Actually I think the question applies to all renderers. I was wondering about
this when I noticed one of my scenes was using up almost 3 GiB of memory. What's
the time ratio between the CPU doing calculations and the CPU waiting for the
data fetch to complete?

Post a reply to this message

jhu schrieb:
> Actually I think the question applies to all renderers. I was wondering about
> this when I noticed one of my scenes was using up almost 3 GiB of memory. What's
> the time ratio between the CPU doing calculations and the CPU waiting for the
> data fetch to complete?

I just did an experiment which might give a hint:

My Intel i7 QuadCore machine provides hyperthreading, that is each core 
can operate on two threads quasi-simultaneously, quickly switching 
between them in case one of them needs to wait for some not-on-chip 
component (such as main memory) to complete an operation.

Running with the default of 8 threads (i.e. fully utilizing the 
hyperthreading mechanism), POV-Ray 3.7 beta took 54 seconds to complete 
a particular scene.

Running with only 4 threads (i.e. utilizing all cores, but not 
hyperthreading), the same scene took 87 seconds to complete.

I think this indicates that render threads do indeed spend quite some 
time waiting for memory accesses to complete, otherwise hyperthreading 
would not give much added benefit. OTOH I think it also shows that 
memory latency (i.e. the time it takes to complete a particular memory 
request) is more of an issue than memory bandwidth (i.e. the maximum 
speed at which memory content can be read), as hyperthreading cannot 
help with a memory bandwidth bottleneck either (it would only increase 
the number of threads standing by for data from the main memory).

Post a reply to this message

> jhu schrieb:
>> Actually I think the question applies to all renderers. I was
>> wondering about
>> this when I noticed one of my scenes was using up almost 3 GiB of
>> memory. What's
>> the time ratio between the CPU doing calculations and the CPU waiting
>> for the
>> data fetch to complete?
>
> I just did an experiment which might give a hint:
>
> My Intel i7 QuadCore machine provides hyperthreading, that is each core
> can operate on two threads quasi-simultaneously, quickly switching
> between them in case one of them needs to wait for some not-on-chip
> component (such as main memory) to complete an operation.
>
> Running with the default of 8 threads (i.e. fully utilizing the
> hyperthreading mechanism), POV-Ray 3.7 beta took 54 seconds to complete
> a particular scene.
>
> Running with only 4 threads (i.e. utilizing all cores, but not
> hyperthreading), the same scene took 87 seconds to complete.
>
> I think this indicates that render threads do indeed spend quite some
> time waiting for memory accesses to complete, otherwise hyperthreading
> would not give much added benefit. OTOH I think it also shows that
> memory latency (i.e. the time it takes to complete a particular memory
> request) is more of an issue than memory bandwidth (i.e. the maximum
> speed at which memory content can be read), as hyperthreading cannot
> help with a memory bandwidth bottleneck either (it would only increase
> the number of threads standing by for data from the main memory).

We need a computer with 3 GHz RAM and a 3 MHz hex core CPU. RAW bus 
speed, doubled using DDR, then tripled using triple channel... Add a 
little cache and you get almost no memory wait. Then, you put some 
dedicated stack buffers on the die to further reduce main memory access.


Alain

Post a reply to this message

Alain schrieb:

>> I think this indicates that render threads do indeed spend quite some
>> time waiting for memory accesses to complete, otherwise hyperthreading
>> would not give much added benefit. OTOH I think it also shows that
>> memory latency (i.e. the time it takes to complete a particular memory
>> request) is more of an issue than memory bandwidth (i.e. the maximum
>> speed at which memory content can be read), as hyperthreading cannot
>> help with a memory bandwidth bottleneck either (it would only increase
>> the number of threads standing by for data from the main memory).
> 
> We need a computer with 3 GHz RAM and a 3 MHz hex core CPU. RAW bus 
> speed, doubled using DDR, then tripled using triple channel... Add a 
> little cache and you get almost no memory wait. Then, you put some 
> dedicated stack buffers on the die to further reduce main memory access.

I guess with a 3 MHz CPU (even a hex core), crappy old DIL-socket RAM 
from the late '80s would be sufficiently fast to keep all cores busy :-P

