Slashdot Mirror
FreeBSD on the Athlon64 in 64bit vs Pentium4 3.2E
veliath writes "Came by a comparison from about three weeks ago, between two systems running FreeBSD. One is an Athlon64 running FreeBSD in 64bit mode and the other a Pentium4 3.2E running FreeBSD in 32bit mode."
While I don't know about FreeBSD's threads sucking as far as I could tell none of the tests would've stressed the threading system.
The tests didn't really work to hyper-threading's advantages. Take the builds with multiple jobs running at the same time. That's more about running separate applications as separate processes and that's not what hyper-threading's advantage is because they arn't separate thread at all.
HT is more for true multithreaded applications like Photoshop or something and none of the benchmarks were anything like that.
Nice comparision, but what about dual or quad processor systems? I have recently installed both FreeBSD 4.9 and 5.2.1 on (almost) identical dual-Xeon servers. Both are operating as if they had 4 processors (due to HTT). How would the Athelon, etc. stack up with this setup (seriously, I'd like to know)? Maybe HTT realy shines on multiple CPU systems, not just mon-processor? Maybe.
BTW- FreeBSD (either version) on a brand new Dell rack-mount server, with hardware RAID, 2GB RAM, dual processor (of course) makes for a very fast server! I have them configured mostly as web servers, a number of Perl generated dynamic pages (ad serving mostly), rsync, CVS repository, Cyrus and Sendmail (w/SASL AUTH and TLS/SSL), MySQL, and a custom rsync staging/production environment. When I run top, it sure is nice to every now and then see 2 processors at almost 100% utilization, yet also show 50% idle. I have no benchmarks to report, alas these are production machines in use.
One page, no annoying Flash advertisements, no tedious space-filling fluff, solid information.
It's the antithesis of a Tom's review!
--
Don't like it? Respond with words, not karma.
The real-world apps demonstrate that the 5% of die space spent on HT doesn't result in much more leveraging of the execution core, in practice. I can't imagine why anyone would care what the P4 numbers were without HT, since no one will ever run it that way now that OSen are supporting it.
As regards FreeBSD's kernel threads, the answer is "not really" since the overwhelming bulk of the benchmarks was spent in userspace (less so for the compile benchmarks than for the crypto ones). Notice that the user time numbers favored the Athlon64 no less than did the wall time numbers.
I think it's interesting that the synthetic benchmarks all favored the P4 (a highly academic design) while the user load tests all favored the 64.
-I like my women like I like my tea: green-
I think you're mistaking the Athlon64 3200+ for the 3000+. 3200+ has 1M cache, while 3000+ has 512k. 3400+ has the same 1M cache, plus the 0.2GHz speed bump.
Come to think of it, this can actually be found on the very page you linked to.
You're forgetting something very crucial here ... the Athlon64 is clocked almost 1 GHz slower than the P4 ... yet the performance difference is virtually nil. That says a lot more about the performance of the Athlon64 than anything.
That's not a "ho-hum" benchmark to me. That's an "Intel has royally fubar'd themselves. Here's hoping their Pentium-M strategy brings them back on track."
What HyperThreading is...
Out of order execution takes the processor to a particular level of performance. Unfortunately, (and especially with the X86 IA), we run out of steam rather quickly, and the processor blocks waiting on registers or memory. The idea behind HT is that the processor's execution elements can then be reassigned to something else waiting in cache.
Of course, this means we need a big fat cache, and something else to execute. Could be another thread or process, but the important thing is that the second job be independent.
This can increase the utilization of the processor's compute elements.
So, yes, the "builds with multiple jobs running at the same time" test makes sense.
I would like to see a benchmark with CPU stalls and utilization summarized at the end. Can't do it myself, because I am far too cheap to replace my current system (and yes, it is an MP box - dual 200Mhz PPRO - and it still does quite nicely).
Anyway, it does look the the Intel took a hit in this benchmark; too bad for them. I looked over the methodology -- and it looked reasonable given the scope of the project.
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
So sad to see that the parent is yet another victim of the megahertz myth.
Imagine for a moment that a CPU maker created a chip that performed 10 times the number of operations per cycle that either Intel or AMD could achieve. But also imagine that because of the complexity, they could only get the chip to run at 50MHz. Not very useful, huh?
Intel has gone with a design that allows them to ramp up clock speed. AMD has gone with a design that allows them to use clock cycles more efficiently.
Both of those approaches are a perfectly good way to do things. All that matters is how fast the user's applications run in the end.
Interesting point, but surely, Intel will be running into physics problems way faster than AMD will, because Intel are running much closer to the raw speed edge.
Megahurtz myths aside, frequency is still frequency and there is an upper limit. The first one to hit the wall loses, by the way. So the frequency/performance aspect of intel processors is definately worth keeping in mind. This is why the Pentium-M is becoming the forefront processor-More IPC than the PIV architecture. Perhaps intel has hit the wall already?
Likewise, one could reason that many of the tricks that Intel are using to increase frequency could be applied to AMD's architectures in the future, giving AMD much more room for growth, as intel has already exhausted many of the available technologies.
I am government man, come from the government. The government has sent me. -- G.I.R.
From a related article referenced in the story (I'll post the excerpt because you're a stupid troll and aren't going to RTFA):
"Before I continue, I'd like to elaborate on why I chose FreeBSD as a benchmarking platform. The original reason was that it supports both the AMD64 and IA32 (i386) architectures, and the purpose of the benchmarking project was to compare performance between an Athlon 64 machine in both i386 and AMD64 modes. I also wanted to compare these two setups with a Pentium4 3.2E system to discover if Hyper-Threading or 64-bit extensions were more important to computing power. Microsoft operating systems available at the time of the project were not able to run in AMD64 mode, and even if they were, there was no 64-bit capable benchmarking software to use on a Windows platform. So the first goal was to find an OS that could use these two machines in the required modes, and the second goal was to find relevant benchmarking methods that could show the performance difference between the configurations. GNU/Linux was an option (specifically Gentoo Linux), but it wasn't mature enough at the time of testing and it didn't offer much to me in the way of benchmarking. NetBSD was also a consideration because it supports so many architectures and has been working with AMD64 longer than most other OSes. This was particularly attractive to me because I could also benchmark machines that were based on the SPARC, POWER, and MIPS architectures and compare them all. This would have worked except for the fact that NetBSD didn't have an official release for AMD64 when I was ready to test, so I'd have to have used experimental code. I also would have trouble getting the same exact code onto each machine because it changes so quickly. FreeBSD already had an AMD64 release (two, actually) and it worked terrifically for my purposes. When I started testing I was using 5.2-RELEASE, but switched to and retested with 5.2.1-RELEASE when it became available. FreeBSD was perfect because I could use the actual release (guaranteeing the same age and quality of the code for both AMD64 and i386), and the ports tree had a number of excellent benchmark tests to choose from.
The FreeBSD base system comes with OpenSSL, which offers an excellent benchmarking mode. It also includes the old Unix time command, which is essential for stopwatch tests. So, all things considered, FreeBSD was the best operating system for the project."
I guess FreeBSD can't be dead if it had a more stable and mature AMD64 port than other operating systems did.
-Jem