I believe the normal Win-Boxes of a user have a great overhead in functionality that never be used for any application like seti or einstein. This makes the system big and slower.
If you compile a linux system for your machine, you can select still these parts of the system that will be necessary to run the application. This makes compact and effective systems without any overhead. And when you compile the kernel you can choose processorspecific propertys like SSE2 etc. to produce a optimal code for your machine.
Therefore I think the linux system is more effective than any windows application.
I believe the normal Win-Boxes of a user have a great overhead in functionality that never be used for any application like seti or einstein. This makes the system big and slower.
If you compile a linux system for your machine, you can select still these parts of the system that will be necessary to run the application. This makes compact and effective systems without any overhead. And when you compile the kernel you can choose processorspecific propertys like SSE2 etc. to produce a optimal code for your machine.
Therefore I think the linux system is more effective than any windows application.
could be, but in reality linux pcs are normaly not faster in any benchmarks, games, distributed computing or whatever than windows pcs. when windows is running it doesnt use much of the system ressources and you also install Motherboard / CPU drivers so....
Am i wrong or does the linux app perform better at S5?
Same Host (Dual Boot)
Win: 1_0796.0_S5R1__685_S5R1a 80756s
Lin: l1_1206.0_S5R1__710_S5R1a 64203s
Both are long WUs but the linux one is about x1.26 faster
edit: CPU is a P3m 1GHz
they are both "long" but still different. you can ONLY really compare between WUs that give the same Credits at the end.
same at Stephen R. Its hard to compare, if you also post the credits you got for the WUs besides the time that would help...
WU ~28200 (AMD 2400+ XP running Linux) All S5 WU credit claimed 176.46
WU ~35400 (AMD 64 X2 3800+ running Win XP) All S5 WU credit claimed 175.76
All the WU I have crunched so far have been long and appear much the same. Apart from Akos's good work dropping the AMD 64 system down to ~23800 before I stopped using his patched apps as requested :-( sigh, although I understand from E@H point of view (for now). Considering memory / bus speed, CPU etc of my two systems vs each other. I think it is most likley that Bernd's Linux compile of the standard app is more effecient and hence considerably faster than the Windows compiled app. I would have to agree that generally Linux vs XP is pretty much simular with regards to speed all things considered, each has it's pros and cons. IMO I think Bernd (and Akos's help) get high marks for bringing the Linux based app back up to "speed".
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
I totally agree with you.
And to add some more, as i'm sure the results generated by intel cpus or amds will differ too( even though both would run on the same OS and using the same application).
There's even a difference between amd cpus. single core cpus produce slightly different results than dual cores.
On the hardware side it's not just Intel/AMD/single/dual. It's also IBM PowerPC for the Macs, SPARC for some older Suns, and who knows, a whole host of others.
Lots of different sets of machine instructions crunching away from "one" official einstein_S5R1_xxx source. If scientific rigor can deal with that, then it should easily cope with a few handcoded instructions in the Windows app. It's not like those changes to the Windows app can't be documented and verified.
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
I totally agree with you.
And to add some more, as i'm sure the results generated by intel cpus or amds will differ too( even though both would run on the same OS and using the same application).
There's even a difference between amd cpus. single core cpus produce slightly different results than dual cores.
(That was seen on leiden classical too)
Hello Crunch3r
Just a thought - I have cut down stuff running in XP as much as possible, which leaves me with 20 services running, doing stuff in the b/ground. On the Linux side I can have far less processes running - even minus the GUI if I want to do that. Would this minimal processes impact on the speed of the Linux crunching do you think ?
Just a thought - I have cut down stuff running in XP as much as possible, which leaves me with 20 services running, doing stuff in the b/ground. On the Linux side I can have far less processes running - even minus the GUI if I want to do that. Would this minimal processes impact on the speed of the Linux crunching do you think ?
Gray
Not meaningfully. If you look at your computers webpages, you can see the Average CPU efficiency number. This is the % of the CPU time einstien's getting. For a dedicated machine it should be in the high 90's, my win2k crunchbox with a standard OS config is at 98.7%. Which means that no matter how hard I work to optimize the oS, I could at most get 1.3% more speed out. IIRC my Xp desktop is around the same value, but the boinc studio client went splat this afternoon and stopped running work so it's all screwed up at the moment.
I believe the normal
)
I believe the normal Win-Boxes of a user have a great overhead in functionality that never be used for any application like seti or einstein. This makes the system big and slower.
If you compile a linux system for your machine, you can select still these parts of the system that will be necessary to run the application. This makes compact and effective systems without any overhead. And when you compile the kernel you can choose processorspecific propertys like SSE2 etc. to produce a optimal code for your machine.
Therefore I think the linux system is more effective than any windows application.
RE: I believe the normal
)
could be, but in reality linux pcs are normaly not faster in any benchmarks, games, distributed computing or whatever than windows pcs. when windows is running it doesnt use much of the system ressources and you also install Motherboard / CPU drivers so....
RE: they are both "long"
)
Well, they are 155.34 vs. 153.38, wich is a difference of 1%, but linux was 26% faster.
RE: RE: Am i wrong or
)
WU ~28200 (AMD 2400+ XP running Linux) All S5 WU credit claimed 176.46
WU ~35400 (AMD 64 X2 3800+ running Win XP) All S5 WU credit claimed 175.76
All the WU I have crunched so far have been long and appear much the same. Apart from Akos's good work dropping the AMD 64 system down to ~23800 before I stopped using his patched apps as requested :-( sigh, although I understand from E@H point of view (for now). Considering memory / bus speed, CPU etc of my two systems vs each other. I think it is most likley that Bernd's Linux compile of the standard app is more effecient and hence considerably faster than the Windows compiled app. I would have to agree that generally Linux vs XP is pretty much simular with regards to speed all things considered, each has it's pros and cons. IMO I think Bernd (and Akos's help) get high marks for bringing the Linux based app back up to "speed".
I posted a message a couple
)
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
RE: I posted a message a
)
I totally agree with you.
And to add some more, as i'm sure the results generated by intel cpus or amds will differ too( even though both would run on the same OS and using the same application).
There's even a difference between amd cpus. single core cpus produce slightly different results than dual cores.
(That was seen on leiden classical too)
On the hardware side it's not
)
On the hardware side it's not just Intel/AMD/single/dual. It's also IBM PowerPC for the Macs, SPARC for some older Suns, and who knows, a whole host of others.
Lots of different sets of machine instructions crunching away from "one" official einstein_S5R1_xxx source. If scientific rigor can deal with that, then it should easily cope with a few handcoded instructions in the Windows app. It's not like those changes to the Windows app can't be documented and verified.
Just a short comment on time
)
Just a short comment on time taken for a pair of long WUs on a dual-booting 2.6 Intel with 768 megs RAM
Windows XP: 12,5 hours
Gentoo Linux (Fluxbox) 9,5 hours
..worth the compile time... (grin)
and at last Linux can play with Windows !
Gray
RE: RE: I posted a
)
Hello Crunch3r
Just a thought - I have cut down stuff running in XP as much as possible, which leaves me with 20 services running, doing stuff in the b/ground. On the Linux side I can have far less processes running - even minus the GUI if I want to do that. Would this minimal processes impact on the speed of the Linux crunching do you think ?
Gray
RE: Hello Crunch3r Just a
)
Not meaningfully. If you look at your computers webpages, you can see the Average CPU efficiency number. This is the % of the CPU time einstien's getting. For a dedicated machine it should be in the high 90's, my win2k crunchbox with a standard OS config is at 98.7%. Which means that no matter how hard I work to optimize the oS, I could at most get 1.3% more speed out. IIRC my Xp desktop is around the same value, but the boinc studio client went splat this afternoon and stopped running work so it's all screwed up at the moment.