First, will there be a Windows "power users" application anytime soon? It is quite discouraging to already know that AMD processors running on Windows have a performance penalty vs. the equivalent processor running Linux. Now, that penalty is increased... My latest batch of results that I have to work on naturally appear to be at the upper end of the runtime variation, so the news of a widened performance delta between Windows and Linux for AMD systems comes as a "double whammy"...
Second, in lieu of an updated Windows application, what would be the estimated overhead involved with running this "power users" application inside of my Ubuntu 7.10 VMware Virtual Machine? Is this something that needs to be tested anyway (running inside a VM)?
Oh, and third, if I were to run a VM and it is faster, is there any way that I can process the existing tasks that I have assigned to my Windows host by the VM "host" and return them back through the Windows host?
BOINC and Ubuntu never quite seemed to like each other on this box. But it obviously isn't a power user app problem. I can't wait to see the speedup for that, even if this is a Core 2 I should see quite a difference I think...
Strangely, BOINC 5.10.28 with standard GUI is only available for Ubuntu and Debian. I am using SuSE 10.1 and shall stick to 5.10.21. But why?
Tullio
Policy change.
It was taking too long to try to get a general Linux GUI build. Rom is now handling the Windows and Linux builds and that was taking time away from coding for the upcoming version 6.
I have the latest alpha (might be release by now) running on Fedora 7. It took soft linking a few libs, but I think Rom recompiled it with those linked statically.
Brian, as for your last question: That would work if you are willing to make the effort. People who use PCs which are not connected to the internet do it all the time. All you have to do is prevent BOINC from contacting the servers as long as it's crunching (meaning you disallow network usage). Then, when the WUs are crunched, you zip up your BOINC folder, copy it back to the original machine and let it upload. This is important because the servers don't accept WUs when they're not coming from the host they were assigned to.
As for the main reason of this post: I got a signal 11 running as normal user with a vanilla client (and the power user app). Debugger was running this time, but I'd appreciate if someone told me how to actually get to the results ;-) so, where the core dump is hidden.
Im talking about this WU: http://einsteinathome.org/task/89904536
Brian, as for your last question: That would work if you are willing to make the effort. People who use PCs which are not connected to the internet do it all the time. All you have to do is prevent BOINC from contacting the servers as long as it's crunching (meaning you disallow network usage). Then, when the WUs are crunched, you zip up your BOINC folder, copy it back to the original machine and let it upload. This is important because the servers don't accept WUs when they're not coming from the host they were assigned to.
.....
Actually, not quite true. I've successfully moved BOINC from one machine to another, and crunched/uploaded/reported WUs from a different host from the one they were downloaded on.
The key thing here is that the servers are checking the 'Host ID' of the reporting computer. So if you move an entire BOINC installation, its host identity travels with it, and crunching can continue.
But that normally only works if the two computers run the same platform, so all the executable file references etc. stay the same (and it's much easier to do it if the two platforms are both Windows, because then the BOINC installation - at least while we're still using BOINC v5.xx.xx - consists of a single folder tree).
As to Brian's question, I'm sure that it would be possible to set up a new BOINC installation in VMware, copy the account and host information from the Windows installation (instead of attaching to the project as normal), install the power users' app manually with its app_info, and carry on crunching from there. You could presumably also copy the data files, if you also filleted the relevant file info out of client_state.xml. But whether you could actually transfer work-in-progress would depend on whether the checkpoint file format is compatible between the two apps - remember, there have been quite a few changes in checkpointing recently.
Oh, and this would have to be an all-or-nothing transfer. You couldn't run the Windows installation and the VMware installation in parallel. BOINC would detect that the scheduler_rpc sequence numbers were getting out of step, and assign one (or both) of the installations a new host ID.
Altogether, probably more trouble than its worth. I would set 'no new tasks' on the Windows installation, report the last WU when it's ready, and then do a brand new install in VMware and let it run under a new host ID. Then, when Bernd has had time to optimise the Windows app and take out the AMD crippleware, you can go back to the old native Windows host ID and pick up where you left off.
Altogether, probably more trouble than its worth. I would set 'no new tasks' on the Windows installation, report the last WU when it's ready, and then do a brand new install in VMware and let it run under a new host ID. Then, when Bernd has had time to optimise the Windows app and take out the AMD crippleware, you can go back to the old native Windows host ID and pick up where you left off.
Well, Bernd, any news about other platform improvements?
Then, when Bernd has had time to optimise the Windows app and take out the AMD crippleware, you can go back to the old native Windows host ID and pick up where you left off.
There is no "AMD crippleware" in the Win app any longer, that was something that happend in S5R2 and was ionjected by an older Microsoft Compiler. The current app is built with a newer version of that compiler and does no longer contain an explicit check for AMD processors.
Will all improvements of the Beta/PowerUser-Applications automatically make it into the final (auto-updated) Application once released ?
I ask because I wonder whether it is worth the trouble manually implementing the Beta Apps into my Network (being a bit work-intensive due to number of Systems involved, I'd preferrably settle for waiting until it's released ;) ).
The beta apps will be made official as soon as they are thoroughly tested, but iirc the power user apps won't be made official since they have limited features and/or only work on a certain architecture, whereas the official app has to be "mainstream compatible".
Then, when Bernd has had time to optimise the Windows app and take out the AMD crippleware, you can go back to the old native Windows host ID and pick up where you left off.
There is no "AMD crippleware" in the Win app any longer, that was something that happend in S5R2 and was ionjected by an older Microsoft Compiler. The current app is built with a newer version of that compiler and does no longer contain an explicit check for AMD processors.
Yet an equivalent AMD processor has better performance in Linux. Somehow the Linux code appears to be faster. The closest comparison to my specific processor I can do is against an X2 4400+, but unless it is overclocked, it doesn't really compare. I think a direct comparison based on dual-core processors would need to be either a 5200+ or 5600+, as my core clock is 2750MHz... As for single core, I'm closer in performance to a FX-57 processor (default 2800MHz, but memory only at DDR-400, while my memory is DDR-500), but I had someone who runs one of the stats sites (Toby, I think), check for FX-57 running Linux, and none were found... That was some time ago though...
To be honest, I really don't want to have to resort to switching to a VM... My gut feeling is that the VM will take away some of the performance, but the Linux app will still end up faster...
Annika is pretty right regarding the policies of "Beta" and "Pwer User's" Apps.
However I'm tempted to try to build completely different Apps for differnt CPU types and let the scheduler decide which one to deliver based on information from the Client instead of switching code segments in the App basd on loacal CPU feature detection. This way an App that now is a "Power User's App" could once make it into an 'official' one some time. But that's not my main concern right now.
Currently my top priority items for Einstein@home Apps are:
* fix the 'signal 11' problem of the Linux App (4.20/21). The Linux Apps migth be fast, but currently Linux hast the highest failure rate of all platforms, which is mainly due to this 'signal 11' errors.
* migrate the code to BOINC API v6. Instad of a seperate thread this will run graphics in a different process, so that problems with graphics don't crash the 'science' App. This should greatly improve the stability of the Windows App and also make the screensaver work on Windows Vista. It will also finally enable to run BOINC graphics in a xscreensaver hack, i.e. work as a real screensaver on Linux.
* fix the fast 'linear' SIN/COS calculation code for all platforms. Currently this only works when compiled with Apple's version of gcc on MacOS Intel. In principle it should be generic and thus give soem speedup on all platforms.
Obviously this is still dominated by bug hunting and fixing. If I could improve speed along the way without hindering that, I'll do this and publish what I find working.
Currently the SSE code can only be compiled with gcc; and when linking gcc code to MSC code the debugging information of the gcc objects get lost. Therefore I find it rather unlikely that there will be a Windows App with an SSE 'hot-loop', say, this year.
Well, I have a couple of
)
Well, I have a couple of questions...
First, will there be a Windows "power users" application anytime soon? It is quite discouraging to already know that AMD processors running on Windows have a performance penalty vs. the equivalent processor running Linux. Now, that penalty is increased... My latest batch of results that I have to work on naturally appear to be at the upper end of the runtime variation, so the news of a widened performance delta between Windows and Linux for AMD systems comes as a "double whammy"...
Second, in lieu of an updated Windows application, what would be the estimated overhead involved with running this "power users" application inside of my Ubuntu 7.10 VMware Virtual Machine? Is this something that needs to be tested anyway (running inside a VM)?
Oh, and third, if I were to run a VM and it is faster, is there any way that I can process the existing tasks that I have assigned to my Windows host by the VM "host" and return them back through the Windows host?
Thanks...
RE: RE: BOINC and Ubuntu
)
Policy change.
It was taking too long to try to get a general Linux GUI build. Rom is now handling the Windows and Linux builds and that was taking time away from coding for the upcoming version 6.
I have the latest alpha (might be release by now) running on Fedora 7. It took soft linking a few libs, but I think Rom recompiled it with those linked statically.
So give it a whirl.
Kathryn :o)
Einstein@Home Moderator
Brian, as for your last
)
Brian, as for your last question: That would work if you are willing to make the effort. People who use PCs which are not connected to the internet do it all the time. All you have to do is prevent BOINC from contacting the servers as long as it's crunching (meaning you disallow network usage). Then, when the WUs are crunched, you zip up your BOINC folder, copy it back to the original machine and let it upload. This is important because the servers don't accept WUs when they're not coming from the host they were assigned to.
As for the main reason of this post: I got a signal 11 running as normal user with a vanilla client (and the power user app). Debugger was running this time, but I'd appreciate if someone told me how to actually get to the results ;-) so, where the core dump is hidden.
Im talking about this WU:
http://einsteinathome.org/task/89904536
RE: Brian, as for your last
)
Actually, not quite true. I've successfully moved BOINC from one machine to another, and crunched/uploaded/reported WUs from a different host from the one they were downloaded on.
The key thing here is that the servers are checking the 'Host ID' of the reporting computer. So if you move an entire BOINC installation, its host identity travels with it, and crunching can continue.
But that normally only works if the two computers run the same platform, so all the executable file references etc. stay the same (and it's much easier to do it if the two platforms are both Windows, because then the BOINC installation - at least while we're still using BOINC v5.xx.xx - consists of a single folder tree).
As to Brian's question, I'm sure that it would be possible to set up a new BOINC installation in VMware, copy the account and host information from the Windows installation (instead of attaching to the project as normal), install the power users' app manually with its app_info, and carry on crunching from there. You could presumably also copy the data files, if you also filleted the relevant file info out of client_state.xml. But whether you could actually transfer work-in-progress would depend on whether the checkpoint file format is compatible between the two apps - remember, there have been quite a few changes in checkpointing recently.
Oh, and this would have to be an all-or-nothing transfer. You couldn't run the Windows installation and the VMware installation in parallel. BOINC would detect that the scheduler_rpc sequence numbers were getting out of step, and assign one (or both) of the installations a new host ID.
Altogether, probably more trouble than its worth. I would set 'no new tasks' on the Windows installation, report the last WU when it's ready, and then do a brand new install in VMware and let it run under a new host ID. Then, when Bernd has had time to optimise the Windows app and take out the AMD crippleware, you can go back to the old native Windows host ID and pick up where you left off.
RE: Altogether, probably
)
Well, Bernd, any news about other platform improvements?
RE: Then, when Bernd has
)
There is no "AMD crippleware" in the Win app any longer, that was something that happend in S5R2 and was ionjected by an older Microsoft Compiler. The current app is built with a newer version of that compiler and does no longer contain an explicit check for AMD processors.
CU
Bikeman
A question for my
)
A question for my understanding :
Will all improvements of the Beta/PowerUser-Applications automatically make it into the final (auto-updated) Application once released ?
I ask because I wonder whether it is worth the trouble manually implementing the Beta Apps into my Network (being a bit work-intensive due to number of Systems involved, I'd preferrably settle for waiting until it's released ;) ).
The beta apps will be made
)
The beta apps will be made official as soon as they are thoroughly tested, but iirc the power user apps won't be made official since they have limited features and/or only work on a certain architecture, whereas the official app has to be "mainstream compatible".
RE: RE: Then, when Bernd
)
Yet an equivalent AMD processor has better performance in Linux. Somehow the Linux code appears to be faster. The closest comparison to my specific processor I can do is against an X2 4400+, but unless it is overclocked, it doesn't really compare. I think a direct comparison based on dual-core processors would need to be either a 5200+ or 5600+, as my core clock is 2750MHz... As for single core, I'm closer in performance to a FX-57 processor (default 2800MHz, but memory only at DDR-400, while my memory is DDR-500), but I had someone who runs one of the stats sites (Toby, I think), check for FX-57 running Linux, and none were found... That was some time ago though...
To be honest, I really don't want to have to resort to switching to a VM... My gut feeling is that the VM will take away some of the performance, but the Linux app will still end up faster...
Annika is pretty right
)
Annika is pretty right regarding the policies of "Beta" and "Pwer User's" Apps.
However I'm tempted to try to build completely different Apps for differnt CPU types and let the scheduler decide which one to deliver based on information from the Client instead of switching code segments in the App basd on loacal CPU feature detection. This way an App that now is a "Power User's App" could once make it into an 'official' one some time. But that's not my main concern right now.
Currently my top priority items for Einstein@home Apps are:
* fix the 'signal 11' problem of the Linux App (4.20/21). The Linux Apps migth be fast, but currently Linux hast the highest failure rate of all platforms, which is mainly due to this 'signal 11' errors.
* migrate the code to BOINC API v6. Instad of a seperate thread this will run graphics in a different process, so that problems with graphics don't crash the 'science' App. This should greatly improve the stability of the Windows App and also make the screensaver work on Windows Vista. It will also finally enable to run BOINC graphics in a xscreensaver hack, i.e. work as a real screensaver on Linux.
* fix the fast 'linear' SIN/COS calculation code for all platforms. Currently this only works when compiled with Apple's version of gcc on MacOS Intel. In principle it should be generic and thus give soem speedup on all platforms.
Obviously this is still dominated by bug hunting and fixing. If I could improve speed along the way without hindering that, I'll do this and publish what I find working.
Currently the SSE code can only be compiled with gcc; and when linking gcc code to MSC code the debugging information of the gcc objects get lost. Therefore I find it rather unlikely that there will be a Windows App with an SSE 'hot-loop', say, this year.
BM
BM