rpi_logo
Help offered to improve MilkyWay@Home performance for Linux users
Help offered to improve MilkyWay@Home performance for Linux users
log in

Advanced search

Message boards : Number crunching : Help offered to improve MilkyWay@Home performance for Linux users

Author Message
Luz Angélica
Send message
Joined: 3 Jul 18
Posts: 5
Credit: 1,614,141
RAC: 0

Message 67651 - Posted: 3 Jul 2018, 16:34:29 UTC

I'm completing a whole work unit per thread per hour on skylake-avx512 with my optimized MilkyWay@Home binary (the normal application, not N-Body). If you use Linux, I can show you how this is done. There are a few tricks you'll need to know; if you're interested in compiling an optimized binary, I can save you the time and effort of figuring it out. Reply or PM if you would like help with this.

Profile Keith Myers
Avatar
Send message
Joined: 24 Jan 11
Posts: 160
Credit: 104,275,171
RAC: 25,334

Message 67652 - Posted: 3 Jul 2018, 19:27:19 UTC - in response to Message 67651.

How about tackling the gpu separation binary for Linux. I had to drop MW on all my Linux machines because the gpu binary only errors out. I was told the only way to fix it was to run a newer BOINC.
____________

Luz Angélica
Send message
Joined: 3 Jul 18
Posts: 5
Credit: 1,614,141
RAC: 0

Message 67653 - Posted: 3 Jul 2018, 20:41:36 UTC - in response to Message 67652.

Sorry to hear it's not working. I don't see a git clone available for the GPU app, so the only thing I can think of is compiling the current BOINC. I don't know what version of the BOINC libraries the GPU app is compiled against; maybe it's an incompatibility between that and the version you're using. It's worth a try IMO.

Profile Keith Myers
Avatar
Send message
Joined: 24 Jan 11
Posts: 160
Credit: 104,275,171
RAC: 25,334

Message 67654 - Posted: 4 Jul 2018, 18:30:57 UTC - in response to Message 67653.

Yes, the problem arises on any BOINC version earlier than 7.6.3. Some helpful posts highlighted the known issue. I documented my problem in the New Linux system trashes all tasks thread.

I tried to compile BOINC for the 7.8.3 version but failed. Don't have the skill set or know what I am doing.
____________

Luz Angélica
Send message
Joined: 3 Jul 18
Posts: 5
Credit: 1,614,141
RAC: 0

Message 67655 - Posted: 4 Jul 2018, 18:53:27 UTC - in response to Message 67654.

The current version is 7.11.0. If you would like assistance, tell me the commands you're using to attempt the build and paste the error output.

DadX
Send message
Joined: 27 Oct 12
Posts: 7
Credit: 5,051,958
RAC: 2,037

Message 67663 - Posted: 9 Jul 2018, 20:40:09 UTC - in response to Message 67651.

Hi, I'm currently running a locally compiled M@H in Ubuntu Mate on a Raspberry PI3. It's slow, completing tasks in the 210,000-238,000 second range. Any advise you can give me that will improve performance would be appreciated.

Regards,
DadX

Luz Angélica
Send message
Joined: 3 Jul 18
Posts: 5
Credit: 1,614,141
RAC: 0

Message 67664 - Posted: 10 Jul 2018, 20:38:21 UTC - in response to Message 67663.

That sounds about right for a Raspberry Pi, I wouldn't expect any better. How does it compare to the stock app (if there is one for ARM)? I can give you detailed instructions for the build if you like. Tell me what steps you followed to compile it and I'll see if anything looks wrong. Sorry for the delay in replying, I only check this once a day anymore because of the lack of activity.

DadX
Send message
Joined: 27 Oct 12
Posts: 7
Credit: 5,051,958
RAC: 2,037

Message 67666 - Posted: 11 Jul 2018, 18:55:19 UTC - in response to Message 67664.

The project does not supply an ARM executable, I used instructions posted a some years ago by Jake and a few others to make the executable. See the thread "Raspberry pi 3 and Milkyway@home".

I used the instructions almost exactly as documented. In almost all cases where apt-get couldn't retrieve something I moved on with the assumption that something else had superseded it or its just different in Ubuntu. The final product works so it seems to have been a valid assumption. I did have to rename the executable because what it created didn't match what they documented as the correct name.

During the build I was looking at the results of each step so I didn't redirect the results to a file. Someday soon I'll recompile it for a PI running stretch (or whatever the current "native" OS is at the time) and see if there is a difference.

Separately I might try moving the installation from the current SD card to a USB hard drive but I doubt that will make a significant difference.

Any advice you can offer would be appreciated.

Luz Angélica
Send message
Joined: 3 Jul 18
Posts: 5
Credit: 1,614,141
RAC: 0

Message 67670 - Posted: 12 Jul 2018, 19:25:23 UTC - in response to Message 67666.

It sounds like you've done everything right. Like I said, I wouldn't expect better performance than that from a Raspberry Pi, the CPU is very slow, I don't think it's worth investing any time or effort in using that device for this project. If you have an x86_64-based system, I can help you compile for your specific CPU, it involves CFLAGS and CXXFLAGS. Source files need to be edited to get it to build on x86_64, I can tell you exactly what needs to be changed, I guess you probably didn't have that issue with the ARM build. The flags probably don't matter for your build, it's a quite basic processor in comparison to a typical desktop one.


Post to thread

Message boards : Number crunching : Help offered to improve MilkyWay@Home performance for Linux users


Main page · Your account · Message boards


Copyright © 2018 AstroInformatics Group