Date: Fri, 14 May 1999 12:58:19 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Eivind Eklund <eivind@FreeBSD.ORG>, Brett Glass <brett@lariat.org>, Jamie Bowden <ragnar@sysabend.org>, chat@FreeBSD.ORG Subject: Re: BSD, GPL, the world today. (fwd) Message-ID: <Pine.BSF.3.96.990514124241.26546b-100000@cygnus.rush.net> In-Reply-To: <xzpr9oj3esz.fsf@localhost.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 May 1999, Dag-Erling Smorgrav wrote: > [I consider myself a friend of Alfred's as well, which I guess > entitles me to pick on him ;P] > > Eivind Eklund <eivind@FreeBSD.ORG> writes: > > To state this another way: Alfred, you're repeating a lot of myths. > > If you're going to have an opinion about this stuff (and you don't > > have to - saying "I don't know enough to have an opinion" is fair > > statement), you need to get the facts. Compiler theory, memory > > management speed measurements, cache handling, average number of bugs > > connected to different programming paradigms, etc. > > To pick one item in the above list which is becoming increasingly > important, C is too low-level to allow the compiler to properly > optimize for efficient cache use, and lacks constructs which would > allow the programmer to help the compiler do this. The reason why I'm > saying it's becoming increasingly important is that memory (and cache) > speed is lagging way behind CPU speed, and the gap is widening every > day. Consider an n-way superscalar CPU with, say, five issues per > clock, running at one gigahertz (totalling five gigaissues per second > in the best case), and a memory hierarchy with a level 1 cache running > at CPU speed and a primary store with a 100 ns average acess, a cache > miss costs 500 instructions. Given those premises, you really, really > want to avoid cache misses as much as possible. I'm sort of irritated that the two of you don't belive I know enough about cache to code appropriatly for it. I do profile my code, I have taken various projects and optimized the hell out of them. @hotjobs I increased the complexity of the resume extractor by 5 times; 5 times more code, and took the performance down from 10ms to ~1-2ms, increasing the accuracy of it and giving it the speed needed to batch large amounts of input. I try to make my programs exhibit as much locality as possible. Avoid kernel calls, watch my reallocs, allocs and strdups etc... Speed has always been very important to me, so if you have any suggestions as to languages to look at (for some reason Modula-2/3 looks cool maybe?) I'd be happy to take a look at it. I've found myself unable to sleep many times thinking "if only C offered feature X or Y to make this faster..." this leaves me VERY open to suggestions for a replacement. :) Java gets you banished to the wasteland. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990514124241.26546b-100000>