Posts by [AF>HFR>RR] Black Hole Sun
|
1)
Message boards :
Number crunching :
Linux x64 CUDA app - HOWTO?..
(Message 34689)
Posted 19 Dec 2009 by  [AF>HFR>RR] Black Hole Sun
Post: Well, no idea since I missed Milkyway's first CUDA apps: I only tried with the current 0.24 version. I believe my system is OK since Collatz used to work without any problem until I began to get freezes with their new app, and this summer, I ran Aqua's CUDA app without any problem either. |
|
2)
Message boards :
Number crunching :
Linux x64 CUDA app - HOWTO?..
(Message 34662)
Posted 18 Dec 2009 by [AF>HFR>RR] Black Hole Sun
Post: |
|
3)
Message boards :
Number crunching :
Linux x64 CUDA app - HOWTO?..
(Message 34610)
Posted 17 Dec 2009 by [AF>HFR>RR] Black Hole Sun
Post: |
|
4)
Message boards :
Number crunching :
Sudden mass of WU's finishing with Computation Error
(Message 34362)
Posted 7 Dec 2009 by [AF>HFR>RR] Black Hole Sun
Post: Hi, I think I have a problem: http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=9243561 Check my host to get the other errored out wus. In the meantime, I suspended the project not to waste tons on wus. I'm running Ubuntu 9.10x64 with boinc 6.10.17 and nvidia 190.42 drivers for my GTX275 GPU (896 Mb RAM) Note : Aqua is running on the CPU Thanks for your help |
|
5)
Message boards :
Number crunching :
app v12
(Message 8828)
Posted 21 Jan 2009 by [AF>HFR>RR] Black Hole Sun
Post: Based on my hosts: Opteron 170 (XP 32) RAC estimation: 2085 (v0.7) / 2070 (v12) => 1% drop Core2Duo 4300 (Ubuntu 64) RAC estimation: 1994 (v0.7) / 1475 (v12) => 26% drop Core2Duo 6600 (Ubuntu 64) RAC estimation: 2385 (v0.7) / 1787 (v12) => 25% drop Core2Quad 6600 (Ubuntu 64) RAC estimation: 4742 (v0.7) / 3564 (v12) => 25% drop Houston, I think we have a problem with the Linux64 version... |
|
6)
Message boards :
Number crunching :
What applications will be valid?
(Message 8799)
Posted 21 Jan 2009 by [AF>HFR>RR] Black Hole Sun
Post: I just don't understand all that mess, sorry. This is a scientific project, right ? Results accuracy matters, right ? So, the project provides a stock app : this should be enough for everyone. Now, as source code is available, volunteers (thanks to them) try and manage to make the official app even better, faster. Great, thanks again. Really. These volunteers release optimized apps they offer to the crunchers community. As long as these optimized apps are kept up to date by responsible users who install them on their machines, everything's fine. Here, from what I understand, the project releases new official apps using the good job from volunteers working on enhancing the stock apps. So what happens ? Are there irresponsible users out there who install optimized apps and leave them on their own ? Wouldn't it be logical that responsible users use the optimized apps corresponding to the current version of the stock app ? OK, Travis multiplied the official versions these last days, which means it created some confusion. Yes, each new stock version should have required a corresponding optimized version to send new work. Seems this was not possible for whatever technical or human reason. So far, from what I understand, stock app is V0.12. Optimized apps are based on V0.7. If Travis plans to release new versions for the next days, the best is to stick on the official app for a moment to let things cool down. Once the version is stable and somewhat durable, then volunteers will probably release new optimized version based on the current official app. Again, using an optimized app "freezes" any app update initiated by the project server. This means that everyone running an optimized version should frequently check that it is still safe to use it. For people who can't check their hosts that often, the solution is to keep up with the stock app. As simple. My 2 cents |
|
7)
Message boards :
Number crunching :
app v12
(Message 8738)
Posted 20 Jan 2009 by [AF>HFR>RR] Black Hole Sun
Post: Travis, do you know why, this host : Hi Sp0wn Check the result ;) Validate state is Invalid May be a bad bunch of wus ? |
|
8)
Message boards :
Number crunching :
app v12
(Message 8736)
Posted 20 Jan 2009 by [AF>HFR>RR] Black Hole Sun
Post: Hi, Opteron 170, 2,0 GHz, XP 32 : 3300 sec average, v10 and V12 Core2Duo 4300, 2,0 GHz, Ubuntu 64 : 4600 sec average V12 (7300 sec average V10) Core2Quad 6600, 2,4 HZz, Ubuntu 64 : 3900 sec average V12 (6200 sec average V10) So, V12 is undoubtly faster. From memories, I would say say V12 is faster than V7 under Windows XP 32. For sure, and completion times show it, Linux 64 V12 is undoubtly slower than V7 (about 30% slower). Other hint for compiling : I doubt that my old Opteron (server version of the socket 939 Athlon 64 x2) could beat my Quad 6600 (both @ stock clock). I know, architecture are not the same, but the gap is not normal. The Linux 64 version lacks optimizations. Good luck |
|
9)
Message boards :
Number crunching :
Vote for the MilkyWay favicon!
(Message 8624)
Posted 18 Jan 2009 by [AF>HFR>RR] Black Hole Sun
Post: #6 for me |
|
10)
Message boards :
Number crunching :
New App status
(Message 5361)
Posted 8 Oct 2008 by [AF>HFR>RR] Black Hole Sun
Post: Hi all, If I may add my 2 (euro) cents, one should never forget this is volunteer computing. - On user side, we want our efforts to be used at their best. Because our efforts are time and money (electricity bill, hardware). But not only as we all have an interest into the science of the different projects (otherwise we wouldn't crunch for them): knowing that our efforts efficiency could be improved in such a drastic proportion is somewhat frustrating. - On project side, never forget what is Boinc: a meaning for money-less projets to exist. If a project had funds, it would not need us: it would just buy or hire Crays to do the stuff. Money-less also means that a project requires the best balance between science, programming and hardware concerns. As far as I can guess from my Boinc experience, projects generally have scientific skills, poor programming skills and "hope it can deal with" hardware. Now just imagine you're the scientist: your concern is science accuracy, above anything else. As no one can be an expert in all domains and as projects do not have enough funds to hire high level coders, programming is always "conservative". Check, double-check, million-check a result to be sure it is accurate. This can even lead to errors as you may compute several times something using different methods. Milksop at try experiment proves MW coding needs a huge improvment. We crunchers deserve a better app for our $/€/£ spent crunching on this project. The project science deserves a better app. I think we all agree with that. Now, flaming at the project admins will never make things go better: they do not have the computer skills (or time) to make the code better. Proving the possible efficiency and telling them "work on your f*cking code or I leave" is not enough. Here, computer skills are on user side, science skills are on project side. WORK TOGETHER ! All projects are interested in efficiency gains for their apps as long as science remains accurate. But those who know how to perform this need to explain/prove this to the scientists. Nothing else to be said I think: work together. Black Hole Sun PS: for project admins (not only MW's), publishing your apps code would definitely help you. There are skilled guys out there who are ready to help improve your app efficiency preserving science accuracy. Not being skilled in computer stuff is not a fault: you're gifted in science. Albert Einstein himself neeeded to learn how to walk ;) On my side, I'm not skilled either in coding nor science: I'm just an humble volunteer who woud like to participate as best as I can to projects that I find interesting. |
©2023 Astroinformatics Group