This topic came up at work and we’re split on which might be better.
The basic machine will be an Asus Xeon server board, 8-12 GB of RAM, Windows XP, a firewire add-on card and bunch of drives.
This will run as a music recording computer running Sonar 8 with two Audiofire 12 interfaces.
I tested the configuration today using a single Xeon 2.33 Ghz Quad core CPU and 8GB RAM. It ran fine for hours pumping out 12 tracks in a loop from Sonar. Sonar appropriately spread the CPU load across the 4 cores and maintained an average of around 18-20% CPU use.
The topic came up if it might be better to run 8 cores. Of course it would. Sure, fine, but we’re looking at another $300 bucks for the second Xeon.
So I priced a slower CPU and I found I could get two Xeon 1.6Ghz quad cores for almost the price of a single 2.33 Ghz.
1.8 Ghz Quad cores are also at an OK price point.
After much debate and head scratching, we couldn’t decide if 8 slower cores would function better than 4 faster cores.
1.8 Ghz isn’t THAT much slower so I suspect we wouldn’t notice much with that. But the 1.6 Ghz is almost half the speed.
If each core is running at 20%, you’re I/O bound, not CPU bound. You’d probably be just as well off with a dual core @ 2.33GHz, or even a single CPU machine.
In general, it’s impossible to answer a question like this. The only way to know would be to test the performance of both configurations. There’s far too many variables that go into it.
Like Rysto, it depends on your definition of “better”.
Given infinite I/O and memory speed, and other issues aside, the 8-core rig gives you more potential calculating power:
2.33ghz * 4 = 9.32bn clocks/sec
1.6ghz * 8 = 12.8bn clocks/sec
So the 8 core rig can potentially do 27% more work.
20% is about average for playing tracks back. That’s not very CPU intensive. I wasn’t working the machine very hard.
The studio computer will have an average of 24-32 tracks going out with, sometimes, 8-10 coming in. The tracks will also be altered by VST effects which will vastly bump the workload of the CPUs. In all I can record/playback a total of 32 audio tracks at a time - which would be the max for my hardware at the moment.
A single core would choke. It doesn’t stand a chance. A dual core sputters a bit as well. Sometimes playing back 8 tracks and recording 4 with a handful of VSTs running will choke it (which is what I’m running on the older system). Sometimes it works, sometimes it doesn’t. So no, that won’t work. At least for a recording system.
How separable are those tracks? If your basic process is one track coming in and being split into three or four tracks going out, and you’re repeating that same basic process 8 times, then your problem will parallelize well to at least 8 processors, likely more, and the simple calculation squeegee did should apply. If there’s some sort of cross-talk between those streams, then it potentially might not, and you could conceivably end up with everything waiting for one processor and going no faster than the single processor by itself.
The more cores there are the more contention there is for system resources. It’s further exasperated by having the cores spread across two chips which requires extra synchronization. In the right (or wrong?) circumstances you could get worse performance with the extra CPU, although I don’t think you’re pushing the system hard enough for it to make a difference.
No-one who’s not cracking 1024bit cyphers needs 8 cores. Virtually everything in the OS and apps will be running on the first two cores, and each succeeding one provides less extra actual processing power. Go for speed over cores every time.
Going in is pretty straight forward. Think of a multi-track tape. Number one input commits to track one, number two input commits to track two,. rinse/repeat up to 32 times in unison.
Outgoing is more complex as you can route committed tracks 1 though 1000+ to any output. Tracks 1 though 10 might all be routed out through output 1 and 2. Track 11 to output 3. Track 12-18 to output 4 and 5. Etc. Between the raw tracks and the output device might be some software processing. This is the big overhead in the system as the software can come from numerous sources.
This whole thing had been hard to figure because of all the weird paths and processing variables. It’s different than our datacenter computers where we have a solid load on a device and I can track that load over time.
This thread sounds like our conversation today. One of my “in favour of 8” thoughts was much like what squeegee pointed out - there are more overall calculations which can be done. One of my “in favour of 4” arguments was having enough overall processing and saving a few bucks.
Bah. I think I’ll just split the difference and get a couple of quad 2.0 Ghz and be done with it.
I’ll make sure to tell this to my co-workers and suggest pulling our second CPUs. I’m sure our database servers will run just as well.
Oh, and can I have your email address? I’d like to have the alerts sent to you directly
I believe Xeons also come in 6-core variants, so you might want to consider those too.
But really, what you should do is stress-test your platform to see at what point it fails and make your judgement from that. I’m not familiar with the software you use so I cannot advise you how to do that.
Quartz: I might consider it but I don’t think the board I have will support 6 cores and I already bought two quad 2.33Ghz. Doing some research shows most people in this application are going with 8 cores over four. Plus, I scored a good deal on the 2.33’s
