Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD on the Athlon64 in 64bit vs Pentium4 3.2E

Posted by Hemos on from the compare-and-contrast dept.

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."

25 of 74 comments (clear)

  1. Old news... by hmallett · · Score: 2, Informative

    This is the same article as was linked to from the FreeBSD site a few weeks ago. Everyone's probably read this already. Basically, the Athlon64 is faster.

    1. Re:Old news... by hmallett · · Score: 2, Funny

      I cna understand wanting a spoiler alert on a post revealing the end of a film, but you must be a true geek to want a spoiler alert on a benchmark!

  2. HT & threads by davegaramond · · Score: 2, Insightful

    The article says that Intel's HT doesn't improve performance much. Isn't this expected, considering that IIRC FreeBSD's kernel threads still suck and most of the programs are single threaded anyway?

    1. Re:HT & threads by Anonymous Coward · · Score: 5, Interesting

      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.

    2. Re:HT & threads by aminorex · · Score: 5, Interesting
      HT does wonders for the P4 in the bandwidth tests, because they are not taxing the execution core; they are only stressing the limits of those parts of the CPU which are replicated. In fact, I can go a step further and say that they aren't even taxing those parts in any meaningful way, because the P4 just plain has fat pipes. Forthcoming dual-channel revisions of the Athlon64 will do another leap-frog, and put that architecture's bandwidth in the lead for a while, but it hasn't happened yet.

      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-
    3. Re:HT & threads by ratboy666 · · Score: 4, Informative

      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
  3. What about multiple processors? by RT+Alec · · 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.

    1. Re:What about multiple processors? by Homology · · Score: 4, Informative
      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.

      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.

    2. Re:What about multiple processors? by Agent+Green · · Score: 3, Interesting

      HTT offers little to zero benefit for properly optimized MP systems like FreeBSD. It helps with scheduling...not by giving you 4 processors of power.

      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!"

      --
      // Agent Green (Ian / IU7 / KB1JQO)
      // IEEE 802.3: All 10base Are Belong To Us
  4. Ultimate 64 bit Nethack box! by forkazoo · · Score: 3, Funny

    Wow, coupled with the ATI Radeon 9600ASC, I'd be the ultimate in cool, whilst getting my Nethack on.

    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.

    1. Re:Ultimate 64 bit Nethack box! by phoenix_rizzen · · Score: 4, Insightful

      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."

    2. Re:Ultimate 64 bit Nethack box! by Henry+V+.009 · · Score: 4, Informative

      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.

    3. Re:Ultimate 64 bit Nethack box! by obeythefist · · Score: 4, Insightful

      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.
    4. Re:Ultimate 64 bit Nethack box! by jasonsingha · · Score: 3, Informative

      All chips are designed to run "at the edge" of the frequency upper limit and so AMD doesn't have an inherent advantage because they do more work per clock cycle and Intel does less work per cycle but has a higher frequency. All chip-makers hit the same physical limitations at about the same time and neither has the advantage because they run at a higher or lower frequency today.

      The primary determination of clock-speed (besides process technology of course) is the largest number of transistors and the length of the wires in the critical path of each pipeline stage. For a chip with a higher clock-speed using the same process technology, this means that it has less wire or transistors in the longest path of each stage so it can be clocked faster. The presumption is that this is achieved by having more stages or better logic when compared to some other design, etc. but it really doesn't matter as far as the physics are concerned. All chips max out when the frequency is so high that the signals flowing through the circuits don't have enough time to go from one stage to the next and from this perspective, the only thing that matters is how much wire and how many transistors. If AMD was able to make faster chips, they would. Likewise with Intel.

      It all boils down to this: if I have path with 10 units of delay and you have all paths with 8 or less units of delay, you will achieve a higher clock-speed if we use the same manufacturing process. Niether design is better for getting sped-up when moving to the next process technology since they use the same transistors and wire and are running at the same edge "node" in the current process technology.

      Where AMD *may* have an advantage is that the top speed of chips may start to be effected by the power-consumption since if the chips get too hot, they will melt. Power-consumption for CMOS is determined by the dynamic component (when CMOS gates change their state they burn power) and a static component (determined by the total number of transistors). You used to be able to ignore the static component but as the feature size decreases, the leakage current begins to become quite noticeable. [AMD is using SOI already to help with this problem. Intel is eventually going to introduce its SOI work-alike (the name escapes me because it was invented by a marketing person).] Most advanced chips designs include circuits which burn power all of the time, but I'll assume that both Intel and AMD use the same tricks with the same small percentage of their transistors (and it is the same transistors with a high dynamic power usage anyways since they are important circuits).

      If is conceivable that one design, Intels P4 or AMD64, is "more efficient" in this it uses less power both statically and dynamically, to acheive the same computations. At the end of the day, the more efficient processor may be able to compute the result quicker because it won't have to turn itself off just to cool down compared to the less efficient design. Currently this kind of limitation is only present in very small laptops.

      However, you can't automatically assume that low frequency means the AMD64 design is more efficient. It may do more wasted work (speculation) per cycle in trying to do more work per cycle. It might have more transistors in its ALUs burning power, etc. One things that hurts Intel is that because they have a longer pipe-line, they have a higher penalty for branch mispredications, but they may just be able to tweak the branch predictor or make it larger to recoup this deficit.

      At the end of the day, you'd probably find out that the two chips are about as efficient as each other (and that PowerPC processors are a little bit more efficient since they have much simpler decoders). I know that both AMD chips and Intel chips both burn a lot of power. If AMD sticks with SOI and Intel uses inferior technology, then AMD will win. But Intel has a lot of money and they probably won't get out-classed in technology by anyone.

  5. AMD 3200 won with only 512k cache. by BrookHarty · · Score: 3, Informative

    I noticed they used the AMD64 3200, But the AMD64 3200+ only has 1/2 the cache compared to the 3400+, that extra cache should boost the build process even more.

    Toms hardware has nice review 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.

    1. Re:AMD 3200 won with only 512k cache. by Too+Much+Noise · · Score: 4, Informative

      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.

  6. What a Refreshing Review! by FFFish · · Score: 4, Funny

    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.
  7. 64 bit is faster by Anonymous Coward · · Score: 3, Informative

    In the end I think the initial point is made with this review though, and that is that 64-bit does make a difference to the "average user" as well as the power user or administrator, but that performance advantage may not be evident in all situations. When under heavy load or dealing with large blocks of data, the Athlon64 (and we can assume that the Opteron and Athlon64-FX also apply) in 64-bit mode achieves superior performance to the same machine in IA32 (x86) mode. This is not so much because of the 64-bit addressing as it is the fact that there are twice as many general-purpose registers available.

  8. 32 bit/64 bit comparision by Chris_Jefferson · · Score: 2, Interesting
    Personally I feel the much more important part of these results is not the athlon64 pentium 4, but the athlon64 on 32-bit and 64-bit code. This is a set of benchmarks I've been trying to find for some time

    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
  9. Re:Finally !!! by bandrzej · · Score: 3, Interesting

    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)

  10. Re:When is 5.3-RELEASE coming out? by boelthorn · · Score: 2, Interesting

    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.

  11. Re:Holy Crap! by mobby_6kl · · Score: 2, Informative

    I can't RTFA, but from the article summary it is a regular Prescott, not ExtremeEdition. IIRC, "E" stands for Prescott, "C" would be for Northwood core.

  12. Re:Why BSD ? by ValourX · · Score: 4, 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.

    -Jem
  13. Re:What I'd like to know is... by DashEvil · · Score: 2, Insightful

    I like how you use four key points, without defending them at all.

    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@!$!$ :P
    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.

    --
    -If God wanted people to be better than me, he would have made them that way.
  14. Re:What I'd like to know is... by DashEvil · · Score: 2, Insightful

    I don't refute with counterpoints because I have no argument other than that your argument is weak.
    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 could still get my work done in it faster. Don't agree? Don't believe me? That's your problem.

    Get over it. What OS you use is irrelevant, it's whether or not you're accomplishing the task that you got on the computer to complete that matters.

    --
    -If God wanted people to be better than me, he would have made them that way.