FreeBSD on the Athlon64 in 64bit vs Pentium4 3.2E 74
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."
Old news... (Score:2, Informative)
Re:Old news... (Score:1, Funny)
Re:Old news... (Score:2, Funny)
HT & threads (Score:2, Insightful)
Re:HT & threads (Score:5, Interesting)
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.
Re:HT & threads (Score:5, Informative)
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.
Re:HT & threads (Score:2)
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).
If it were possible, I would have done this and measure temperatures as well... but I couldn't find a way to measure these things without interfering with the tests. It was really important to me to prevent anything from altering the test results. Of course if you h
Re:HT & threads (Score:5, Interesting)
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.
Re:HT & threads (Score:1)
FWIW, my personal simplistic non-HT vs. HT test on Windows XP showed that HT does make a difference. While, er, backing up a DVD to an XviD AVI file using AutoGK, second encode pass, non-HT took 142 minutes on my 3GHz P4 with dual channel DDR400 memory. After turning HT on, it took only 122 minutes...
Re:HT & threads (Score:2)
What about multiple processors? (Score:5, Interesting)
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.
Re:What about multiple processors? (Score:5, Informative)
It shows that you have capacity over for starting other processes. It also shows that your system is slower that it could be. Some food for thought relating to the uses of hyperthreading.
Re:What about multiple processors? (Score:4, Interesting)
Now, if you're running 100% on 2 "processors" which happen to be the same chip on HTT, you're really not using the full potential of the machine.
And to quote Chris Rock, "Turn that shit off!"
Re:What about multiple processors? (Score:1)
For a great aticle comparing SMP systems check out this article at Ace's Harware [aceshardware.com]. I know that its not a BSD based comparison, but it should give you s
Ultimate 64 bit Nethack box! (Score:4, Funny)
I mean, don't get me wrong. I'm all about benchmarks. I love fast kit. I own an Athlon64, so seeing it win even makes me feel good about myself. OTOH, the performance differences tend not to be huge, and Athlon64 doesn't win every benchmark. Wake me up when I can afford 8 GB of RAM. That's when Athlon 64 will really matter.
Re:Ultimate 64 bit Nethack box! (Score:5, Insightful)
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."
Re:Ultimate 64 bit Nethack box! (Score:5, Informative)
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.
Re:Ultimate 64 bit Nethack box! (Score:5, Insightful)
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.
Re:Ultimate 64 bit Nethack box! (Score:3, Informative)
The primary determination of clock-speed (besides process technology of course) is the largest number of transistors and the leng
Re:Ultimate 64 bit Nethack box! (Score:1, Troll)
Yes, the fact that Intel's approach will melt your heatsink means nothing at all, and should be completely disregarded.
Re:Ultimate 64 bit Nethack box! (Score:2)
Re:Ultimate 64 bit Nethack box! (Score:2)
My limited understanding is that for many 32 bit O/Ses the kernel wants part of the address space for itself and the rest of the address space is for the currently running process.
If you have a 2GB:2GB address space split in some cases 2GB of kernel space isn't enough, in other cases 2GB of user space isn't enough. You can do 3:1 or 1:3 splits for some O/S but what gets squished into the 1GB space?
So it seems address space starts to m
Re:Ultimate 64 bit Nethack box! (Score:2)
But you are forgetting a great many things.
First of there is heat and power... The Athlon 64 runs cooler, and requires less power than a regular Athlon/Pentium. And that's only the PEAK specs.
Dig deeper and you will find that the Athlon 64 is even better than that. It throttles down the MHz when the CPU isn't being fully utilized, so you are using even less power and creating even less heat, because surely you aren't go
AMD 3200 won with only 512k cache. (Score:4, Informative)
Toms hardware has nice review [tomshardware.com] and benchmarks for the 3400 vs the P4 3.4.
Also anyone notice, in both articles, P4's clean house on synthetic benchmarks, but real world (build process) the AMD cleans house.
Re:AMD 3200 won with only 512k cache. (Score:5, Informative)
Come to think of it, this can actually be found on the very page you linked to.
What a Refreshing Review! (Score:5, Funny)
It's the antithesis of a Tom's review!
64 bit is faster (Score:3, Informative)
Re:It has been confirmed, Linux sucks... (Score:1, Interesting)
The problem is, that at any one time, you can point at different versions of two kernels and get wildly varying results. Linux 2.6 performance is very impressive though.
The stable gene
Re:It has been confirmed, Linux sucks... (Score:1, Insightful)
Have you looked at the finished benchmark document?
There is an area where Linux is 100 times faster than FreeBSD and yet NetBSD is 400 times faster than FreeBSD.
This benchmark that you covet so highly, is being largely discredited, to the point where the author is considering taking it off the net and re-doing it properly.
Linux 2.6 is pretty new, FreeBSD 4.9 takes very cautious steps forward and 5.x is an unstable work in progress. N
Re:When is 5.3-RELEASE coming out? (Score:1, Informative)
Either way, I'd expect there won't be a 5-STABLE branch until the end of the year if not longer.
Re:When is 5.3-RELEASE coming out? (Score:2, Interesting)
32 bit/64 bit comparision (Score:3, Interesting)
If we ignore the cases where the 32-bit code has been optimised via ASM, it looks like the athlon64 is noticably faster on 64-bit code, and often much faster. This backs up what a number of people had been saying, that even if 64-bit code takes up more space the extra registers are a bonus (I'm thinking it's quite likely that gcc hasn't got around to using the various new instructions available yet)
Finally !!! (Score:1)
Re:Finally !!! (Score:3, Interesting)
But... (Score:1)
2. This crappy beta's installer doesn't boot on my machine. And we're not the only one having problem do get it work.
Holy Crap! (Score:1)
*salivate* If only I could afford one of the damn things...
Re:Holy Crap! (Score:2)
IIRC, the Athlon FX is basically an Opteron and the P4 EE is a Xeon, so it says something about the server market too.
Re:Holy Crap! (Score:2, Informative)
Re:Why BSD ? (Score:5, Interesting)
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.
-JemRe:Why BSD ? (Score:1, Insightful)
So it OpenSSL.
I think someone cant get over the fact that *BSD is dead.
Re:Why BSD ? (Score:2)
Re:What I'd like to know is... (Score:2, Insightful)
How is it more reliable, how is it easier to use, maintain, and how is the community better?
I mean, personally I don't give a shit which you use; I prefer FreeBSD over Linux any day, for any purpose. That's just me.
P.S. Several months == nothing. n00b@!$!$
But seriously, you do seem a TAD biased towards Linux. But that's cool too, because your opinion isn't going to change shit for me in the end.
Re:What I'd like to know is... (Score:2, Insightful)
BSD is not better than Linux, and Linux is not better than BSD. I personally am much more comfortable with a BSD system, your experience may vary. I don't care, and I do not think highly of someone who dislikes someone simply because of the OS that they choose to put their support behind.
BSD snobs disgust me.
Speed and stability aren't everything. For example: BSD could be 50% slower than Linux, and I coul