Hey guys,
I have a thread going on another website and I would love some input from the users here to get more opinions.
Basically, it’s between the 2600k, 2700k, and 3930k.
x79 mobo will have 8 dimm slots.
Something tells me to wait until November.
asked and answered in your other thread.
I am still having mixed emotions about the 4 and 6 core sandy e’s.
Most say 6 cores is overkill, but to me this should mean lots more fx, sends, and vsti’s.
People here and on steinberg.net have also stated that dual cpu’s is not that much more powerful than a single 2600k:
“it takes at least dual 2.8 to 2.93GHz Dual 12 cores to beat a SINGLE 2600 or 980/990. and that system will be more than 2 x the cost. sounds like stupid spending to me… better off to buy 2 2600 systems and slave 1”
This seems unbelievable to me, when steinberg states that you will see a great performance increase:
ftp://ftp.steinberg.net/Download/General_Documents/Multiprocessing_Tech_Info.pdf
There is no such thing as overkill for me.
There advantages to both systems. Obviously once you take additional soundcards, cables and electricity bills into the equation, the cost differential is less, but for me I don’t want to live with the double latency that a master and slave system provides. There are also so many time wasting issues that are solved by only having one computer, that any extra perceived cost is more than made up for after a few days work for me.
That document is a dinosaur, so take no notice of it.
D
Thanks for your input.
Jc,
Your benches here were very helpful http://www.cubendo.com/showthread.php?12-Intel-i5-i7-i9-DAW-Performance-Reports
As a sample standpoint, the 6 core is overkill vs the 2600k it seems.
But as for VSTi, and processing fx, the 6 core doesn’t seem too beneficial either in this bench:
http://www.adkproaudio.com/benchmarks.cfm
What’s the point of a hexa core?
Now I’m stumped, and am wondering how many tracks/samples I can have loaded in cubase before running into problems. Those accurate benches have only been done in Logic Pro.
the logic benchmark on GS i would take with a grain of salt…
lets put it as simply as possible whils very basic it will give you an idea
Hard drives = track count
memory (quantity and to a small degree speed) = number of patches/instances/sample libraires
CPU= effects count. more cores usually mean more effects, however GHz is more important than core count.
thats why the 2600k with its higher GHz can keep up with the 6 core or even the dual Xeons (until you hit a high GHz on the Xeons) also costing you a high $ amount.
its bad enough the $700 difference price tag betwen a 2600 and a 990x how about $2500 or more for Dual Xeon.
making it a useless expense. and $3000 more for a hair better performance. (dual 2.93GHz)
samples are all about GHz. you can run more samples at a lower latency on a 2600 than you can a dual Xeon.
I’m a bit confused about HD = Track count, and Memory = samples.
I know when samples libraries are streamed they are put into RAM, but you’re saying the seek time of a drive effects how many tracks I have in Cubase? Aren’t tracks essentially samples loaded from kontakt, east west, etc.
When building my new PC should I be spreading my samples across ssds for libraries like hollywood strings? This library makes it seem like it’s mandatory and recommended by the company and every film composer I’ve spoken with.
I’d love to know your thoughts and if this will effect how many samples/tracks I can run simultaneously.
It’s hard to dissect what effects what exactly when everything is so correlated.
Basically most sample players use streaming technology. What this means is that they put a tiny part of the sample into memory and whilst that is being played the sample player grabs the next bit of audio off the drive. If you think of the size of sample libraries these days, there is a very good reason why they are not loaded completely into memory!
The main reason that some sample developers tell you to get SSD is that they are using multiple microphone positions. Therefore each note that you play has to drag multiple files off the disk, and this is why the disk needs to be fast. I do know some people using these sort of libraries without SSD, but they are only using one mike position. What I would suggest is finding out whether or not you can spread the mike positions over multiple drives. If so, this would mean that you wouldn’t need SSD.
There are two main other reason for using SSD. Firstly your samples will load much, much quicker, and if you are the sort of person who likes to re-start your computer many times a day, or swap projects quickly, then this can help. Personally I just use a VE Pro template, so changing projects is no problem, but if each project used a totally different set-up, then SSD would be more convenient. The second reason is that some sample players allow you to set your own pre-load buffer (that little bit of the sample that goes into the computer’s memory). Again, the advantage of this is that because SSD is so fast, you can reduce this amount from around 60kb to 4kb, in some cases. This will not only reduce your memory usage, but will also speed up loading of your projects. In this case do remember if you are using a sample player that allows you to automated start times (to get a quicker attack, for example) if the pre-load buffer is too small, you won’t be able to do this without pops and clicks, because the bit of the sample that you are wanting to play is not in memory. However, sometimes you will find that the developer has over-ridden the user-set pre-load value to avoid this problem, which is why people using SSD and a low pre-load buffer don’t find the the memory usage goes down as much as they expect.
One last thing. SSD have a very high failure rate, so if you go this route you have to be fastidious in backing up, as well as having spare drives, so that if yours does fail you can be up and running again in just a few minutes.
DG