Message boards :
Number crunching :
Lunatics v0.41!
Message board moderation
Author | Message |
---|---|
Cliff Harding Send message Joined: 18 Aug 99 Posts: 1432 Credit: 110,967,840 RAC: 67 |
I wanted to ask this over at Lunatics, but registration is disabled at the moment. I deleted my app_info.xml file on my i7/950 machine this morning to generate what I'd hoped to be a cleaner version after reinstalling v0.41. The points/bullets that I specified as always are: 1)Use SSSE3 instructions 2)AP_v6 (both CPU & NV GPU) 3)Cuda50 Can some please explain to me in layman terms why the installer, with the above bullets specified, still includes all of the other types? I had thought that this version was constructed in such a way as to be more specific as to what was to be generated. Even though I checked SSSE3, I still see SSE & SSE2. The same for v7 Cuda specs, specified Cuda50, but still see plan_ class for Cuda22/23/32/ & 42 all using the same Lunatics_x41zc_win32_cuda50.exe file. I guess I have never paid this much attention before, just enough to get it running. Verrrrrrry confusing. I don't buy computers, I build them!! |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Hi Cliff, Since the earliest 'unified installers' the goals with those have primarily been general applicability & to avoid losing tasks where possible. As such all necessary app, platform, version, & standard plan classes are provided, as no prior installation/migration expert knowledge is gathered (other than the assumption of Boinc installation & project attach, and some CPU detection facilities recently incorporated). in a nutshell, app_info.xml is read only once, at Boinc startup. That means your (and as it happens my own) preference for a 'lean' app_info, is a cosmetic one, rather than a performance related one. This will likely remain the standard 'catch-all' approach until sophisticated application management facilities are built eventually (for other purposes than lean installation, but by happy coincidence likely providing one). I do customise / lean-out my own app_info for the sakes of being pedantic etc. direct edits on a full modern app_info.xml with many apps is a challenge, so myself I tend to modify the aistub files & merge them with the installer supplied command. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Cliff Harding Send message Joined: 18 Aug 99 Posts: 1432 Credit: 110,967,840 RAC: 67 |
Thanks Jason, you have explained a lot. Am surprised to hear from the man himself. I will try to use the aistub files to get a cleaner, leaner app_info. Hopefully, I won't screw up things to badly. I don't buy computers, I build them!! |
Mike Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 |
Jason just beat me to it. But perfectly fine by me. With each crime and every kindness we birth our future. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
I wrote a schema for app_info to help me avoid mistakes. I too try to keep it clean but I still make "silly" mistakes now and then. I'm not sure if it's human nature or just my nature. http://setiathome.berkeley.edu/forum_thread.php?id=72229 |
William Send message Joined: 14 Feb 13 Posts: 2037 Credit: 17,689,662 RAC: 0 |
Thanks Jason, you have explained a lot. Am surprised to hear from the man himself. I will try to use the aistub files to get a cleaner, leaner app_info. Hopefully, I won't screw up things to badly. Basically, in a nutshell, at your own risk: As soon as you have no 'old' work left you can cull all the additional <app_version> entries per <app> - you do need the first one, all the extra ones are there to pick up old work. A person who won't read has no advantage over one who can't read. (Mark Twain) |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.