I am sorry if I am wearing anyone out but the idea of these multithread tests is to see if a speed increase can be achieved on a dual core processor using multiple threads. This test piece does two tests, the first uses 2 threads to alternately zero fill a memory bufer and them write data to the buffer while the other bufer is being zero filled again. The second test does the two operations sequentialy in a single thread without any thread overhead.
On my single core PIV the threaded version is about 5% slower which is predictable, what I need to find out is if there is a speed increase with a dual core processor using two alternate threads.
This is the timing on my dev box, a single core PIV.
Thread started
Thread started
-----------------
Two thread tining
-----------------
2109 ms duration
-----------------
One thread tining
-----------------
2047 ms duration
Press any key to continue ...
[attachment deleted by admin]
Thread started
Thread started
-----------------
Two thread tining
-----------------
2422 ms duration
-----------------
One thread tining
-----------------
2219 ms duration
Press any key to continue ...
Dual Core - Intel Core2 Duo T7200 at 2Ghz
Multiple threads are not faster even with dual core CPU's
Thanks Bogdan,
I wonder if there is a way to test if the two threads are running on seperate cores ? Somewhere vauely I remember there being API functions that gave you the capacity to pick which core was being used but I forget where i saw it.
Pentium D 940 (3.2 GHz)
Thread started
Thread started
-----------------
Two thread tining
-----------------
1734 ms duration
-----------------
One thread tining
-----------------
1594 ms duration
I can see it using both cores in Performance Monitor.
As far as the APIs, I don't know, without researching it.
Thanks Greg,
Sad to say it looks like the idea is a flop, it would probably be interesting to find out why it is no faster if it is being processed by both cores but then its probaby not worth the effort bothering.
Q6600 2.4GHz on XP Home SP2
Thread started
Thread started
-----------------
Two thread tining
-----------------
2031 ms duration
-----------------
One thread tining
-----------------
1969 ms duration
Quote from: hutch-- on April 23, 2008, 03:44:49 AM
I wonder if there is a way to test if the two threads are running on seperate cores ? Somewhere vauely I remember there being API functions that gave you the capacity to pick which core was being used but I forget where i saw it.
SetThreadAffinityMask maybe?
intel core2duo 2.66Ghz - 1333mhz/4M
Thread started
Thread started
-----------------
Two thread tining
-----------------
1531 ms duration
-----------------
One thread tining
-----------------
1500 ms duration
Press any key to continue ...
Thread started
Thread started
-----------------
Two thread tining
-----------------
1750 ms duration
-----------------
One thread tining
-----------------
1782 ms duration
Press any key to continue ...
i added
SetThreadAffinityMask in start_fill_thread in order to select a cpu for the thread
Quote from: hutch-- on April 23, 2008, 04:19:01 AMSad to say it looks like the idea is a flop, it would probably be interesting to find out why it is no faster if it is being processed by both cores but then its probaby not worth the effort bothering.
I think it's quite obvious that it's RAM bandwidth limited.
Do you think there might be a change if you set the affinity?
Hutch what about if you simultanously write to ram with one thread and to a ddraw vram surface with second thread?
Magnus,
Its worth a try as the memory does not overlap and should use different paths as well. I think c0d1f1ed is correct that its a memory access/bandwidth issue in the test piece even though the two addresses should be far enough apart was slower on both a single processor and Core 2 Duos.
Two thread: 2106 ms
One thread: 2231 ms
this is on a quad core cpu.
two threads evidently seems to be faster for me.
By removing the second 'double-fill' operation from the two-thread timing and increasing the loop count to 16 I get about a 20% advantage for the two-thread fill. There's about 5-10% the other way when the original code is used.
To be honest, I can't figure that out. My guess would be that ResumeThread() is slow. It is not intended for use outside of a debugging context, so perhaps using waitable objects (an event, most likely) would provide some improvement.
Cheers,
Zooba :U