2

Important computer specs (cpu clock, nr of cores/threads, ram, etc.) if you want rtrace to compute faster?

I am looking for a hardware solution that will be able to run rtrace, specifically illuminance (point-in-time and annual) simulations fast, relatively speaking. What is the optimum choice? For instance, multiple threads clocked lower or less threads clocked really high? Do ram or hard-drive have any impact too?

Iason Bournas's avatar
55
Iason Bournas
asked 2017-09-25 10:32:08 -0500
Aaron Boranian's avatar
14.1k
Aaron Boranian
updated 2021-01-25 11:24:36 -0500
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

4

The optimum depends on exactly what you're trying to do. Specifically, how many jobs are you trying to run at a time, and how much of your job can be run in parallel. Amdah's Law describes the maximum speedup you can expect depending on your clock speed and number of threads.

More specific to rtrace, it matters whether you are running multiple simulations simultaneously, or spawning processes from one master process (which you can't do on Windows). Do you know if you are RAM limited (for instance, are you considering a large number of bounces or a large number of ambient divisions in a model of unusually large size)? You might want to monitor the RAM usage of one of your simulations to see if this is actually an issue for you. If you require a very large amount of memory (for instance, using photon mapping) then you might want a solid state drive for faster read/write access.

At the high end of the performance spectrum, you could use GPU computing through Accelerad. This is most useful if you have a large number of sensor points in your model because parallelism occurs at the primary ray level. Then you'll want to consider the CUDA core count and clock speed of your GPU, and you may also need a little more RAM for data transfer.

Nathaniel Jones's avatar
531
Nathaniel Jones
answered 2017-09-25 12:07:42 -0500
edit flag offensive 0 remove flag delete link

Comments

Thank you for the feedback Nathaniel, Amdah's Law explains a lot. I only run one simulation at a time, max 300 sensors. Honeybee allows for multiple threads, but i do not know what is the rtrace serial part. I may have to wait 3 hours for a calculation but i am not sure how much of these 3 hours is serial and how much is parallelised. If rtrace uses only one core during 2 out of 3 hours then multiple cores might not be the solution, right?. I have had no RAM issues (relatively small models). I have followed Accelerad (nice work btw) but i typically simulate for limited nr of sensors.

Iason Bournas's avatar Iason Bournas (2017-09-25 12:58:14 -0500) edit
add a comment see more comments
2

If you are running just "one [300 analysis point] simulation at a time" consider using the -n flag of
rtrace. For n, choosing the maximum # of threads your CPU can run at once will be optimal-- e.g. 2, 4, 8, etc. If you also want to be doing other CPU intensive tasks on your computer, though, lower this number accordingly :).

I agree with Nathaniel to monitor RAM too.

Dan Glaser's avatar
81
Dan Glaser
answered 2017-09-25 13:46:18 -0500, updated 2017-09-25 13:48:21 -0500
edit flag offensive 0 remove flag delete link

Comments

Thank you Dan, i will follow your advice, and Nathaniel's.

Iason Bournas's avatar Iason Bournas (2017-09-25 14:21:12 -0500) edit

YW. I'm not familiar with how Honeybee chains into rtrace (can you share the commands it executes?), but you can watch your CPU/logical processor usage. There are pre- and post-processing events like oconv that may only run on 1 CPU. But if your jobs on small models are for 3 hours, I assume 99% of it is rtrace, and you should see a benefit from its built-in -n accelerator.

Dan Glaser's avatar Dan Glaser (2017-09-25 15:17:33 -0500) edit

I am not familiar either, but i ran some tests since this discussion and it seems that more threads decrease simulation time, so it must be -n flag connected. I believe there is documentation on Honeybee here. Thanks again Dan.

Iason Bournas's avatar Iason Bournas (2017-09-25 15:42:01 -0500) edit
add a comment see more comments