I think beta app are here to minimize risks no ? i'm surprized By your argument because it seems to me That you do not proceed in this way before.
I fully understand that there are technical problems for PPC app
But the difference between x86 app for Macos X /Linux or Windows is very
Tenuous so i d'ont understand why it takes more than 3 months to recompile for windows !
Because it's not just a re-compile.
The SSE code is hand-crafted assembly, originally tested in a version that follows gcc syntax convetntions.
Vector arithmetic would be difficult to formalize in a cross-architecture, cross-compiler C/C++ standard because of implementation differences. Some compilers (not the MS Windows one) now have the ability to "auto-vectorize" code, that is you throw standard scalar code at it and by some magic, the compiler tries to rearrange these computations in a way that can be implemented by SIMD instructions on the target system. This is very tricky, and depending on the specific source code and compiler used can yield results that are quite good if you are lucky and not so good if you aren't. If you can you go for hand written assembly code, I guess.
As for risk management, the beta apps are fine for testing but you cannot limit per se how many users will actually use them. There is an acceptable upper-bound for beta-apps for Linux, Mac OS etc., but if you publish a Windows beta app, it can "spread" to a really huge number of users. It's better to have a smaller beta test base so that almost all beta-app results are paired with non-beta generated results for validation, to prevent that the beta-app is validating against itself.
Bernd has explained this before, MacOS X Intel was the natural choice to start with since there is no older processors than Core inside those and therefore all Intel Macs supports SSE/SSE2, on Linux and Windows theres even processors not supporting MMX, thats a major difference, MacOS X Intel just dont have any code compatibility issues.
It took a long time also for GNU/Linux users to get a real good app that could compare to x86 MacOS X (Power users app 4.21), the first Linux app to improve performance was Beta 4.12, before that Linux was by far the slowest.
As for risk management, the beta apps are fine for testing but you cannot limit per se how many users will actually use them. There is an acceptable upper-bound for beta-apps for Linux, Mac OS etc., but if you publish a Windows beta app, it can "spread" to a really huge number of users. It's better to have a smaller beta test base so that almost all beta-app results are paired with non-beta generated results for validation, to prevent that the beta-app is validating against itself.
...which is a good reason for implementing a separate beta project, like SETI has... You have all your test data over in the beta project and you don't care how many sign up because it is a physical separation of the main project data and the test data...
1500 dollards max for possible 50% speed boost , The intel compiler is the best compiler for x86
Alexkan on SETI app have a 50 % speed boost in two days of work with the ICC compiler :)
No question on the performance of Alex's app's for the Mac on SAH, but let's keep the record straight! He has far more than 2 days of work put in to those app's.
Likewise on the Windows/Linux front, the Coop members have a similar investment in time put into the current versions. Even with using ICC/IPP, a lot of hand tweaking has been done. ;-)
As far as using ICC/IPP here on EAH, that would be great, but it's not a one size fits all proposition. IIRC, there is still the issue of not fully utilizing the capability of SSEx on AMD platforms (without jumping through hoops), plus there is a recurring licensing charge except for the Linux version to stay up to date. So it's not like you cough up the cake once and you're golden. Granted EAH has better funding overall than SAH, but it's still something to take into account.
RE: The SSE code is
)
Because it's not just a re-compile.
The SSE code is hand-crafted assembly, originally tested in a version that follows gcc syntax convetntions.
Vector arithmetic would be difficult to formalize in a cross-architecture, cross-compiler C/C++ standard because of implementation differences. Some compilers (not the MS Windows one) now have the ability to "auto-vectorize" code, that is you throw standard scalar code at it and by some magic, the compiler tries to rearrange these computations in a way that can be implemented by SIMD instructions on the target system. This is very tricky, and depending on the specific source code and compiler used can yield results that are quite good if you are lucky and not so good if you aren't. If you can you go for hand written assembly code, I guess.
As for risk management, the beta apps are fine for testing but you cannot limit per se how many users will actually use them. There is an acceptable upper-bound for beta-apps for Linux, Mac OS etc., but if you publish a Windows beta app, it can "spread" to a really huge number of users. It's better to have a smaller beta test base so that almost all beta-app results are paired with non-beta generated results for validation, to prevent that the beta-app is validating against itself.
CU
Bikeman
Bernd has explained this
)
Bernd has explained this before, MacOS X Intel was the natural choice to start with since there is no older processors than Core inside those and therefore all Intel Macs supports SSE/SSE2, on Linux and Windows theres even processors not supporting MMX, thats a major difference, MacOS X Intel just dont have any code compatibility issues.
It took a long time also for GNU/Linux users to get a real good app that could compare to x86 MacOS X (Power users app 4.21), the first Linux app to improve performance was Beta 4.12, before that Linux was by far the slowest.
Team Philippines
ok but how many times it take
)
ok but how many times it take to do the SSE code for x86MacOS X ? 3 months ? :)
I'm also surprized , using assembly code for SSE it's very difficult and intel has done lots of Library/developpement tools for SSE optimization.
RE: ok but how many times
)
Also for for the gcc compiler? And with a license that allows free redistribution?
CU
Bikeman
RE: As for risk
)
...which is a good reason for implementing a separate beta project, like SETI has... You have all your test data over in the beta project and you don't care how many sign up because it is a physical separation of the main project data and the test data...
To my knowledge einstein@home
)
To my knowledge einstein@home source code is not opensource so ?
ICC compiler :
http://www.sosdevelopers.com/fiche.aspx?pg_code=7082
1500 dollards max for possible 50% speed boost , The intel compiler is the best compiler for x86
Alexkan on SETI app have a 50 % speed boost in two days of work with the ICC compiler :)
RE: To my knowledge
)
Bernd has indicated that he'd like to switch to the Intel compiler, but that will take some time. I pointed him to a potential resource for help...
Brian
Ok it's a good news !
)
Ok it's a good news !
RE: To my knowledge
)
No question on the performance of Alex's app's for the Mac on SAH, but let's keep the record straight! He has far more than 2 days of work put in to those app's.
Likewise on the Windows/Linux front, the Coop members have a similar investment in time put into the current versions. Even with using ICC/IPP, a lot of hand tweaking has been done. ;-)
As far as using ICC/IPP here on EAH, that would be great, but it's not a one size fits all proposition. IIRC, there is still the issue of not fully utilizing the capability of SSEx on AMD platforms (without jumping through hoops), plus there is a recurring licensing charge except for the Linux version to stay up to date. So it's not like you cough up the cake once and you're golden. Granted EAH has better funding overall than SAH, but it's still something to take into account.
Alinator
See here for a first version
)
See here for a first version of an optimized PPC S5R3 app.