Peer review of AMD64/FreeBSD article

[Jem Matzan]

Bill Squire wrote:

>On Fri, Mar 12, 2004 at 02:01:50PM +0100, Oliver Fromme wrote:
>  
>
>>Jem Matzan <valour at thejemreport.com> wrote:
>> > I've just finished writing this article comparing performance between an 
>> > Athlon64 in 32-bit and 64-bit mode using FreeBSD:
>> > 
>> > http://www.thejemreport.com/lab64/amd64vsi386.php
>> > 
>> > (this is a temporary address which will later redirect to the published 
>> > article)
>> > 
>> > I've checked it over twice for fact accuracy, but I would like other 
>> > eyes to look at it before it goes to press. I haven't spell-checked it 
>> > yet, so don't worry about that... I just want to make sure I haven't 
>> > made any factual errors.
>>
>>I like the article very much.  Well done.  I also appre-
>>ciate the fact that you refrained from spoiling the compa-
>>rison with colorful graphics.  :-)
>>
>>There are just two things which seem a bit unclear to me.
>>
>>In the very first paragraph it sounds like hyperthreading
>>would always be a performance win, but that's not the case.
>>I've had applications that ran slightly faster when hyper-
>>threading was turned off.  If I remember correctly, soft-
>>ware that does many concurrent things and I/O benefits most
>>from hyperthreading, while pure numbercrunching jobs run
>>faster with hyperthreading switched off.  (I'm not saying
>>that you should repeat all your benchmarks with hyper-
>>threading off, mind you.  I just think that the remark in
>>the first paragraph sounds a little bit misleading.  YMMV.)
>>
>>The second point is that the gcc "benchmark" seems a bit
>>unfair for me, because you're really measuring _different_
>>things when compiling something for i386 and for amd64.
>>The compiler is producing different code, it has to opti-
>>mize differently (particularly because of the different
>>register sets of the processors), so you can't really
>>compare the results.  Also take into account that the amd64
>>code generation engine of gcc is rather new, while the i386
>>code generation is very mature.  Apart from that, I would
>>rather call this "benchmark" synthetic, because nobody buys
>>an Opteron to compile things all day long.  Well, except
>>for the FreeBSD package building people, maybe.  :-)
>>
>>In relation to that, the oggenc benchmark is certainly much
>>more realistic.  It would have been nice to have some video
>>decoding / encoding benchmarks, too (e.g. mplayer / menco-
>>der, transcode, ffmpeg, whatever).
>>
>>Well, just my 2 cents.  :-)
>>
>>Regards
>>   Oliver
>>
>>    
>>
>
>Hi Oliver,
>
>Your name seems familiar to me. Anyways, as far as benchmarks there is 
>allot of 'snake oil' for salesmen out there. This is the coolest bench
>mark for hardware I've ever seen. It is extremely technical and do 
>understand it or limit your experiment. 
><http://www.kurims.kyoto-u.ac.jp/~ooura/fft.html> 
>
>Good luck, (everyone -- this is fun stuff)
>
>Bill
>
>PS: My EUR 0,02 worth (Actually free and ALLOT of time went into getting 
>this right.) You should be able to get 4M (2^22) digits of pi in about 
>2:22s with a single amd64 running at 2.22GHz. :) The performance rating
>of a well tuned amd64 is over 5600, the beat Intel barely gets 3000 and 
>uh won't spoil the fun, but "The fastest desktop ever" (as the ads in the 
>sheepish trash once read.) Will not likely beat the Intel, but I don't 
>waste my time on closed source.
>
> 
>
>
>
>
> 
>_______________________________________________
>freebsd-amd64 at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
>To unsubscribe, send any mail to "freebsd-amd64-unsubscribe at freebsd.org"
>
>
>  
>
Alas it's not in ports... I'd rather have a standard version to go from, 
knowing that the code will work well with FreeBSD 5.2.1-RELEASE. It 
looks like a good test though; I'm going to try it out anyway for my 
next round of testing. I'm particularly interested in valid tests that 
can accurately show performance differences between architectures.

-Jem