[BUG] Epic multithreading fail in PT Mode ***FIXED in v3***

[Zom-B]

I just bought a new AMD 1090T CPU to upgrade my system from a AMD 945.

two more cores and +0.2Ghz higher clocked.... nice, so letzt Benchmark this Baby I thought.
After the first tests I thought I did something wrong, only 5% faster then the old CPU... wtf!?!?

So I did a simple test... opened the testscene of Psor, changed CPU allocation in the Task manager to 1 Core, and run a 1min benchmark (Indigo 2.4.12!).
I repeated this, raising Core allocation by 1 each time... here are the ugly numbers:

1 Core: 89k
2 Core: 155k
3 Core: 193k
4 Core: 209k
5 Core: 215k
6 Core: 217k

Benchmark with Cinebech gave me a reasonable good result, the older 4x3GHz CPU did 210k on this scene btw...
A test on my iMac with Vista on it scaled fine 1Core: 63k, 2Core: 127k

It could be that this problem is related to that issue...

if there is something else I can provide, just tell me!
I really hope to see this problem solved quickly... I want my 500k samples/sec that I deserve

[Zom-B]

Ok, more testing & interesting results:

This time I tried to go from default BiDir PT to pure MLT, also raised the benchmark time to 3min, since MLT raises samples/s slower:

1 Core: 153k
2 Core: 234k
3 Core: 496k
4 Core: 661k
5 Core: 829k
6 Core: 993k

As you also can see, the performance not raises even more with each additional core, this is maybe because of using Task Manager for Thread-Control... Indigo still starts 6 Threads.

It seems that only PT mode scales that bad... I hope this doesn't affect the GPU version either.

[pixie]

I think glare is abusing of windows most known function donothing(), it's one of the reasons that windows seems so slow, it's done on purpose!

[StompinTom]

I think glare is abusing of windows most known function donothing(), it's one of the reasons that windows seems so slow, it's done on purpose!

Haha! Is that sort of like the eatprocessortimefornoreason() function?

[pixie]

Haha! Is that sort of like the eatprocessortimefornoreason() function?

The best family functions produced for windows, like, ever! In the end it's all part of the master plan!

[Zom-B]

Just wanted to bump this...

Can somebody with a AMD system confirm this issue??

[OnoSendai]

I did some testing of this on my I7. Rendering speed increased approximately linearly with the number of threads for the first 4 threads, then increased approximately linearly but at a slower rate over the next 4 (hyperthreaded / virtual core) threads.

[Zom-B]

This seems not to effect i7 systems at all, therefor I look for AMD people to give it a quick benchmark!
Some testing on a 4 Core AMD would be nice too... anybody?

[ENSLAVER]

I don't think any renderer will ever scale linearly, the more cores, the more overhead. Probably expect the curve to be more linear but it's one of those things, not sure how other renderers scale compared to indigo.

AMD phenomx4 (random simple scene)

PT
1 Core/s: 73K
2 Core/s: 125K
3 Core/s: 156K
4 Core/s: 168K

MLT
1 Core/s: 128K
2 Core/s: 275K
3 Core/s: 395K
4 Core/s: 523K

+1.2 ghz overall is not a huge jump, specially spread across more cores. It seems reasonable to expect a greater increase in speed though. Zom-B have you done some other benchmarks on the old cpu to compare it against the new? Maybe something is off in the setup.

[Zom-B]

I don't think any renderer will ever scale linearly, the more cores, the more overhead. Probably expect the curve to be more linear but it's one of those things, not sure how other renderers scale compared to indigo.

The gain with multiple CPU Cores should be very linear for a raytracer, it is on a Intel at least (also on Ono's system)!
So your Benchmark prove my theory about PT racism against AMD CPUs

I+1.2 ghz overall is not a huge jump, specially spread across more cores. It seems reasonable to expect a greater increase in speed though. Zom-B have you done some other benchmarks on the old cpu to compare it against the new? Maybe something is off in the setup.

I just tested some of my own scenes for speed comparison before selling the older x4, and my scenes use MLT+BiDir quite always...

[Headroom]

The reason for the difference could be manyfold. The Athlon 6-core processors have 3 MB 2nd level cache and 6MB 3rd level cache while the Intel 6-cores (i7 980x for example) have 1MB 2nd level cache but 12MB 3rd level cache. IIRC there is also a difference as to how that is shared between the different cores. I believe that in the AMD processors all cores share the same cache memory but the Intel processors some of the cache memory is dedicated to each core. That may explain why the difference seems to be mostly in PT.

Also compiler settings may make quite a difference. 10 years ago I ran a Redhat linux system on a DEC Alpha and tinkered a lot with compiling Povray using different compiler settings, different math libraries and compared results across different rendered scenes. These things made quite some difference and differed a bit from the "standard" compiler settings that were mostly aimed at Intel's processors.

There were some DEC Alpha optimized math libraries available (with hand optimized assembler code. Yeehaw) that made the most difference.

[Zom-B]

Also compiler settings may make quite a difference.

yes, this is something that could be optimized in Indigo for sure!
http://www.indigorenderer.com/forum/vie ... =5&t=10105

[Zom-B]

Just to keep this up to date I would like to announce that this bug was fixed in Indigo 3

To give ya some Numbers:
Erotica PT + BiDir: 761k samples/sec
Erotica pure PT: 875k samples/sec