Also note that neither memory clock speed nor DDR nor number of channels 
give you /any/ benefit at all if latency is your issue. All they do is 
increase your bandwidth (which, as pointed out before, doesn't seem to 
be such an issue with POV-Ray); latency hasn't improved much in recent 
years. Typically, the average high-speed super-RAM needs just so many 
more clock cycles to complete a read operation that the latency remains 
as bad as (or occasionally even worse than) what you'd get with slower 
chips.

So all that can be done about it is more L1 and L2 cache or praying for 
a RAM technology breakthrough.

Post a reply to this message

clipka wrote:
> a RAM technology breakthrough.

Or maybe a fundamental physics breakthrough. The reciprocal of three GHz is 
about 5 inches.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

clipka wrote:
> Also note that neither memory clock speed nor DDR nor number of channel
s
> give you /any/ benefit at all if latency is your issue. All they do is
> increase your bandwidth (which, as pointed out before, doesn't seem to
> be such an issue with POV-Ray); latency hasn't improved much in recent
> years. Typically, the average high-speed super-RAM needs just so many
> more clock cycles to complete a read operation that the latency remains

> as bad as (or occasionally even worse than) what you'd get with slower
> chips.
> 
> So all that can be done about it is more L1 and L2 cache or praying for

> a RAM technology breakthrough.

	Well, Rambus had a much lower latency than DDR...

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Darren New schrieb:
> clipka wrote:
>> a RAM technology breakthrough.
> 
> Or maybe a fundamental physics breakthrough. The reciprocal of three GHz 
> is about 5 inches.

How far away from the CPU are your memory modules?

5 inches should suffice in that respect; at worst, one could design a 
mainboard with the memory modules on the back side, just opposite the 
CPU (of course this would require a nonstandard casing, and probably 
different CPU sockets, too).

Compared to the lacenty of SRAM as such, the latency due to distance is 
still not much of a problem AFAIK.

Post a reply to this message

clipka wrote:
> How far away from the CPU are your memory modules?

How twisty are the wires inside?  How much heat do you have to dissipate 
(which is really more the problem)?

But sure, that's why Cray supercomputers are in a cylindrical shape - the 
bus in the middle is shorter that way.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> jhu schrieb:
> > Actually I think the question applies to all renderers. I was wondering about
> > this when I noticed one of my scenes was using up almost 3 GiB of memory. What's
> > the time ratio between the CPU doing calculations and the CPU waiting for the
> > data fetch to complete?
>
> I just did an experiment which might give a hint:
>
> My Intel i7 QuadCore machine provides hyperthreading, that is each core
> can operate on two threads quasi-simultaneously, quickly switching
> between them in case one of them needs to wait for some not-on-chip
> component (such as main memory) to complete an operation.
>
> Running with the default of 8 threads (i.e. fully utilizing the
> hyperthreading mechanism), POV-Ray 3.7 beta took 54 seconds to complete
> a particular scene.
>
> Running with only 4 threads (i.e. utilizing all cores, but not
> hyperthreading), the same scene took 87 seconds to complete.
>
> I think this indicates that render threads do indeed spend quite some
> time waiting for memory accesses to complete, otherwise hyperthreading
> would not give much added benefit. OTOH I think it also shows that
> memory latency (i.e. the time it takes to complete a particular memory
> request) is more of an issue than memory bandwidth (i.e. the maximum
> speed at which memory content can be read), as hyperthreading cannot
> help with a memory bandwidth bottleneck either (it would only increase
> the number of threads standing by for data from the main memory).

I just replaced my Athlon 64 LE-1640 (2.6 GHz) with an Athlon 2 x4 @ 2.8 GHz.
What I found puzzling was that the LE-1640 runs the benchmark scene in ~20
minutes whereas the the Athlon 2, despite being clocked higher, runs the scene
in ~ 25 minutes. All other factors on the software side are the same. The only
reason I can think of for the slower rendering time is that each core from the
Athlon 2 has 512k of L2 cache whereas the LE-1640 has 1024k of L2 cache.

Post a reply to this message