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.
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-
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)
Combination - fun iPhone puzzling
Actually, there is a beta version of Windows 64 bit out for AMD and Intel users to test out. Cost nothing to download, and you can get a CD in the mail if you need to. I had problems burning from their ISO, so i opted for the CD in the mail. The biggest advantage of Win 64 bit is you get past a great deal of the memory limitations in Windows XP and 2000. I have noticed a great difference in speed between running the same AMD 64 3200+ machine in Windows XP and Windows 64 bit on a dual boot.
LainTheWired = isgod( int Lain, int denial, float truth)
I am running -CURRENT on my router. It has been running 50 days without any problems. I also run -CURRENT on my laptop and desktop systems, without problems... The only panic I had was when I forgot to recompile my nvidia kernel module after doing installworld/installkernel.
Your google link is not very compelling, the mailing list link links off to a broken link, the fefe benchmark shows that FreeBSD and especially NetBSD perform very well (did you read it all? They had huge improvements in a very short time.) and the NASA story seems to have no relevence to BSD (can you enlighten us on that?).
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 generic BSD's in the past have performed very well and consistent, often better than Linux. The improvements in NetBSD show that great things are coming and they will make it to FreeBSD eventually.
I think Linux and BSD will be neck and neck soon, as far as performance goes. As they both get closer to theoretical walls. Not that tricks like those found with NetBSD and FreeBSD won't be engineered.
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