Rendering: 3ds Max 2008
Operating System Windows 2008 Enterprise RTM (64-bit)
Software 3ds Max 2008
Benchmark software Build in timer
Typical error margin 1-2%

Render server are only a small part of the server market. We used the "architecture" scene included in the SPEC APC 3DS Max test. All tests were done with 3ds max's default scanline renderer, SSE enabled, and we rendered at HD 720p (1280x720) resolution. We measured the time it takes to render 10 frames (from 20 to 29) and then calculated (3600 seconds * 10 frames / time recorded) how many frames a certain CPU configuration could render in one hour. Results are reported as rendered images per hour.


We used the 32-bit version of 3ds Max 2008 on 64-bit Windows 2008 RTM. The 64-bit version of Windows 2008 is a bit slower (especially when you use the scanline renderer). All CPU configurations are dual, unless we indicate otherwise.

3ds Max 2008 32-bit - architecture scene

When it comes to floating point and SSE, the performance gains over several CPU generations are a bit smaller. The Xeon 5570 again shatters all records, but it's "only" three times faster than the Xeon 5080. There are two reasons for this. First, the Xeon 5080 is based on the Pentium 4 architecture. Thanks to its high clock speed, it can deliver relatively high FLOPS (Floating Point Operations per Second). The high branch prediction penalty, the relatively low hit rate of the trace cache, and very high memory latency which all made the Pentium 4 based Xeons very inefficient in integer code are of no real importance when running floating point intensive applications such as 3ds Max.

Improvements have been slower in this area. In the Xeon 51xx we have seen the introduction of 128-bit SSE units (AMD: Barcelona, Opteron 23xx) and faster 4-bit RADIX in the Harpertown Xeon (Xeon 54xx). We analyzed this in great detail previously: while the Opterons are still better at divisions, the Xeon 54xx is faster in multiplications which are much more common. The Xeon 55x "Nehalem" is almost identical to the Xeon 54xx "Harpertown", while the AMD "Shanghai" is identical to AMD "Barcelona" core when it comes to floating point. Notice how the Nehalem at 2.93GHz (in reality 3.1GHz) settles between the 3GHz and 3.3GHz Xeon 54xx. This confirms that floating point code hardly sees a difference between a Harpertown and a Nehalem… unless it is limited by the bandwidth available to the core of course. Nehalem can still beat its older brothers thanks to SMT, once again underlining what a powerful weapon SMT is.

While the Xeon X5570 is only 24% faster than the Xeon 5450, that is good enough to make the current 4-way servers completely useless for rendering. The dual Xeon "Nehalem" offers the same performance at much lower price points, while consuming a lot less power.

Collaboration - MS Exchange 2007 Virtualization - ESX 3.5 Update 2/3
Comments Locked

44 Comments

View All Comments

  • gwolfman - Tuesday, March 31, 2009 - link

    Why was this article pulled yesterday after it first posted?
  • JohanAnandtech - Tuesday, March 31, 2009 - link

    Because the NDA date was noon in the pacific zone and not CET. We were slightly too early...
  • yasbane - Tuesday, March 31, 2009 - link

    Hi Johan,

    Any chance of some more comprehensive Linux benchmarks? Haven't seen any on IT Anandtech for a while.

    cheers
  • JohanAnandtech - Tuesday, March 31, 2009 - link

    Yes, we are working on that. Our first Oracle testing is finished on the AMD's platform, but still working on the rest.

    Mind you, all our articles so far have included Linux benchmarking. All mysql testing for example, Stream, Specjbb and Linpack.
  • Exar3342 - Monday, March 30, 2009 - link

    Thanks for the extremely informative and interesting review Johan. I am definitely looking forward to more server reviews; are the 4-way CPUs out later this year? That will be interesting as well.
  • Exar3342 - Monday, March 30, 2009 - link

    Forgot to mention that I was suprised HT has such an impact that it did in some of the benches. It made some huge differences in certain applications, and slightly hindered it in others. Overall, I can see why Intel wanted to bring back SMT for the Nehalem architecture.
  • duploxxx - Monday, March 30, 2009 - link

    awesome performance, but would like to see how the intel 5510-20-30 fare against the amd 2378-80-82 after all that is the same price range.

    It was the same with woodcrest and conroe launch, everybody saw huge performance lead but then only bought the very slow versions.... then the question is what is still the best value performance/price/power.

    Istanbul better come faster for amd, how it looks now with decent 45nm power consumption it will be able to bring some battle to high-end 55xx versions.
  • eryco - Tuesday, April 14, 2009 - link

    Very informative article... I would also be interested in seeing how any of the midrange 5520/30 Xeons compare to the 2382/84 Opterons. Especially now that some vendors are giving discounts on the AMD-based servers, the premium for a server with X5550/60/70s is even bigger. It would be interesting to see how the performance scales for the Nehalem Xeons, and how it compares to Shanghai Opterons in the same price range. We're looking to acquire some new servers and we can afford 2P systems with 2384s, but on the Intel side we can only go as far as E5530s. Unfortunately there's no performance data for Xeons in the midrange anywhere online so we can make a comparison.
  • haplo602 - Monday, March 30, 2009 - link

    I only skimmed the graphs, but how about some consistency ? some of the graphs feature only dual core opterons, some have a mix of dual and quad core ... pricing chart also features only dual core opterons ...

    looking just at the graphs, I cannot make any conclusion ...
  • TA152H - Monday, March 30, 2009 - link

    Part of the problem with the 54xx CPUs is not the CPUs themselves, but the FB-DIMMS. Part of the big improvement for the Nehalem in the server world is because Intel sodomized their 54xx platform, for reasons that escape most people, with the FB-DIMMs. But, it's really not mentioned except with regards to power. If the IMC (which is not an AMD innovation by the way, it's been done many times before they did it, even on the x86 by NexGen, a company they later bought) is so important, then surely the FB-DIMMs are. They both are related to the same issue - memory latency.

    It's not really important though, since that's what you'd get if you bought the Intel 54xx; it's more of an academic complaint. But, I'd like to see the Nehalem tested with dual channel memory, which is a real issue. The reason being, it has lower latency while only using two channels, and for some benchmarks, certainly not all or even the majority, you might see better performance by using two (or maybe it never happens). If you're running a specific application that runs better using dual channel, it would be good to know.

    Overall, though, a very good article. The first thing I mention is a nitpick, the second may not even matter if three channel performance is always better.

Log in

Don't have an account? Sign up now