Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
World Community Grid Forums
Category: Active Research Forum: Smash Childhood Cancer Thread: SCC program used suboptimal? |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 18
|
Author |
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 748 Status: Offline Project Badges: |
Heuristic0667 said:
----------------------------------------Tried on linux(Debian 4.9.130-2 amd64), and got 4 assignment running on amd64 instantaneously... Just make me more confusing I wouldn't mix Windows and Linux hosts, as it's an apples-to-oranges comparison. Only compare Windows to Windows. :)
|
||
|
NixChix
Veteran Cruncher United States Joined: Apr 29, 2007 Post Count: 1187 Status: Offline Project Badges: |
hchc wrote:
----------------------------------------Heuristic0667 said: Tried on linux(Debian 4.9.130-2 amd64), and got 4 assignment running on amd64 instantaneously... Just make me more confusing I wouldn't mix Windows and Linux hosts, as it's an apples-to-oranges comparison. Only compare Windows to Windows. :) Yes, all jobs in a replication group are sent to the same OS for precisely that reason, although it makes me scratch my head that different results are expected depending on the OS. Cheers [Edit 1 times, last edit by NixChix at Dec 25, 2018 5:28:25 PM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
You may know something I don't, but at the moment there are NO GPU-based science apps on WCG (and there haven't been for a long time), so I THINK that the programmes you're referring to are the ones that run when you hit "Show graphics" or you run the screensaver. on my, how embarrasing... |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
hchc wrote: Heuristic0667 said: Tried on linux(Debian 4.9.130-2 amd64), and got 4 assignment running on amd64 instantaneously... Just make me more confusing I wouldn't mix Windows and Linux hosts, as it's an apples-to-oranges comparison. Only compare Windows to Windows. :) Yes, all jobs in a replication group are sent to the same OS for precisely that reason, although it makes me scratch my head that different results are expected depending on the OS. Cheers How ridiculous... If the computation programs (on different platforms) return different results, how on earth are they going to determine which is correct? Maybe one of the computation program is incorrect, or both? I suppose THAT kind of fault shall never appear in a science research like this... But it just do There's many ways to solve this problem, but they just chose the worst one: They ran away from the problem and pretend they never seen... Or they just have got sooooooo many WU done, and cannot afford to throw about half of them away(I assume more than a half of them is done on a Windows client)? Oh yeah, and cheers~ [Edit 1 times, last edit by Former Member at Dec 26, 2018 1:26:03 AM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
There is more to it than just OS. From the BOINC docs:
----------------------------------------"Most numerical applications produce different outcomes for a given workunit depending on the machine architecture, operating system, compiler, and compiler flags. For some applications these discrepancies produce only small differences in the final output, and results can be validated using a 'fuzzy comparison' function that allows for deviations of a few percent. Other applications are 'divergent' in the sense that small numerical differences lead to unpredictably large differences in the final output. For such applications it may be difficult to distinguish between results that are correct but differ because of numerical discrepancies, and results that are erroneous. The 'fuzzy comparison' approach does not work for such applications." "BOINC provides a feature called homogeneous redundancy (HR) to handle divergent applications. HR divides hosts into 'numerical equivalence classes': two hosts are in the same class if they return identical results for your applications. The BOINC scheduler will send results for a given workunit only to hosts in the same class; this lets you use strict equality to compare redundant results." Additionally, when you say a program is "suboptimal", it begs the question, "suboptimal" for what? performance? accuracy? mathematics? support? What may be suboptimal to you may not be to the researchers. They are using what they have determined to be "optimal" for them based on the alpha testing, beta testing, and early production results. I assume if it wasn't producing what they need for the research they would have changed it by now. [Edit 1 times, last edit by Doneske at Dec 26, 2018 2:28:56 AM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
There is more to it than just OS. From the BOINC docs: "Most numerical applications produce different outcomes for a given workunit depending on the machine architecture, operating system, compiler, and compiler flags. For some applications these discrepancies produce only small differences in the final output, and results can be validated using a 'fuzzy comparison' function that allows for deviations of a few percent. Other applications are 'divergent' in the sense that small numerical differences lead to unpredictably large differences in the final output. For such applications it may be difficult to distinguish between results that are correct but differ because of numerical discrepancies, and results that are erroneous. The 'fuzzy comparison' approach does not work for such applications." "BOINC provides a feature called homogeneous redundancy (HR) to handle divergent applications. HR divides hosts into 'numerical equivalence classes': two hosts are in the same class if they return identical results for your applications. The BOINC scheduler will send results for a given workunit only to hosts in the same class; this lets you use strict equality to compare redundant results." Additionally, when you say a program is "suboptimal", it begs the question, "suboptimal" for what? performance? accuracy? mathematics? support? What may be suboptimal to you may not be to the researchers. They are using what they have determined to be "optimal" for them based on the alpha testing, beta testing, and early production results. I assume if it wasn't producing what they need for the research they would have changed it by now. Yeah... You're right. Thanks for the explanation. Well, by saying "optimal", I thought that performance is a real problem, and others are to be ignored, except accuracy. The accuracy of the research must be guaranteed, if the result we got after so many years of computation is faulty, the things we have done will be ultimately meaningless and a waste of time, money, and energy. And that's the last thing I want to see. |
||
|
KerSamson
Master Cruncher Switzerland Joined: Jan 29, 2007 Post Count: 1671 Status: Offline Project Badges: |
"Most numerical applications produce different outcomes for a given workunit depending on the machine architecture, operating system, compiler, and compiler flags. For some applications these discrepancies produce only small differences in the final output, and results can be validated using a 'fuzzy comparison' function that allows for deviations of a few percent. Other applications are 'divergent' in the sense that small numerical differences lead to unpredictably large differences in the final output. For such applications it may be difficult to distinguish between results that are correct but differ because of numerical discrepancies, and results that are erroneous. The 'fuzzy comparison' approach does not work for such applications." At first CPU (CPU mask) and CPU generation could cause some small differences in the results generated by two different machines. Secondly, as already mentioned, compiler, compiler options, OS libraries could cause as well such differences. This reality is one of the major reasons why there is no real GPU support for project supported by WCG. GPU are very fast but the computation accuracy is not in the main focus. Such accuracy is sufficient for pattern detection and comparison (e.g. seti) but could cause significant troubles for highly accurate computation works as required for the most projects supported by WCG. Numerical computations is a very particular area of computer science with very specific constraints. Cheers, Yves |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
"Most numerical applications produce different outcomes for a given workunit depending on the machine architecture, operating system, compiler, and compiler flags. For some applications these discrepancies produce only small differences in the final output, and results can be validated using a 'fuzzy comparison' function that allows for deviations of a few percent. Other applications are 'divergent' in the sense that small numerical differences lead to unpredictably large differences in the final output. For such applications it may be difficult to distinguish between results that are correct but differ because of numerical discrepancies, and results that are erroneous. The 'fuzzy comparison' approach does not work for such applications." At first CPU (CPU mask) and CPU generation could cause some small differences in the results generated by two different machines. Secondly, as already mentioned, compiler, compiler options, OS libraries could cause as well such differences. This reality is one of the major reasons why there is no real GPU support for project supported by WCG. GPU are very fast but the computation accuracy is not in the main focus. Such accuracy is sufficient for pattern detection and comparison (e.g. seti) but could cause significant troubles for highly accurate computation works as required for the most projects supported by WCG. Numerical computations is a very particular area of computer science with very specific constraints. Cheers, Yves Thanks a lot, I've learned so much from this place. |
||
|
|