Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » Hydra is FAST
| Hydra is FAST [message #2385] |
Mon, 10 April 2006 11:35  |
hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
|
Experienced Member |
|
|
I tested Hydra settings on a P4 2800 Mhz with 2 Hyper Threading units. Compilation times for recompiling the CodeMetric example:
1 Thread: 2.30
2 Threads: 2.12
3 Threads: 2.02
4 Threads: 1:17
5 Threads: 1:13
6 Threads: 1:10
7 Threads: 1:16
8 Threads: 5:51
It seems that it is good to set thread count higher than number of CPU cores. Best result was achieved with 6 threads.
|
|
|
|
|
|
| Re: Hydra is FAST [message #2387 is a reply to message #2385] |
Mon, 10 April 2006 12:59  |
hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
|
Experienced Member |
|
|
I rerun these test. The results seems to vary greatly. In the second run the winner was 2 threads, and in the third run winner was 3 threads but only with a small amount ahead of 2 threads.
1 Thread: 2.30 1.27, 1.30
2 Threads: 2.12, 1.10, 1.14
3 Threads: 2.02 1.13, 1.13
4 Threads: 1:17 1.12, 1.19
5 Threads: 1:13 1.12, 2.52
6 Threads: 1:10 2.32
7 Threads: 1:16
8 Threads: 5:51
I did all these tests the same way, by clicking the bomb icon in the same example after modifying the thread setting. Maybe some of the wild time values could be caused by some files becoming old enough between test runs to used in BLITZ compilations, but even with that the results are quite inconsistent. I suppose this could be tested automatically by compiling with every thread setting 10 times, and averaging, but I don't have the patience for that. Given all this inconsistency the only conclusion I can make is that 2 threads was always faster than 1 thread.
|
|
|
|
| Re: Hydra is FAST [message #2388 is a reply to message #2387] |
Mon, 10 April 2006 14:55 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| hojtsy wrote on Mon, 10 April 2006 06:59 |
I rerun these test. The results seems to vary greatly. In the second run the winner was 2 threads, and in the third run winner was 3 threads but only with a small amount ahead of 2 threads.
1 Thread: 2.30 1.27, 1.30
2 Threads: 2.12, 1.10, 1.14
3 Threads: 2.02 1.13, 1.13
4 Threads: 1:17 1.12, 1.19
5 Threads: 1:13 1.12, 2.52
6 Threads: 1:10 2.32
7 Threads: 1:16
8 Threads: 5:51
I did all these tests the same way, by clicking the bomb icon in the same example after modifying the thread setting. Maybe some of the wild time values could be caused by some files becoming old enough between test runs to used in BLITZ compilations, but even with that the results are quite inconsistent. I suppose this could be tested automatically by compiling with every thread setting 10 times, and averaging, but I don't have the patience for that. Given all this inconsistency the only conclusion I can make is that 2 threads was always faster than 1 thread.
|
Well, those results look much more believable....
In fact, if you take best resutls, it now looks like 2 and more threads a little bit faster than single one (something one would expect on HT CPU), but not by large margin.
Still, I have not seen compile times so much erratically changing yet....
Mirek
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 01:52:09 CEST 2024
Total time taken to generate the page: 0.04013 seconds
|
Members
Pages
Help
Register
Login
Home
