Pattern in CPU benchmarks that could (MAYBE) predict SONAR performance?

This is the second and last of two burning questions I've wanted to ask for some time now.

In anticipation of my looming DAW upgrade, I've looked at every benchmark available on the net for the more recent Intel and AMD CPUs. No, I'm not posting to ask which CPU you think would be best. It's just that I've noticed a distinct pattern that I think (I'm not knowledgeable about programming, processing technology, etc. so please keep in mind that I'm completely prepared to be 100% wrong here) MIGHT - might - help predict performance in SONAR, depending on how we use it most.

This is the pattern I think I've picked up on. Please note that each processing category is INDEPENDANT of the others, so just because one performs better in one category doesn't guarantee it would if the processes were mixed.

Integer-heavy apps: Athlon 64 FX CPUs tend to outperform other processors.

Floating point-heavy apps: Pentium Extreme Edition 800 series CPUs take the lead here.

Multi-threaded/multi-processor optimized apps: The new dual core Athlon 64 X2 CPUs seem to be quite a bit faster here, all things being equal.

Pure memory bandwidth intensive processes (i.e. functions or apps in which memory bandwidth takes precedence over other factors by a large enough margin for it to dominate the process): The fastest clocked CPU with the fastest RAM wins here regardless of rating, dual core, or on-die cache. Currently, that means the Pentium 4 EE 3.7/3.8GHz.

Functions or apps in which memory bandwidth, floating point, and integer are all roughly equal in importance, and in which none of the three dominate: The Athlon 64 FX wins here.

Integer-heavy apps with SSE/SSE2 (and one would assume 3 as well) optimization: Athlon 64 FX and Pentium Extreme Edition 800 series are more or less tied here, with the Pentium having a very slight edge.

Floating point-heavy apps with SSE optimization (same as above but more floating point intensive than integer): Pentium Extreme Edition 800 series wins here by a fair margin.

So, I need to ask a few questions following from these assumptions (which as I said, may be misinterpretations of the dozens of benchmarks I saw - but they all seemed consistent across the board in these areas to me), and they are these:

1) Is SONAR 4 more integer heavy or floating point intensive, and if so, which parts of SONAR are most floating point or integer heavy?

2) Is SONAR 4 SSE optimized?

3) Is SONAR 4 multithreaded and/or optimized for multi-processing?

4) Is SONAR 4 extremely memory bandwidth intensive, and if so, what aspects or functions of it are the most reliant upon memory size and bandwidth, more so than other factors such as clock speed?

If anyone can provide reasonable and verifiable answers with respect to these questions - unless I'm just a moron, which has been known to happen more often than not lol - then I think we may be able to (within reason) predict which of the new top of the line CPUs will run SONAR best. This may/will vary from person to person of course, because we all use certain features more or less than others, and different aspects of SONAR are likely to rely more or less on different factors.

Anyway, like I said I could be completely moronic. Nonetheless, I thought this would make for a worthy conversation - if for no reason but to display my ineptitude lol.

Wow, that's a great resource - that should be stickied. Thanks very much for bringing that to my attention.

From that I'm able to derive atleast two things - 1) SONAR appears to benefit much more from good integer performance than from having a good FPU, and 2) it is definitely very efficient at utilizing dual processing.

Based on those benchmarks I would say the top three configurations one could buy in the next few months would be:

Dual Opteron 275

