@Byron: I really can't make a prediction, as I cannot speak for the official dev team. I personally would *not* expect this to happen in the next 3 or 4 weeks or so.
It would, in my opinion be a good idea to put more thought into getting a Win SSE2 version out asap, considering that, according to BOINCStats, there are 50% more windows computers that all other operating systems.
Any increase in windows performance will give a bigger increase in Einsteins throughput, than concentrating on 'nix or its close cousin version for the macs.
Some of us are stuck with windows, whether we like it or not.
It would, in my opinion be a good idea to put more thought into getting a Win SSE2 version out asap, considering that, according to BOINCStats, there are 50% more windows computers that all other operating systems.
Any increase in windows performance will give a bigger increase in Einsteins throughput, than concentrating on 'nix or its close cousin version for the macs.
Some of us are stuck with windows, whether we like it or not.
But if the reference app shows almost no difference between the speed of SSE and SSE2 under Linux (green and purple lines), what makes you think there'll be a big improvement under Windows?
I think it would be a better use of scarce developer time to continue to migrate the code-base to a cross-platform compiler, and then continue hand-crafting the "hotloos" (as Bikeman called them - love it. Makes 'em run.) to the benefit of all.
Sorry, but the ref-app does not meet the reality. While the SSE-app mostly speeds up the longer WUs, the SSE2 app gives an additionaml kick to the shorter WUs, but also speeds up the longer ones an bit more.
It would, in my opinion be a good idea to put more thought into getting a Win SSE2 version out asap, considering that, according to BOINCStats, there are 50% more windows computers that all other operating systems.
Any increase in windows performance will give a bigger increase in Einsteins throughput, than concentrating on 'nix or its close cousin version for the macs.
Some of us are stuck with windows, whether we like it or not.
But if the reference app shows almost no difference between the speed of SSE and SSE2 under Linux (green and purple lines), what makes you think there'll be a big improvement under Windows?
I think it would be a better use of scarce developer time to continue to migrate the code-base to a cross-platform compiler, and then continue hand-crafting the "hotloos" (as Bikeman called them - love it. Makes 'em run.) to the benefit of all.
All the evidence from the linux hosts compared to win hosts during latter stages of S5R3, running proper tasks, not test apps. I did a run of about 20 tasks with the same wingman who was going about 8% faster than me on an 8 core e5430 Xeon running linux, pity, but all wiped away now from my results page.
But if the reference app shows almost no difference between the speed of SSE and SSE2 under Linux (green and purple lines), what makes you think there'll be a big improvement under Windows?
That graph does explicitly show the significant difference between the Windows and Linux SSE apps though. Whatever the difference between those two lines (red and green) is what the focus needs to be. If that is achieved by migrating the code-base to a cross-platform complier, then by all means, let's Git R Done... Hopefully that will bring the Windows and Linux apps much closer to each other instead of the 20%+ advantage the Linux app currently enjoys.
... Hopefully that will bring the Windows and Linux apps much closer to each other instead of the 20%+ advantage the Linux app currently enjoys.
In the good old days of CLASSIC SETI@home I was able to get up to 30% advantage when switching to a lower runlevel ( no Xserver ! ) while running the client when I was away from my computer.
As long as you don't measure the CPU time scheduled to the application, there will always be differences as some OS are more efficient than others ( even if you install the same OS to the same hardware, other programs installed by admins and/or users will lead to noticeable differences :rollingeyes: )
Quote:
... Note that the new stock apps come in bundles of two or three executables:
einstein*_0 is for legacy PCs (no SSE support)
einstein*_1 is used for SSE enabled PCs
einstein*_2 (Linux only at the moment) is for SSE2 enabled PCs
Intel-Macs are all SSE2 enabled...
What about apps for my PS3 with Fedora 9 ?
will then stand _0 for legacy PPC (without Altivec), _1 for PPC64 with Altivec and _2 for cell specific code using the 6 available SPU of my PS3 instead of only the PPC core ?
... Hopefully that will bring the Windows and Linux apps much closer to each other instead of the 20%+ advantage the Linux app currently enjoys.
In the good old days of CLASSIC SETI@home I was able to get up to 30% advantage when switching to a lower runlevel ( no Xserver ! ) while running the client when I was away from my computer.
As long as you don't measure the CPU time scheduled to the application, there will always be differences as some OS are more efficient than others ( even if you install the same OS to the same hardware, other programs installed by admins and/or users will lead to noticeable differences :rollingeyes: )
True enough, but that's why I'm also willing to accept a target range. Preferred range (for me) is 3-5%. My XP installation is tweaked to have only the absolute required services running. I don't run out and install "Mega-Cool" freeware / shareware applications which can have "hidden treasures" in them...
Also, SETI Classic had a Windows command line app as well. I'd be curious if you are meaning 30% runtime improvement over a Windows host with the exact same hardware specs as your system running the Windows command line app...or if you were comparing something else...
RE: @Byron: I really can't
)
Thanks again Bikeman.
It would, in my opinion be a
)
It would, in my opinion be a good idea to put more thought into getting a Win SSE2 version out asap, considering that, according to BOINCStats, there are 50% more windows computers that all other operating systems.
Any increase in windows performance will give a bigger increase in Einsteins throughput, than concentrating on 'nix or its close cousin version for the macs.
Some of us are stuck with windows, whether we like it or not.
RE: It would, in my opinion
)
But if the reference app shows almost no difference between the speed of SSE and SSE2 under Linux (green and purple lines), what makes you think there'll be a big improvement under Windows?
I think it would be a better use of scarce developer time to continue to migrate the code-base to a cross-platform compiler, and then continue hand-crafting the "hotloos" (as Bikeman called them - love it. Makes 'em run.) to the benefit of all.
Sorry, but the ref-app does
)
Sorry, but the ref-app does not meet the reality. While the SSE-app mostly speeds up the longer WUs, the SSE2 app gives an additionaml kick to the shorter WUs, but also speeds up the longer ones an bit more.
cu,
Michael
RE: Using gcc for *all*
)
At one point, Bernd made some sort of statement about considering ICC/IPP/MKL
RE: RE: Using gcc for
)
Yes, but I think this one is more recent and reflects current preferences.
CU
Bikeman
RE: RE: It would, in my
)
All the evidence from the linux hosts compared to win hosts during latter stages of S5R3, running proper tasks, not test apps. I did a run of about 20 tasks with the same wingman who was going about 8% faster than me on an 8 core e5430 Xeon running linux, pity, but all wiped away now from my results page.
RE: But if the reference
)
That graph does explicitly show the significant difference between the Windows and Linux SSE apps though. Whatever the difference between those two lines (red and green) is what the focus needs to be. If that is achieved by migrating the code-base to a cross-platform complier, then by all means, let's Git R Done... Hopefully that will bring the Windows and Linux apps much closer to each other instead of the 20%+ advantage the Linux app currently enjoys.
RE: ... Hopefully that
)
In the good old days of CLASSIC SETI@home I was able to get up to 30% advantage when switching to a lower runlevel ( no Xserver ! ) while running the client when I was away from my computer.
As long as you don't measure the CPU time scheduled to the application, there will always be differences as some OS are more efficient than others ( even if you install the same OS to the same hardware, other programs installed by admins and/or users will lead to noticeable differences :rollingeyes: )
What about apps for my PS3 with Fedora 9 ?
will then stand _0 for legacy PPC (without Altivec), _1 for PPC64 with Altivec and _2 for cell specific code using the 6 available SPU of my PS3 instead of only the PPC core ?
MfG, MEX
0xFF
RE: RE: ... Hopefully
)
True enough, but that's why I'm also willing to accept a target range. Preferred range (for me) is 3-5%. My XP installation is tweaked to have only the absolute required services running. I don't run out and install "Mega-Cool" freeware / shareware applications which can have "hidden treasures" in them...
Also, SETI Classic had a Windows command line app as well. I'd be curious if you are meaning 30% runtime improvement over a Windows host with the exact same hardware specs as your system running the Windows command line app...or if you were comparing something else...