I have tested 2 WU's from the l1_1336.0_..... serie.
1 using 4.02 and 1 using 4.24.
Both WU's was running with the same conditions.
On a P4 3066MHz. - Solo. - And in one go without stop.
The WU using 4.02 took 11 h 20 m (40800 sec) to complete. Done with Success.
The WU using 4.24 took 7 h 6 m (25560 sec) to complete. Done with Success.
Dimmerjas
Another non stop test of WU's from the same serie. (h1_0801.0_..).
This test on a P4 3.20 GHz.
With 4.02 the WU took 11 h 0 m to complete.
With 4.24 the WU took 7 h 10 m to complete.
So 4.24 is early 35% faster than 4.02.
My respect for the programming of 4.24. - Excellent job.
I have tested 2 WU's from the l1_1336.0_..... serie.
1 using 4.02 and 1 using 4.24.
Both WU's was running with the same conditions.
On a P4 3066MHz. - Solo. - And in one go without stop.
The WU using 4.02 took 11 h 20 m (40800 sec) to complete. Done with Success.
The WU using 4.24 took 7 h 6 m (25560 sec) to complete. Done with Success.
Dimmerjas
Another non stop test of WU's from the same serie. (h1_0801.0_..).
This test on a P4 3.20 GHz.
With 4.02 the WU took 11 h 0 m to complete.
With 4.24 the WU took 7 h 10 m to complete.
So 4.24 is early 35% faster than 4.02.
My respect for the programming of 4.24. - Excellent job.
Dimmerjas
Ups!
The fifth line should say:
So 4.24 is nearly 35% faster than 4.02.
My respect for the programming of 4.24. - Excellent job.
Dimmerjas
My sentiments also.
Thanks for making all my X1's into X2's and my X2 into an X4 (as soon as I work off the cache).
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
How many of them have you met? How many compilers have you written on your own? If I would have to write a compiler for this worse-of-all x86 architecture, I would really be happy if this would give me anything working (and conforming to the standards) at all.
I've not seen any speedup with the current code on the Intel Mac where we use Apples's modified gcc, but actually a slight slowdown. Seems that this compiler knows the CPU better than we.
Bruce has made the Beta Apps 4.17 and 4.24 official. You can now remove the app_info.xml and restart the client to switch back to the official, auto-update path.
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
How many of them have you met? How many compilers have you written on your own? If I would have to write a compiler for this worse-of-all x86 architecture, I would really be happy if this would give me anything working (and conforming to the standards) at all.
Sorry for having been that harsh. But I don't like to talk bad about people which I don't know, or to judge their work when I don't know the problems they're facing at it. And I'm especially sensitive when these people are of my kind (programmers).
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
How many of them have you met? How many compilers have you written on your own? If I would have to write a compiler for this worse-of-all x86 architecture, I would really be happy if this would give me anything working (and conforming to the standards) at all.
Sorry for having been that harsh. But I don't like to talk bad about people which I don't know, or to judge their work when I don't know the problems they're facing at it. And I'm especially sensitive when these people are of my kind (programmers).
BM
Seems as if everybody needs to calm down...
@BM
Could you get your hands on the intel compiler for OSX ? That would really speed thins up.
Could you get your hands on the intel compiler for OSX ? That would really speed thins up.
I doubt that. It didn't help much with earlier code, and it refuses to compile the current one "cannot allocate registers for asm statement". I'll plan to look into that later this week again.
Edit: I expect a bit more from the SSE2 stuff I'm coding right now, but I may also be wrong there. Thanks to Akos, we have now reached a level of optimization where the effects of any change (on the speed) are hard to predict - just try and see. And it gets very different for different CPUs. Luckily all the Intel Macs have (more or less) the same.
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
How many of them have you met? How many compilers have you written on your own? If I would have to write a compiler for this worse-of-all x86 architecture, I would really be happy if this would give me anything working (and conforming to the standards) at all.
Sorry for having been that harsh. But I don't like to talk bad about people which I don't know, or to judge their work when I don't know the problems they're facing at it. And I'm especially sensitive when these people are of my kind (programmers).
BM
No need to apolgise. Compiler design is a 'There but for the grace of God go I' form of development.
I doubt that. It didn't help much with earlier code, and it refuses to compile the current one "cannot allocate registers for asm statement". I'll plan to look into that later this week again.
BM
Depends on what calculations are beeing done with the einstein app. icc ins't the only way to go... Tried ipp or mkl ? (Both should e available for OSX now too).
At least i'd expect a boost on the new intel core 2 duo macs. (should ease some of the development regarding the use of sse(X)... At least you're not using apples "accelerate headers/libs" etc...
Anyhow... is it possible to use some "stuff" from ipp or even mkl for both i386 and mac apps on the E@h app ???
(Just curious or is writing asm code the best way to go ?)
RE: I have tested 2 WU's
)
Another non stop test of WU's from the same serie. (h1_0801.0_..).
This test on a P4 3.20 GHz.
With 4.02 the WU took 11 h 0 m to complete.
With 4.24 the WU took 7 h 10 m to complete.
So 4.24 is early 35% faster than 4.02.
My respect for the programming of 4.24. - Excellent job.
Dimmerjas
RE: RE: I have tested 2
)
Ups!
The fifth line should say:
So 4.24 is nearly 35% faster than 4.02.
RE: My respect for the
)
My sentiments also.
Thanks for making all my X1's into X2's and my X2 into an X4 (as soon as I work off the cache).
Makes you wonder about the state of the art of compiler writers.
They must be from the "it works so what else do you want" school.
Take away all their stock options.
RE: Makes you wonder about
)
How many of them have you met? How many compilers have you written on your own? If I would have to write a compiler for this worse-of-all x86 architecture, I would really be happy if this would give me anything working (and conforming to the standards) at all.
I've not seen any speedup with the current code on the Intel Mac where we use Apples's modified gcc, but actually a slight slowdown. Seems that this compiler knows the CPU better than we.
BM
BM
Bruce has made the Beta Apps
)
Bruce has made the Beta Apps 4.17 and 4.24 official. You can now remove the app_info.xml and restart the client to switch back to the official, auto-update path.
Thanks a lot for participating in this Beta Test!
BM
BM
RE: RE: Makes you wonder
)
Sorry for having been that harsh. But I don't like to talk bad about people which I don't know, or to judge their work when I don't know the problems they're facing at it. And I'm especially sensitive when these people are of my kind (programmers).
BM
BM
RE: RE: RE: Makes you
)
Seems as if everybody needs to calm down...
@BM
Could you get your hands on the intel compiler for OSX ? That would really speed thins up.
RE: Could you get your
)
I doubt that. It didn't help much with earlier code, and it refuses to compile the current one "cannot allocate registers for asm statement". I'll plan to look into that later this week again.
Edit: I expect a bit more from the SSE2 stuff I'm coding right now, but I may also be wrong there. Thanks to Akos, we have now reached a level of optimization where the effects of any change (on the speed) are hard to predict - just try and see. And it gets very different for different CPUs. Luckily all the Intel Macs have (more or less) the same.
BM
BM
RE: RE: RE: Makes you
)
No need to apolgise. Compiler design is a 'There but for the grace of God go I' form of development.
RE: I doubt that. It
)
Depends on what calculations are beeing done with the einstein app. icc ins't the only way to go... Tried ipp or mkl ? (Both should e available for OSX now too).
At least i'd expect a boost on the new intel core 2 duo macs. (should ease some of the development regarding the use of sse(X)... At least you're not using apples "accelerate headers/libs" etc...
Anyhow... is it possible to use some "stuff" from ipp or even mkl for both i386 and mac apps on the E@h app ???
(Just curious or is writing asm code the best way to go ?)