Athlon 64 X2 4800+ (get's the better of a single Opteron 175 in most benchmarks)

Single Opteron 175 (dual core)

Granted, the up coming FX-57 will be higher clocked than the 175 and 4800+ but it appears that SONAR peforms far better in systems with high multithreading capability. Evidence of this is that even the Opteron 246 in those benchmarks outperforms the FX-53, despite giving up 400MHz and faster (unbuffered) RAM to it.

From that I'm able to derive atleast two things - 1) SONAR appears to benefit much more from good integer performance than from having a good FPU, and 2) it is definitely very efficient at utilizing dual processing.

#2 - It sure does!

#1 - Integer performance is not the whole picture here. The Sonar performance tests show a high sensitivity to RAM latency, not necessarily bandwidth. For this reasion it likes large caches that can hide the latency to system RAM (the reason the P4 XE and Pentium M do well), as well as improved memory controller performance. None of the common benchmarks (aside from synthetics) show this kind of behavior. IMO, this is due to pushing the audio latencies very low, causing it to be very important to cycle small chunks of audio data between RAM and CPU. That is where the Athlon 64 core starts to really kick ass. The latencies are much, much lower between RAM and CPU with the memory controller on the die. At high audio latencies your seeing the raw potency of the SSE / floation point / integer execution units of the processors. But push the latency down, and the RAM performance starts to become a factor.

Also, classic x87 floating point operations are much faster on Athlon 64's (and Athlon XP's too). That doesn't really matter much anymore though as x87 code is dissapearing (slowly... old cake efx use x87 instructions for example). The x86-64 instruction set no longer includes x87 instructions.

There's also two types of SSE to consider, scalar and packed. Both the Athlons and the P4 are pretty comparable on scalar SSE code, but the P4 smokes on packed SSE code, hence it's superb performance with archiving and media conversion. I think the underlying cause for that is the branch prediction of the P4 and the penalty for a missed branch with such deep pipelines.

For recording it all depends on the plug in code!

I'm not sure what sources you're using.. but here's my favorite CPU geekiness sites:
www.anandtech.com
www.arstechnica.com
www.techreport.com

ORIGINAL: wogg

From that I'm able to derive atleast two things - 1) SONAR appears to benefit much more from good integer performance than from having a good FPU, and 2) it is definitely very efficient at utilizing dual processing.

#2 - It sure does!

#1 - Integer performance is not the whole picture here. The Sonar performance tests show a high sensitivity to RAM latency, not necessarily bandwidth. For this reasion it likes large caches that can hide the latency to system RAM (the reason the P4 XE and Pentium M do well), as well as improved memory controller performance. None of the common benchmarks (aside from synthetics) show this kind of behavior. IMO, this is due to pushing the audio latencies very low, causing it to be very important to cycle small chunks of audio data between RAM and CPU. That is where the Athlon 64 core starts to really kick ass. The latencies are much, much lower between RAM and CPU with the memory controller on the die. At high audio latencies your seeing the raw potency of the SSE / floation point / integer execution units of the processors. But push the latency down, and the RAM performance starts to become a factor.

Also, classic x87 floating point operations are much faster on Athlon 64's (and Athlon XP's too). That doesn't really matter much anymore though as x87 code is dissapearing (slowly... old cake efx use x87 instructions for example). The x86-64 instruction set no longer includes x87 instructions.

There's also two types of SSE to consider, scalar and packed. Both the Athlons and the P4 are pretty comparable on scalar SSE code, but the P4 smokes on packed SSE code, hence it's superb performance with archiving and media conversion. I think the underlying cause for that is the branch prediction of the P4 and the penalty for a missed branch with such deep pipelines.

For recording it all depends on the plug in code!

I'm not sure what sources you're using.. but here's my favorite CPU geekiness sites:
www.anandtech.com
www.arstechnica.com
www.techreport.com

AH, I see! Thanks for explaining that a little bit more for me. Like I said, I'm not very savvy when it comes to understanding the factors involved. When people say "memory performance," to me that's about as deep an understanding as I can grasp unless someone like you explains it better like you just did lol.

That makes alot of sense now. The on-die memory controller is one of the coolest ideas implemented in a while IMHO. Those sites were all among the ones who's benches I sampled (though not all of them had dual core benches - though they may by now - I could still derive alot from others). I don't really know what integer, FP, and SSE mean. I just knew certain types of benchmarks tested certain things, and that certain CPUs tended - consistently - to behave a certain way under them.

So I was just taking a stab in the dark. I understand it SLIGHTLY better now thanks to you though lol.

Indeed, no offense to OCers as we all have our valid passions but - why OC a CPU that's already more than fast enough, risking the stability of your main workstation? I mean, I do plan to get an X2 but only because I'll be able to afford it by the time I build my new rig. But there's a performance/price balance for everyone, and they're all equaly valid and worthy. The whole OCing thing would just scare me lol.