Well, Einstein@Home is working on it ... of course you have to have a Macintosh ... :)
I have not tried it yet. But, with some success with the WIndows and SETI@Home, the procedure for which I am STILL WRITING, and the possibilities here at Einstein@Home I may be running many more optimized versions.
Keep in mind that SETI@Home's data accuracy tolerance is quite low and the signals to noise ratios are reletively high (if I read the tea leaves right) and so the need for tighter tolerances in Einstein@Home, LHC@Home, and Predictor@Home.
* PPAH uses homogenous redundency to improve the chances of tight tolerances.
* LHC@Home uses ONE specific compiler and does not do an OS-X version because they have such tight tolerances.
* Einstein@Home I think has a much smaller signal to noise ratio and again a need for much higher precision.
Anyway, we glide over the surface as there are just too many factors that come into play. Mr. T does a fantastic job (though I still have not figured out his file names for my table - sigh, weak mind or something), but it mostly a "cook-book" type thing.
I expected this from the new SETI code but I was surprised that Einstein also improved since I forget how the BOINC program attempts to balance competing applications.
Sounds like you are not only running the optimized science app, but the CC as well...
The reason E@H is doing 'better' is because the optimized CC has inflated benchmark numbers. If you are running the optimized science app at Seti, this is fine because the optimized app will take less time and request far less credit than the standard app. The problem is that when running the optimized CC in conjunction with other projects, the inflated benchmark numbers cause your machine to request more credit than it should.
I visited here after a long interval, and is surprised this thread is still active :) Recently I've been up to the ears in seti@home beta test and found optimized clients don't always benefit. In beta test project, the client upgraded, and the algorithm has changed. However many people using my optimized clients didn't upgrade when a new official client was released and a mixture of different versions happened in many WUs, which might grant inappropriate results, and the honest people using up-to-date clients couldn't get enough credits. Even I myself suffered from this incident (due to my own clients!!), and aborted some WUs, which had been crunched by older optimized clients because optimized clients aren't updated automatically.
So it's up to the developer of each project, whether the source is released to public or not, and I myself am now reluctant to make optimized clients because of the above reason...sorry to those who want it. And at the same time, I cannot afford time to make optimized clients for Einstein, though I'm interested in theory of general relativity.
As Paul said (Hi there Paul... nice to see you around here too...) optimization benefits depend on so many factors...
My 2 ¢...
Say with a regular client you can crunch 8 WUs a day, and with an optimized client you can crunch 16 WUs a day (this is my average in S@H, not the same, but bear with me). BUT 4 out of every 10 results are invalid due to errors in results are above tolerances (I have had no erroneous result, but let's say in E@H, 40% of results coming out from optimized clients are considered erroneous). This is way high, yet considering we are returning 16 results every day, I would have returned about 9.6 validated results. Is this better than the normal approach? Hell yeah... Proyect would need to dismiss 40% of my results, but at the end of the day I'ld be returning 1.6 results more... However, let's remember that for this example an optimized client will finish in half the time, and 40% of the times results won't validate..
BUT... if everyone (or a high percentage of users/hosts) use optimized clients, probably a WU should be crunched more than 3 times.. perhaps 4 or 5, or even 6, only to check that every client returned a valid result (NOT part of the 40% erroneous).
Did optimized clients helped? Not quite... It's just a matter of how much precision do you need... Time vs precision...
... BUT 4 out of every 10 results are invalid due to errors in results are above tolerances (I have had no erroneous result, but let's say in E@H, 40% of results coming out from optimized clients are considered erroneous).
I presume you are talking exclusively about SAH because there are no TMR style optimised clients for EAH. This whole thread was started by TMR asking gently for the source code to be made available so he could do his optimising thing. So it's a bit of a long bow to be presuming that 40% of the optimised results might be erroneous when there aren't any such clients in the first place.
But getting back to my presumption that you are really talking about SAH. I'd be very interested in any link you could point us to which could show that there might even be a 4% increase in erroneous results from an optimised seti client, let alone anything like 40%.
IMHO there's no reason on earth 'not' to have optimized Clients.
Having custom compiled Clients is one of BOINC's key features, and the Server-sided redundancy/validation check takes care of the rest.
Ideal solution would be, however, that the Developers create their own, fully optimized Clients that will be auto-updated and downloaded by the appropriate platforms.
(beats me why they haven't done so already, Compilers and Expert advice + their know-how (if needed) are readily available)
The only fallback one must truly recognize is the fact that Custom Clients integrated via the app_info.xml will never auto-update.
...although arguably, people capable of manually inserting their own Clients 'should' be able to manually update those as well, but it remains a valid consideration.
Otherwise, it would be up to the Server Admins to throw a switch and put obsolete Version numbers to a rest with a
"There was work available but not for your Client Version. Please update your Client to Vx.xx" type of Message.
--------
So far, the SETI optimized Clients are a smashing success, with ~60-70% more performance at 100.0% validation levels in my case.
Not doing it would be kind of stupid actually, and those that don't trust those compiles can still use the slow default Clients.
... BUT 4 out of every 10 results are invalid due to errors in results are above tolerances (I have had no erroneous result, but let's say in E@H, 40% of results coming out from optimized clients are considered erroneous).
I presume you are talking exclusively about SAH because there are no TMR style optimised clients for EAH. This whole thread was started by TMR asking gently for the source code to be made available so he could do his optimising thing. So it's a bit of a long bow to be presuming that 40% of the optimised results might be erroneous when there aren't any such clients in the first place.
I was just assuming, IF TMR could compile some optimized clients, and due to the lower error tolerance, that 40% of every result would be invalid. It's an incredibly high rate, and I was trying to show that even with such a high rate, I could probably return more valid results at the end of the day.
Quote:
But getting back to my presumption that you are really talking about SAH. I'd be very interested in any link you could point us to which could show that there might even be a 4% increase in erroneous results from an optimised seti client, let alone anything like 40%.
As I said before...
Quote:
Say with a regular client you can crunch 8 WUs a day, and with an optimized client you can crunch 16 WUs a day (this is my average in S@H, not the same, but bear with me).BUT 4 out of every 10 results are invalid due to errors in results are above tolerances (I have had no erroneous result, but let's say in E@H, 40% of results coming out from optimized clients are considered erroneous).
Perhaps I was a little unclear.
In S@H, my 2.6GHz Laptop:
Regular client: 3 ~ 3.5 hours. 0% invalid results.
Optimized client: 1.5 ~ 1.7 hours. 0% invalid results.
In E@H, big and wild guess here:
Regular client: 5 ~ 10 hours. 0% invalid results
Optimized client: 2.5 ~ 5 hours. 40% invalid results
I used 40% because I know tolerances in E@H are slim, so I was trying to approach to the worst case scenario.
And about having to send the result to more than 4 in case results wouldn't validate, I meant in the way that the project's server automatically does that... just in case.
Due to licensing issues, I don't think the Einstein App Code can be released.
The project folks are doing everything they can to optimize their apps, and for a long time the Windows code was more efficient then others. The Linux users are just getting close to parity with Windows users now. The Mac users have a small advantage because of the alti-vec unit in some Power PC chips. Its my understanding that the Einstein team is/has looked at further optimization for all platforms, but that there is no significant benefit at this time for Windows, but that it continues to be an area of focus as compilers improve. I'm sure they will tweak the Windows app further, when it becomes practical to do so. Of all the BOINC projects, the Einstein team seems most heavily committed to getting the most of any platform. The benefit to both the science and the contributers is something they actively think about. Tetsuji did a great job on the SETI apps, but don't underestimate the developers. If they can sqeeze more performance out of Windows, they will.
IMHO there's no reason on earth 'not' to have optimized Clients.
Actually, there are several. :)
First of all, as Gary was trying to make the point that it is very possible for clients compiled using different compile time "switches" to change the output values by enough of a margin to render them "invalid". One of the hardest points to keep in mind is that with computers there is no guarentee that the answer you get is "valid". Trying to keep it reletively simple I beat on this problem in the Wiki when you read about floating point and errors of same. If your tolerance for error is low, then the use of several "versions" of the program leads you to having more "invalid" results.
And I use "Valid" and "invalid" because each answer may only be "invalid" when compared to an answer developed on a different binary executable. LHC@Home, for example, has such strict requirements that they only have Windows and Linux clients because they can only use one compiler to get the outputs they need.
Secondarily, at this stage, BOINC does not have a really good means of CPU detection and identification that would enable easy selection of the correct binary for the platform. When I wrote the guide for installing an optimized SETI@Home optimized binary I was cringing inside with the expectation that people are going to use that and get mad at me cause I made a mistake along the way ... of course, the good news is that readership is low enough that maybe I will get "lucky" and no one will ever use that guide but me ...
Well, the Validator would quickly tell the User (and more importantly, the person doing the optimizations) that the accuracy is insufficient.
Thus, those clients affected would never be released nor used (fast but invalid would be pointless).
Therefor, only those known to 100% validate would earn the required trust to be used by people would appear for public use. (in the past, AFAIK there were a very few SETI Clients in the early optimization stages that simply did not validate 100% and those were never used in public as well, no harm done)
Apart from a very few CPU versions (e.g. some Athlon64 and Pentium4 steppings), the plain CPU Vendor string is more than sufficient to give excellent baseline optimization guidelines. BOINC already does read it and displays it on the Computer Info Page.
e.g. knowing that the CPU is an Athlon64 3700+ will already tell BOINC that at least MMX, MMX+, 3dNow!, Enhanced 3dNow!, SSE and SEE2 are available for use.
The only thing it cannot tell in this example, is whether it supports SSE3 (Venice core), but that is a neglectible factor.
About the same is valid for just about every CPU existing, the plain Info already gathered by BOINC will always yield a good baseline with room for very effective optimization.
If for whatever reason the CPU string read is truly not usable, it can still default to a vanilla unoptimized x86 Client (IMHO this only happens to a few 'oddball' Linux installations reading like "Unkown CPU @ xxx MHz").
Since CPU detection sample codes are publicly available for both Intel and AMD Systems, those can be easily integrated at anytime, royalty free (then BOINC has more Info than it would ever need).
Not sure if E@H also gives it, but SETI has its desired validation limits published and those are strictly adhered to.
------------
I fully agree however on the Sourcecode release part.
If the Code contains proprietary technology that the team worked very hard for and do not wish to release it to public, that's their free choice of course.
Well, Einstein@Home is
)
Well, Einstein@Home is working on it ... of course you have to have a Macintosh ... :)
I have not tried it yet. But, with some success with the WIndows and SETI@Home, the procedure for which I am STILL WRITING, and the possibilities here at Einstein@Home I may be running many more optimized versions.
Keep in mind that SETI@Home's data accuracy tolerance is quite low and the signals to noise ratios are reletively high (if I read the tea leaves right) and so the need for tighter tolerances in Einstein@Home, LHC@Home, and Predictor@Home.
* PPAH uses homogenous redundency to improve the chances of tight tolerances.
* LHC@Home uses ONE specific compiler and does not do an OS-X version because they have such tight tolerances.
* Einstein@Home I think has a much smaller signal to noise ratio and again a need for much higher precision.
Anyway, we glide over the surface as there are just too many factors that come into play. Mr. T does a fantastic job (though I still have not figured out his file names for my table - sigh, weak mind or something), but it mostly a "cook-book" type thing.
RE: I expected this from
)
Sounds like you are not only running the optimized science app, but the CC as well...
The reason E@H is doing 'better' is because the optimized CC has inflated benchmark numbers. If you are running the optimized science app at Seti, this is fine because the optimized app will take less time and request far less credit than the standard app. The problem is that when running the optimized CC in conjunction with other projects, the inflated benchmark numbers cause your machine to request more credit than it should.
I visited here after a long
)
I visited here after a long interval, and is surprised this thread is still active :) Recently I've been up to the ears in seti@home beta test and found optimized clients don't always benefit. In beta test project, the client upgraded, and the algorithm has changed. However many people using my optimized clients didn't upgrade when a new official client was released and a mixture of different versions happened in many WUs, which might grant inappropriate results, and the honest people using up-to-date clients couldn't get enough credits. Even I myself suffered from this incident (due to my own clients!!), and aborted some WUs, which had been crunched by older optimized clients because optimized clients aren't updated automatically.
So it's up to the developer of each project, whether the source is released to public or not, and I myself am now reluctant to make optimized clients because of the above reason...sorry to those who want it. And at the same time, I cannot afford time to make optimized clients for Einstein, though I'm interested in theory of general relativity.
As Paul said (Hi there
)
As Paul said (Hi there Paul... nice to see you around here too...) optimization benefits depend on so many factors...
My 2 ¢...
Say with a regular client you can crunch 8 WUs a day, and with an optimized client you can crunch 16 WUs a day (this is my average in S@H, not the same, but bear with me). BUT 4 out of every 10 results are invalid due to errors in results are above tolerances (I have had no erroneous result, but let's say in E@H, 40% of results coming out from optimized clients are considered erroneous). This is way high, yet considering we are returning 16 results every day, I would have returned about 9.6 validated results. Is this better than the normal approach? Hell yeah... Proyect would need to dismiss 40% of my results, but at the end of the day I'ld be returning 1.6 results more... However, let's remember that for this example an optimized client will finish in half the time, and 40% of the times results won't validate..
BUT... if everyone (or a high percentage of users/hosts) use optimized clients, probably a WU should be crunched more than 3 times.. perhaps 4 or 5, or even 6, only to check that every client returned a valid result (NOT part of the 40% erroneous).
Did optimized clients helped? Not quite... It's just a matter of how much precision do you need... Time vs precision...
Cheers and happy crunchin'
RE: ... BUT 4 out of every
)
I presume you are talking exclusively about SAH because there are no TMR style optimised clients for EAH. This whole thread was started by TMR asking gently for the source code to be made available so he could do his optimising thing. So it's a bit of a long bow to be presuming that 40% of the optimised results might be erroneous when there aren't any such clients in the first place.
But getting back to my presumption that you are really talking about SAH. I'd be very interested in any link you could point us to which could show that there might even be a 4% increase in erroneous results from an optimised seti client, let alone anything like 40%.
Watcha smokin dude .... :).
Cheers,
Gary.
IMHO there's no reason on
)
IMHO there's no reason on earth 'not' to have optimized Clients.
Having custom compiled Clients is one of BOINC's key features, and the Server-sided redundancy/validation check takes care of the rest.
Ideal solution would be, however, that the Developers create their own, fully optimized Clients that will be auto-updated and downloaded by the appropriate platforms.
(beats me why they haven't done so already, Compilers and Expert advice + their know-how (if needed) are readily available)
The only fallback one must truly recognize is the fact that Custom Clients integrated via the app_info.xml will never auto-update.
...although arguably, people capable of manually inserting their own Clients 'should' be able to manually update those as well, but it remains a valid consideration.
Otherwise, it would be up to the Server Admins to throw a switch and put obsolete Version numbers to a rest with a
"There was work available but not for your Client Version. Please update your Client to Vx.xx" type of Message.
--------
So far, the SETI optimized Clients are a smashing success, with ~60-70% more performance at 100.0% validation levels in my case.
Not doing it would be kind of stupid actually, and those that don't trust those compiles can still use the slow default Clients.
RE: RE: ... BUT 4 out of
)
I was just assuming, IF TMR could compile some optimized clients, and due to the lower error tolerance, that 40% of every result would be invalid. It's an incredibly high rate, and I was trying to show that even with such a high rate, I could probably return more valid results at the end of the day.
As I said before...
Perhaps I was a little unclear.
In S@H, my 2.6GHz Laptop:
Regular client: 3 ~ 3.5 hours. 0% invalid results.
Optimized client: 1.5 ~ 1.7 hours. 0% invalid results.
In E@H, big and wild guess here:
Regular client: 5 ~ 10 hours. 0% invalid results
Optimized client: 2.5 ~ 5 hours. 40% invalid results
I used 40% because I know tolerances in E@H are slim, so I was trying to approach to the worst case scenario.
And about having to send the result to more than 4 in case results wouldn't validate, I meant in the way that the project's server automatically does that... just in case.
I'm sorry if I wasn't clear.
Cheers and happy crunchin'
Due to licensing issues, I
)
Due to licensing issues, I don't think the Einstein App Code can be released.
The project folks are doing everything they can to optimize their apps, and for a long time the Windows code was more efficient then others. The Linux users are just getting close to parity with Windows users now. The Mac users have a small advantage because of the alti-vec unit in some Power PC chips. Its my understanding that the Einstein team is/has looked at further optimization for all platforms, but that there is no significant benefit at this time for Windows, but that it continues to be an area of focus as compilers improve. I'm sure they will tweak the Windows app further, when it becomes practical to do so. Of all the BOINC projects, the Einstein team seems most heavily committed to getting the most of any platform. The benefit to both the science and the contributers is something they actively think about. Tetsuji did a great job on the SETI apps, but don't underestimate the developers. If they can sqeeze more performance out of Windows, they will.
- David
Team MacNN - The best Macintosh team ever.
RE: IMHO there's no reason
)
Actually, there are several. :)
First of all, as Gary was trying to make the point that it is very possible for clients compiled using different compile time "switches" to change the output values by enough of a margin to render them "invalid". One of the hardest points to keep in mind is that with computers there is no guarentee that the answer you get is "valid". Trying to keep it reletively simple I beat on this problem in the Wiki when you read about floating point and errors of same. If your tolerance for error is low, then the use of several "versions" of the program leads you to having more "invalid" results.
And I use "Valid" and "invalid" because each answer may only be "invalid" when compared to an answer developed on a different binary executable. LHC@Home, for example, has such strict requirements that they only have Windows and Linux clients because they can only use one compiler to get the outputs they need.
Secondarily, at this stage, BOINC does not have a really good means of CPU detection and identification that would enable easy selection of the correct binary for the platform. When I wrote the guide for installing an optimized SETI@Home optimized binary I was cringing inside with the expectation that people are going to use that and get mad at me cause I made a mistake along the way ... of course, the good news is that readership is low enough that maybe I will get "lucky" and no one will ever use that guide but me ...
And Shaktai give the other reason ...
Well, the Validator would
)
Well, the Validator would quickly tell the User (and more importantly, the person doing the optimizations) that the accuracy is insufficient.
Thus, those clients affected would never be released nor used (fast but invalid would be pointless).
Therefor, only those known to 100% validate would earn the required trust to be used by people would appear for public use. (in the past, AFAIK there were a very few SETI Clients in the early optimization stages that simply did not validate 100% and those were never used in public as well, no harm done)
Apart from a very few CPU versions (e.g. some Athlon64 and Pentium4 steppings), the plain CPU Vendor string is more than sufficient to give excellent baseline optimization guidelines. BOINC already does read it and displays it on the Computer Info Page.
e.g. knowing that the CPU is an Athlon64 3700+ will already tell BOINC that at least MMX, MMX+, 3dNow!, Enhanced 3dNow!, SSE and SEE2 are available for use.
The only thing it cannot tell in this example, is whether it supports SSE3 (Venice core), but that is a neglectible factor.
About the same is valid for just about every CPU existing, the plain Info already gathered by BOINC will always yield a good baseline with room for very effective optimization.
If for whatever reason the CPU string read is truly not usable, it can still default to a vanilla unoptimized x86 Client (IMHO this only happens to a few 'oddball' Linux installations reading like "Unkown CPU @ xxx MHz").
Since CPU detection sample codes are publicly available for both Intel and AMD Systems, those can be easily integrated at anytime, royalty free (then BOINC has more Info than it would ever need).
Not sure if E@H also gives it, but SETI has its desired validation limits published and those are strictly adhered to.
------------
I fully agree however on the Sourcecode release part.
If the Code contains proprietary technology that the team worked very hard for and do not wish to release it to public, that's their free choice of course.