Peer review of AMD64/FreeBSD article
Jem Matzan
valour at thejemreport.com
Fri Mar 12 12:31:36 PST 2004
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
More information about the freebsd-amd64
mailing list