Ive <"ive### [at] lilysoftorg"> wrote:
> Maybe just a much better cache access and/or jump prediction as a result
> of using multiple cores? There are e.g. a few SSE2 instructions just to
> optimize the memory access.

Hm... why should jump prediction or cache access suffer from running only a
single thread on a single core, while the other cores are basically just idle?

I'd agree if the system would keep rotating the thread among multiple cores to
keep an even load per core. But Linux doesn't: It keeps the thread "pinned" to
a single core, which can "calibrate" itself to run the POV code, without having
to "re-calibrate" due to task switches. There are plenty enough idle cores to
take care of any other task that might occasionally pop up.

On the opposite, a multi-core system maxed out by 4 POV-Ray threads, with not
much blocking to do, will be forced to do some task switching in order to
"squeeze in" other jobs; in addition, it will probably kick out the POV threads
alternatingly, so no single thread can run undisturbed, and I'd actually expect
assignment of threads vs. cores to change much more frequently.


> Proper aligned memory on 16-byte boundaries as a side effect when using
> 4 cores and misalignment when using just one?

Interesting theory. But I guess there are not many data structures that vary in
size depending on the thread count.


> Ok. Just wild thoughts,

I asked for it :)


I wouldn't bother much, if I didn't have the "gut feeling" that this effect
might be related to the overall dramatic slowdown seen in beta.30-rad1 with too
many scenes.

Post a reply to this message