Hello,
We’re considering purchasing Krakatoa, along with a few more render machines. I have the option of purchasing a few render machines which have 24 cores, or more instances of 8 core machines … in everyone’s experience would Krakatoa make good use of such an amount the cores in one machine ?.
All the best,
ben
Hi Ben,
As I understand, it’s not just about having CPU power, as Krakatoa is quite dependent on how fast it can handle i/o and also available RAM which would get divided up per core in use.
Bobo’s written some interesting blog articles touching on this subject: viewtopic.php?f=22&t=3756&hilit=performance
Bobo also mentioned the “benchmarking script” back in Sept. 2009, which would be nice to share as a ‘standard series of tests’ and perhaps provide performance results back to everyone on the forum so other people can see for themselves what makes the biggest performance differences, taking into account different people’s spec machines. Personally, I’ve seen some remarkable performance jumps with our 24 core blades across the board, especially with VRay.
Regards,
Mike
Thanks very much Mike, I’ll look those over now.
We’re testing one 24 core 12GB machine, which costs roughly the same as 2x 8core 8GB machine and we’re seeing pretty much a half in V-Ray render times. ie the cost is the same for the render power whether you buy 1x 24core or 2x 8core. However we are finding them hugely useful as a distributed render machine, each artist can hook into just one machine for test renders.
cheers
ben
Hi Ben,
We haven’t tested Krakatoa on more than 8 cores here, so I cannot speak from experience.
The rendering process of Krakatoa, as Mike mentioned, can be very I/O dependent, specifically when using PRT file sequences.
In many cases, the loading time of the particles can take up to half the total rendering time.
In version 1.6.0, the following processes are fully multi-threaded: Evaluation of MagmaFlow nodes, Evaluation of Materials/Maps, Sorting of particles, Drawing of particles for Light Attenuation, Drawing of particles for Final Pass, Drawing of polygons into Z-buffer for Matte objects. In addition, the loading of particles runs on two threads currently, so it does not scale with core count.
On an 8 core machine, we saw the drawing performance of Krakatoa go up to about 17.5 Million particles per second, but the loading time is still the same as in previous versions. Thus, if you look at the tables posted here software.primefocusworld.com/sof … v1.6.0.php you will see that the drawing performance in 1.6.0 with 8 cores can be up to 6 times faster, but the TOTAL performance taking into account the loading of particles is only up to 3 times faster.
So using 3 times more cores (24 instead of 8) will NOT result in 3 times more performance in Krakatoa, probably not even 2 times more. The drawing itself WILL scale linearly though. So if you take the example from the table
Description Loading L.Sorting Attenuation Sorting Drawing TOTAL
v1.6.0, 10 PRT Loaders, 3 Spots, PCache OFF, 95MP 140.094s 43.921s 44.094s 12.375s 12.625s 257.282sthen the Loading time will remain 140 seconds, the Sorting will probably go down to about 15s, Attenuation will take about 4, Final Pass Sorting about 5, Drawing 4 seconds, total time will be around 168 seconds, or a speedup factor of around 1.53x. So in the best case, 24 cores will render 95 million particles 1.5 times faster than 8 cores, which is probably a waste. In other words, 2 machines with 8 cores each will render a sequence faster than 1 machine with 24 cores.
But only a real-world benchmark can tell. Generate 100 million particles and try to render with 8 cores and 24 cores and measure. Then let us know 
I personally would suggest 24 cores for workstations (interactive work) and 8 core machines for network rendering. But if you have the funds, buy the former for network rendering as they have more RAM.
Hi bobo,
Many thanks for your response, my apologies for not replying earlier. I’ll let you know how we fair with the 24 core machines. We have found that for fume they seem to make a big difference, and hopefully in the future vray and max will make better use of them.
It’s interesting you mention the io overhead, we are thinking of creating a dedicated server for PRT files as so far they seem huge and we’re to eat up server space. My first thought was to create a cheap server, (as our main data server is an isilon clustered system, expanding that is costly), however I guess that’ll be slow. I’d be interested to know how others tackle the io issue.
A
In my humble opinion I would love a PRT/Sim dedicated store if:
It had mega fast drives.
100 gig ethernet, mmmnn dual fibre channel. (this will seem a silly statement in a few years)
Optimized for constant rapid I/O.
And on a small LAN… no need to send packets halfway around the world before it finds your local server in the next room 
If it was cheap that would be a bonus 
(not to say that it would be that expensive)