64bit+2.3+lot of memory+lot of cpu

Started by ndeewolfwood, August 04, 2011, 10:16:00 AM

Previous topic - Next topic

ndeewolfwood

I wondered if the recommendations made ​​concerning the use of memory are still valid for version 2.3.

for example.
For a machine with 16 core and 16 go:
is it always a good idea to make an animation made ​​by dividing the render between 2 terragen launched at the same time, or can we now render using the 16 hearts and hope to see a significant time savings.

With 2.1 for example : it was faster to render 2 pictures with 2 terragen with 8 core for each (or 2 crop) than 1 render with 16 core.

Tangled-Universe

Here you go:
http://forums.planetside.co.uk/index.php?topic=11545.msg121102#msg121102

If I would have a 16 thread machine I would split the workload over 2 instances of TG2, each using 8 threads max.
4 instances with 4 threads is closest to the ideal situation, but that would mean memory resources need to be shared among more instances which is not always favorable.
Also it isn't really nice to work in 4 instances simultaneously, but that's a personal matter.
The gain is also not that big.

ndeewolfwood

Thanks for your help and links.
just one more question.
whats the difference between core setup in terragen preference and the min max thread in the render tab ?

Tangled-Universe

Quote from: ndeewolfwood on August 04, 2011, 02:59:43 PM
Thanks for your help and links.
just one more question.
whats the difference between core setup in terragen preference and the min max thread in the render tab ?

You're welcome :)

The core setup (can automatically) detect the number of physical cores. If one has an Intel cpu with hyper-threading then TG2 will recognize it as a physical core.
Easily put you can consider each core to be able to run one thread. In case of hyper-threading each core in the cpu will process 2 threads, but TG2 considers this as a physical core.
So, cores = threads in TG2.

With min threads you tell how many threads to create at least...max threads does the same for the max of threads allowed. Basically you can force TG2 to create more threads than you have cores, by setting minimum threads greater than the number of cores. This usually creates overhead since the threads need to wait for each other until data has been processed by each core.

jo

Hi,

Quote from: ndeewolfwood on August 04, 2011, 02:59:43 PM
whats the difference between core setup in terragen preference and the min max thread in the render tab ?

As Martin says TG2 will automatically detect the number of processor cores on your machine. On a machine with Hyperthreading each real core counts as two cores. Normally TG2 will create one thread per core for rendering.

There are two ways to explicitly control how many threads TG2 will use during rendering. One is to change the thread settings in the Advanced tab of the Render node. This is useful if you want to control this on a node-by-node or project-by-project basis.

The other way is to change the settings in the preferences. If you do this then TG2 will use the number of cores you specify instead of the number of cores it detects at startup. Let's say you have a 16 core machine but for some reason you always want to render with 8 cores. If you set the core preference to 8 cores then 8 cores will be used without you having to change any of the render node settings.

You might think of the settings as working at two levels. The automatic core detection or core preferences are the bottom level, where TG2 decides the basic resources available for rendering. The Render node thread settings are at a higher level and the settings you have there can override the lower level core settings.

Regards,

Jo

jo

Hi,

Quote from: ndeewolfwood on August 04, 2011, 10:16:00 AM
I wondered if the recommendations made ​​concerning the use of memory are still valid for version 2.3.

I'd just like to clarify that suggestions that you split animation renders across two instances was never something to do with memory usage but rather to do with CPU usage. Using two instances can lead to better CPU usage and therefore faster rendering. I've done tests where it's a bit faster but sometimes it's a bit slower. It depends on your scene. If you're going to render a long animation it might be worthwhile doing a test run with a small number of frames to see what's best.

Memory usage is potentially an issue though. I haven't really tried this out but theoretically if you have two instances which are both using a lot of memory then you might find things start to slow down, perhaps dramatically. This is because the two instances will gobble up your physical RAM more quickly than one instance and this could lead to virtual memory being used which is really, really slow. If you have a lot of RAM and your scene doesn't use more than half of it then you should be able to run two instances without problems. If it's using a lot more than half your RAM then it could end up slowing things down. Again I should say I haven't tried this but that's how I think it would work.

Regards,

Jo

neon22

I have found that there is a strong relationship between number of cores and the tile size that each core renders.
If you have a lot of cores - I assume you should lower the tile size.

Reasoning:
In an image there may be a section which takes longer to render. If the cores finish the image unevely, then all cores, but one, are sitting there doing nothing while the last one finishes.
Turns out if you lower the render tile size - the cores will balance better.
Of course - if you lower it too much - you waste setup time on each tile.
I haven't worked out the overhead yet. Also I want to do some tests. I assume(?) that doing a test at a low quality setting will also reflect the percentages for a high quality - but this remains to be proved.

jo

Hi neon,

In my own basic testing, and I think this was borne out by some testers, dropping the bucket size to 128 x 128 can be faster for some scenes and pretty much for the reason you mention about keeping more cores working for longer. However going much smaller than that can cause things to get slower.

Your tool would be a good way to test that of course :-). I'm not sure how representative lower quality renders would be of higher quality ones.

Regards,

Jo