Dear all:
I am trying to use Radiance on a super computer of our university. The super computer has 128 CPUs, and it should be very fast. But I found the rendering speed is almost the same as my notepad. A stuff of the super computer center tried to analysis the rendering process, and found out that most time was not taken by computation, but by outputing data to files. I think writing data to the .unf file must take a lot of time. Is there any way to solve this problem?
Yours,
Huang
Huang,
Your calculation uses just one of these 128 CPUs, if you don't use the program rpiece. The amount or RAM is not really an issue. Check the man page for rpiece and ask your system administrator to help you set up a batch file for it.
Rview and rtrace are not parallized at this time, I believe.
Martin Moeck
________________________________
From: [email protected] on behalf of Huangwx
Sent: Thu 1/19/2006 7:23 AM
To: [email protected]
Subject: [Radiance-general] output to .unf file
Dear all:
I am trying to use Radiance on a super computer of
our university. The super computer has 128 CPUs,
and it should be very fast. But I found the rendering
speed is almost the same as my notepad. A stuff of
the super computer center tried to analysis the rendering
process, and found out that most time was not taken by
computation, but by outputing data to files. I think
writing data to the .unf file must take a lot of time.
Is there any way to solve this problem?
Yours,
Huang
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hello Huang,
If you offer some details about how you set up your calculations, your rendering parameters, etc., I'm sure there are people on this list who could help you.
-Greg
From: "Huangwx" <[email protected]>
Date: January 19, 2006 4:23:43 AM PSTDear all:
I am trying to use Radiance on a super computer of our university. The super computer has 128 CPUs, and it should be very fast. But I found the rendering speed is almost the same as my notepad. A stuff of the super computer center tried to analysis the rendering process, and found out that most time was not taken by computation, but by outputing data to files. I think writing data to the .unf file must take a lot of time. Is there any way to solve this problem?
Yours,
Huang
dear all:
I am using a supercomputer which has 128 CPUs, and should be very fast. But I found the rendering speed is almost the same as my notepad. A stuff of the super computer said that most time was not taken by computation, but by outputing data to files. I think writing data to the .unf file must take
a lot of time. The supercomputer uses NFS storage, so maybe because it is too slow, the rendering cannot be finished quickly. If there is any
way that radiance do not use the NFS storage during rendering, but only the memory, I think the speed could be greatly improved.
The rendering parameters in .opt file:
-dp 256
-ar 28
-ms 2.6e+02
-ds .3
-dt .1
-dc .5
-dr 1
-sj .7
-st .1
-ab 2
-af day.amb
-ad 329
-as 42
-av 0.36 0.36 0.36
-lr 8
-lw .002
-st .001
-dj .02
-aa 0.25
The image size: 256x176
Thank you very much.
Yours,
Huang.
dear all:
I am using a supercomputer which has 128 CPUs, and should be very fast.
But I found the rendering speed is almost the same as my notepad.
As in life, mere size doesn't matter.
As Martin already said, you have to use the programm "rpiece" not
"rpict" to use more than one CPU. I don't remember the status of
"rpice" on SMP systems but I don't think it will scale up to 128
CPUs.
A stuff of the super computer said that most time was not taken by
computation, but by outputing data to files. I think writing data
to the .unf file must take a lot of time. The supercomputer uses NFS
storage, so maybe because it is too slow, the rendering cannot be
finished quickly.
I tested the settings you give below and on my 2GHz PowerPC
("Core Solo") the daffodil test scene ran about 3 seconds.
If you have similar times on your system, saving image data
on a slow NFS system may indeed have an impact on your process.
But that's a problem of your NFS then, not of Radiance.
If you can set up a RAM disc on your nodes you could use that
to store the image computed on one node and copy the final
image to the shared storage space. But I don't think that's
possible on a managed cluster. (Perhaps there is a /tmp FS
local to each cluster node?) But you still have to share
your ambient data (in the day.amb file) across all nodes to
get the real benefit of multiple cpus.
Given your settings your need for render speed is _not_
render quality (pretty low). As well your image dimensions
are small. What are you trying to render in the end?
If it's an animation you could use "ranimate" to distribute
frame rendering to separate nodes explicitly.
If there is any way that radiance do not use the NFS storage
during rendering, but only the memory, I think the speed could
be greatly improved.
You should share your ambient data (in the "day.amb" file)
between all nodes to get the benefit of multiple CPUs and to
avoid variations between frames or image parts. If this slows
down your system don't use the "-af day.amb" option and
rpict will use the memory during calculations (on each node
separately).
The image data is written to STDOUT by rpict. If you can
redirect to a local FS on each node you don't have to use NFS
all the time (like I said "/tmp" may be a local FS on each node).
Don't forget to copy the final image to your NFS area, though.
I use RAM discs when I have do create a lot of small files
for a short time only. Speed has not been a consideration,
only HD movements and noise.
Your settings for reference. You should provide information
about your rendering setup (which commands, control files)
and what you actually want to do (BIG image vs. animation vs.
high detail rendering) on the cluster, too.
The rendering parameters in .opt file:
-dp 256
-ar 28
-ms 2.6e+02
-ds .3
-dt .1
-dc .5
-dr 1
-sj .7
-st .1
-ab 2
-af day.amb
-ad 329
-as 42
-av 0.36 0.36 0.36
-lr 8
-lw .002
-st .001
-dj .02
-aa 0.25
The image size: 256x176
HTH,
Thomas
On 23.01.2006, at 06:56, Huangwx wrote: