Akos is working for the project now, so the new apps should have his speedups built in. That may not mean that they'll run a WU in a little time as akos's current versions. It depends on if Bruce, et al. feel they'll get a larger benefit out of analizing more data, or looking deeper at the best data they have. Since the Akos code will be built into the official apps though, you'll only see standardish credit. Exactly how that'll work out is somewhat debatable though since Akos's tweaked asm is signifcantly faster than the improved C++ code used to generate the non x86 apps. There's also a fairly large spread between old x86 chips at the low end, and SSE3 Amds at the high end, so which system is used to baseline the credit will make a decent impact on credit accumulation.
With Crunch3r hanging around here, and apparently through with seti we might see additional app optimizations from him at some point.
Akos is working for the project now, so the new apps should have his speedups built in. That may not mean that they'll run a WU in a little time as akos's current versions. It depends on if Bruce, et al. feel they'll get a larger benefit out of analizing more data, or looking deeper at the best data they have. Since the Akos code will be built into the official apps though, you'll only see standardish credit. Exactly how that'll work out is somewhat debatable though since Akos's tweaked asm is signifcantly faster than the improved C++ code used to generate the non x86 apps. There's also a fairly large spread between old x86 chips at the low end, and SSE3 Amds at the high end, so which system is used to baseline the credit will make a decent impact on credit accumulation.
With Crunch3r hanging around here, and apparently through with seti we might see additional app optimizations from him at some point.
It would be nice if official S5 apps were made for specific processers (instructions - MMX, SSE, SSE2, CDNow, etc.) and made available eventually on the Applications page, such as are available now (Akos' - though unofficial) for S4 in the forum. The "all purpose" app would still be set up as it is now for those who sign on to the project and receive the automatic download.
Just a suggestion. I thought I'd drop it here instead of starting a new thread in Wish List. I'd understand if the "logistics" would not be feasible for this because of the added work on the programmers.
-edit- It just occured to me that maybe the "official - general purpose app" could be coded to "sense" what processor (instructions) are available and then there would be no need for "specific" applications. I don't code so I don't know if this is possible or feasible.
-edit- It just occured to me that maybe the "official - general purpose app" could be coded to "sense" what processor (instructions) are available and then there would be no need for "specific" applications. I don't code so I don't know if this is possible or feasible.
At that time would we have to discontinue using Akosf's optimized apps to get the new S5 work?
Then the project sends out the new science application, Akos optimized application on your host will be automatically replaced by the new standard app.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
-edit- It just occured to me that maybe the "official - general purpose app" could be coded to "sense" what processor (instructions) are available and then there would be no need for "specific" applications. I don't code so I don't know if this is possible or feasible.
IIRC it'll be doing just that
If that happens, will there be any provision to 'override' the instruction set it uses? I have one system that I use heavily for video processing (copying my VHS tapes to DVDs) and if E@H uses the SSE instructions, it causes my system to crash. I went thru several of Aksof's apps before I found one that was compatible and did the best work (D41.14).
If we're forced to use whatever the app chooses and can't override it, I'll have to remove that system from E@H.
-edit- It just occured to me that maybe the "official - general purpose app" could be coded to "sense" what processor (instructions) are available and then there would be no need for "specific" applications. I don't code so I don't know if this is possible or feasible.
IIRC it'll be doing just that
At least initially it won't because the CPU switching's turned out to he more of a problem than they thought it would be. If we'll be able to keep using the current akos clients or will have to go back to a new standard one (~4x speedup) is currently unknown.
Are there currently any optimized apps for Linux and x86_64 Linux SSE2 and SSE3? If so, could someone please post a link to them? Thanks.
Regards, Daniel.
Daniel,
Please take a look at the sticky posts on the Linux Beta test apps. Akosf developed the optimized windows apps, but the Linux optimized apps are being developed by the project itself.
Are there currently any optimized apps for Linux and x86_64 Linux SSE2 and SSE3? If so, could someone please post a link to them? Thanks.
Regards, Daniel.
Daniel,
Please take a look at the sticky posts on the Linux Beta test apps. Akosf developed the optimized windows apps, but the Linux optimized apps are being developed by the project itself.
Thanks. I got 4.58 running on my Pentium D 950 with x86_64 Linux, but it is nowhere NEAR as fast as the Windows apps by Akosf. I wish I had another Windows XP license now :)
[
Thanks. I got 4.58 running on my Pentium D 950 with x86_64 Linux, but it is nowhere NEAR as fast as the Windows apps by Akosf. I wish I had another Windows XP license now :)
Daniel,
Welcome to Einstein, and to the wonderful speedup of the akosf aps. I notice some of your machines are Intel hyperthreaded ones, which you appear to be running with HT enabled.
In the evolution of the akosf improvements, there was an abrupt point at which the hyperthreading improvement for my Gallatin (Northwood-derived P4 extreme edition) turned to a substantial penalty. That's right, if I run Einstein alone (as distinct from one thread Einstein one thread SETI), I get more science out of the machine with hyperthreading disabled than running two Einstein threads.
If you are interested in checking for maximum performance, you may wish to test turning off HT on a representative machine or so--I'm not sure if this applies to your versions and CPUs. It is rather strongly true for S41.07 on Gallatin.
Akos is working for the
)
Akos is working for the project now, so the new apps should have his speedups built in. That may not mean that they'll run a WU in a little time as akos's current versions. It depends on if Bruce, et al. feel they'll get a larger benefit out of analizing more data, or looking deeper at the best data they have. Since the Akos code will be built into the official apps though, you'll only see standardish credit. Exactly how that'll work out is somewhat debatable though since Akos's tweaked asm is signifcantly faster than the improved C++ code used to generate the non x86 apps. There's also a fairly large spread between old x86 chips at the low end, and SSE3 Amds at the high end, so which system is used to baseline the credit will make a decent impact on credit accumulation.
With Crunch3r hanging around here, and apparently through with seti we might see additional app optimizations from him at some point.
RE: Akos is working for the
)
It would be nice if official S5 apps were made for specific processers (instructions - MMX, SSE, SSE2, CDNow, etc.) and made available eventually on the Applications page, such as are available now (Akos' - though unofficial) for S4 in the forum. The "all purpose" app would still be set up as it is now for those who sign on to the project and receive the automatic download.
Just a suggestion. I thought I'd drop it here instead of starting a new thread in Wish List. I'd understand if the "logistics" would not be feasible for this because of the added work on the programmers.
-edit- It just occured to me that maybe the "official - general purpose app" could be coded to "sense" what processor (instructions) are available and then there would be no need for "specific" applications. I don't code so I don't know if this is possible or feasible.
RE: -edit- It just occured
)
IIRC it'll be doing just that
RE: At that time would we
)
Then the project sends out the new science application, Akos optimized application on your host will be automatically replaced by the new standard app.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: RE: -edit- It just
)
If that happens, will there be any provision to 'override' the instruction set it uses? I have one system that I use heavily for video processing (copying my VHS tapes to DVDs) and if E@H uses the SSE instructions, it causes my system to crash. I went thru several of Aksof's apps before I found one that was compatible and did the best work (D41.14).
If we're forced to use whatever the app chooses and can't override it, I'll have to remove that system from E@H.
Seti Classic Final Total: 11446 WU.
RE: RE: -edit- It just
)
At least initially it won't because the CPU switching's turned out to he more of a problem than they thought it would be. If we'll be able to keep using the current akos clients or will have to go back to a new standard one (~4x speedup) is currently unknown.
http://einsteinathome.org/node/191326
Are there currently any
)
Are there currently any optimized apps for Linux and x86_64 Linux SSE2 and SSE3? If so, could someone please post a link to them? Thanks.
Regards, Daniel.
RE: Are there currently any
)
Daniel,
Please take a look at the sticky posts on the Linux Beta test apps. Akosf developed the optimized windows apps, but the Linux optimized apps are being developed by the project itself.
RE: RE: Are there
)
Thanks. I got 4.58 running on my Pentium D 950 with x86_64 Linux, but it is nowhere NEAR as fast as the Windows apps by Akosf. I wish I had another Windows XP license now :)
Regards, Daniel.
RE: [ Thanks. I got 4.58
)
Daniel,
Welcome to Einstein, and to the wonderful speedup of the akosf aps. I notice some of your machines are Intel hyperthreaded ones, which you appear to be running with HT enabled.
In the evolution of the akosf improvements, there was an abrupt point at which the hyperthreading improvement for my Gallatin (Northwood-derived P4 extreme edition) turned to a substantial penalty. That's right, if I run Einstein alone (as distinct from one thread Einstein one thread SETI), I get more science out of the machine with hyperthreading disabled than running two Einstein threads.
If you are interested in checking for maximum performance, you may wish to test turning off HT on a representative machine or so--I'm not sure if this applies to your versions and CPUs. It is rather strongly true for S41.07 on Gallatin.
see also
this thread