Date: Sat, 6 Mar 2004 02:45:05 +0000 From: Daniela <dgw@liwest.at> To: Rahul Siddharthan <rsidd@online.fr> Cc: chat@freebsd.org Subject: Re: FreeBSD Most wanted Message-ID: <200403060245.05790.dgw@liwest.at> In-Reply-To: <20040306012556.GA2554@online.fr> References: <20040306012556.GA2554@online.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 06 March 2004 01:25, Rahul Siddharthan wrote: > Daniela wrote: > > > > I know, by experience, that my code is always much faster than the > > > > compiler-generated code. > > > > > > *rotfl* > > > > > > seriously, grow up. > > > > This wasn't meant as a generalization, I only wanted to say that every > > time I tried it so far, my code was faster. > > Sorry if this is misleading. > > You're probably trying some specific category of programs. Apart from > the fact that most compilers are pretty good these days, most programs > run into bottlenecks other than the CPU rather quickly and there's not > much point in optimising them. Look at the output of "top": there may > be a hundred or more processes running on the system, but usually no > process takes up more than a fraction of a percent of the CPU time. > Bittorrent is written in python, and it won't be any faster written in > asm because it spends most of its time waiting. I hardly ever optimize only for CPU time. If there are other bottlenecks, I also try to combat them. > Things were very different in the 1980s because (a) cpu speeds were > 100-500 times lower than today and hadn't so greatly outpaced the > rest of the hardware, (b) RAM was much more limited, so the savings in > memory usage from handcoded assembly was significant, (c) the most > common operating system was MS-DOS, which was hardly an operating > system at all, so programs didn't worry about playing nice with one > another. > > If you're doing some serious numbercrunching code, eg scientific > programming, then you need to worry not only about speed but about > correctness. (I don't mean to imply that correctness is unimportant > otherwise, but a very minor bug in a scientific program can ruin your > reputation.) Most people would not want to debug asm code and will > take the performance hit (if any) of a compiler. And even if you're > dissatisfied with the speed of the compiled program, if you profile > the program you generally find that one routine, comprising less than > 10% of the code, is responsible for over 90% of the execution time, so > you really don't gain from optimising the rest. I like doing AI programming, that's numbercrunching most of the time. A compiler can't, for example, know whether you need to have zero returned from the atoi() function when the user entered nonsense. If you don't need to check whether the user has entered a valid number, you can do it *much* faster.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403060245.05790.dgw>