We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
Maybe you could just release the new linux binaries immediately. That way people like me aren't having to run wine to take advantage of the improvements in the new binary, and also, Linux is a relatively small share of the E@H computer base, so I doubt the increased WU's from the Linux machines would break anything.
This would also allow for testing out the code before a widespread release.
Just wishful thinking :)
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users.
how about making the workunits say 2x or 4x longer with the new app? those z.... named workunits are much too short even without optimation anyway.
how about making the workunits say 2x or 4x longer with the new app? those z.... named workunits are much too short even without optimation anyway.
greetz, pe.
IMHO they would have to restart the S4 run then. It would only make sense if _all_ workunits have (e.g.) a longer integral time. But ok. They might merge several workunits to a single one.
For my P200 is NO workunit too short :)
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
with all due respect, this problem is easy to solve. Rather than having 25+% CPU time waisted while running a known-to-underperform binary, I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while. E@H updates its server in the meantime and we all will be back once you give the thumbs-up signal for it.
All the best
Steffen (who needs his CPU power himself since a few days)
I guess any DC programm can be optimized furher so this is no reason to leave Einstein@home and come back ... Even if we "waist" cpu time now we'll finish earlier.
I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while.
Definitely, hehe ;) what a problem! Would be interesting which app is faster, akosf's S-38 or the officially optimized one. Maybe the new official app will get another speed-up since Akos's further development may be not implemented yet.
Live long and crunch ;-)
Same here. We know akosf's gained very large improvements by changing the actual algorithm used. I'd be very interested in seeing if he's outdone the compiler in producing asm code as well. Excepting cases where the compiler doesn't know about new instruction sets (and special purpose processors without a good compiler) it's supposed to be very hard to do now.
Excepting cases where the compiler doesn't know about new instruction sets (and special purpose processors without a good compiler) it's supposed to be very hard to do now.
Alot of the times it comes down to compilers needing to make sure the code stays 100% accurate according to the logic the coder explicitly, whereas looking at the code often times reveals that moving a few calcuations around to take advantage of pipelining and so on is actually "ok" for the code. The code can only be as good as you allow it to be. Alot of times people use variables in a way that makes them dependent on earlier calculations, and decreases the utilization of the CPU being able to do things in the pipeline.
I'm not saying this is what akosf did for sure, but it is one major area where a compiler will never be perfect.
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while.
RE: Here's an
)
Maybe you could just release the new linux binaries immediately. That way people like me aren't having to run wine to take advantage of the improvements in the new binary, and also, Linux is a relatively small share of the E@H computer base, so I doubt the increased WU's from the Linux machines would break anything.
This would also allow for testing out the code before a widespread release.
Just wishful thinking :)
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
RE: We are worried that our
)
how about making the workunits say 2x or 4x longer with the new app? those z.... named workunits are much too short even without optimation anyway.
greetz, pe.
RE: how about making the
)
IMHO they would have to restart the S4 run then. It would only make sense if _all_ workunits have (e.g.) a longer integral time. But ok. They might merge several workunits to a single one.
For my P200 is NO workunit too short :)
What about new source
)
What about new source optimized FreeBSD binary, too? That's so tiny market share that it will absolutely not overload your servers, Bruce :)
Dear
)
Dear Bruce,
with all due respect, this problem is easy to solve. Rather than having 25+% CPU time waisted while running a known-to-underperform binary, I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while. E@H updates its server in the meantime and we all will be back once you give the thumbs-up signal for it.
All the best
Steffen (who needs his CPU power himself since a few days)
I guess any DC programm can
)
I guess any DC programm can be optimized furher so this is no reason to leave Einstein@home and come back ... Even if we "waist" cpu time now we'll finish earlier.
Greetings, Santas little helper
RE: I suggest to ask
)
It is a very grandiose attitude.
RE: RE: At least that is
)
Same here. We know akosf's gained very large improvements by changing the actual algorithm used. I'd be very interested in seeing if he's outdone the compiler in producing asm code as well. Excepting cases where the compiler doesn't know about new instruction sets (and special purpose processors without a good compiler) it's supposed to be very hard to do now.
RE: RE: RE: Excepting
)
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
RE: RE: I suggest to ask
)
Also give akosf the Volunteer Developer title.
me-[at]-rescam.org