Why not get BOINC to do it? You aren't the only project that uses FFT's and if it had a wisdom file generated (maybe when it does CPU benchmarks) then ALL the projects could make use of it rather than having to do their own.
Interesting idea, but there are a few caveats:
- how would BOINC know for which transform types / size(s)! the apps would want wisdom generated?
- how would BOINC know which version(s) of FFTW are required by the different apps?
- How would boinc call those specific FFTW version implementations? E.g. Einstein@Home uses apps that have FFTW linked statically into the code. BOINC can't call that directly. So have FFTW supplied by dynamic libs? But what if the app is 32 bit and BOINC is 64 bit ......
All in all, I guess making BOINC try to generate FFTW wisdom is not a good idea and a can of worms. One would have to think along different, more general concepts perhaps, e.g. an app could signal a need for uninterrupted precomputations to BOINC, and then BOINC would run the app once to do that, not interrupting it (with a special command line parameter?), plus a mechanism to keep app generated files across results. This could then be used not just for FFTW wisdom but also for any other similar, not "checkpointable", preprocessing stuff.
Still, a lot of hassle to extend BOINC in this way.
Quote:
When you say it takes a while, how long are we talking here? The Seti optimised apps generate wisdom files, so it makes sense to have one that all projects could utilise per host.
We are talking many hours here. One wisdom file will not fit all projects, because different apps in different projects will use different versions of FFTw and different types & sizes of transforms.
I saw that Albert@Home has a Raspberry Pi application since yesterday but no takers yet. I think it would be great to support ARM. I'm not an expert but Rasperry Pi, Parallella by Adapteva (perhaps not because they use different technology?), and a good Ubuntu phone (which I consider buying as my first smartphone) allow for lots of possible users and they may be electricity efficient, too.
I saw that Albert@Home has a Raspberry Pi application since yesterday but no takers yet. I think it would be great to support ARM. I'm not an expert but Rasperry Pi, Parallella by Adapteva (perhaps not because they use different technology?), and a good Ubuntu phone (which I consider buying as my first smartphone) allow for lots of possible users and they may be electricity efficient, too.
I'll attach mine to Albert once it's finished it's current crop of asteroids work (they are taking 3 days each).
David Carrion has a number of project apps packaged up on his blog. This includes the Einstein app although if HBE has updated it to use less memory its probably the old one. His blog can be found here
The Raspberry Pi app on Albert is still experimental, but feel free to give it a try. The app compiled by David and linked in his blog probably needs rebuilding, since we have now switched to compressed input files on Albert and for this you need a v1.33/1.34 generation app version. We are also beginning to do the same transition on Einstein@Home now.
Actually the test on Albert is also testing a new pool of BRP4 workunits, which are 1/8th the size of the regular ones (which are meant for desktop CPU and GPU). A Raspi which is moderately overclocked should be able to complete one of the new tasks in about 1 to 1.5 days.
The new app is optimized for low memory profile. It requires a bit less than half the RAM of a "naive" port of the BRP4 source, but as there is no free lunch, it is also a bit slower. With only 256 MB (or max 512 MB depending on HW and setup of the graphics mem), I think it's more important to have a low memory footprint. I have one running on my Raspbmc media center Raspi, so far w/o any problem.
What's gone from it? Did it use some kind of LUT that could be disabled?
The new version just does the FFTs in-place, some other computations are done in-place and some memory is recycled from previous steps. Unfortunately this slows down the code, but as I said...no free lunch ;-)
Bernd has now enabled the validator on Albert that is taking care of the "Raspberry-Pi"-sized BRP4 workunits. All seems well. So the Albert@Home test run for the Raspberry Pis is now fully functional, end-to-end.
We are still experimenting with the port of the app to Android. We suffered a bit of a delay when one of the team (me :-( ) got sick for ca. two weeks, but now I'm back and we will resume work on the app. Please bear with us.
That´s nice to hear and i hope you´re feeling well again.
I can´t help you with that unfortunately because i´ve no knowledge of that but what i know is that programming is not a simple thing and for sure it can take a lot of time depending on what you are trying to do.
So i wish you the best with that and hopefully it works in the next time because there are so many Phones and Tablets out there in the world and their Performance grows up and up.
I like that idea of Mobile crunching that would give all the Distributed Computing Networks new or rather more possibilitys and on user side more credit for very low energy costs.
RE: Why not get BOINC to
)
Interesting idea, but there are a few caveats:
- how would BOINC know for which transform types / size(s)! the apps would want wisdom generated?
- how would BOINC know which version(s) of FFTW are required by the different apps?
- How would boinc call those specific FFTW version implementations? E.g. Einstein@Home uses apps that have FFTW linked statically into the code. BOINC can't call that directly. So have FFTW supplied by dynamic libs? But what if the app is 32 bit and BOINC is 64 bit ......
All in all, I guess making BOINC try to generate FFTW wisdom is not a good idea and a can of worms. One would have to think along different, more general concepts perhaps, e.g. an app could signal a need for uninterrupted precomputations to BOINC, and then BOINC would run the app once to do that, not interrupting it (with a special command line parameter?), plus a mechanism to keep app generated files across results. This could then be used not just for FFTW wisdom but also for any other similar, not "checkpointable", preprocessing stuff.
Still, a lot of hassle to extend BOINC in this way.
We are talking many hours here. One wisdom file will not fit all projects, because different apps in different projects will use different versions of FFTw and different types & sizes of transforms.
Cheers
HB
I saw that Albert@Home has a
)
I saw that Albert@Home has a Raspberry Pi application since yesterday but no takers yet. I think it would be great to support ARM. I'm not an expert but Rasperry Pi, Parallella by Adapteva (perhaps not because they use different technology?), and a good Ubuntu phone (which I consider buying as my first smartphone) allow for lots of possible users and they may be electricity efficient, too.
RE: I saw that Albert@Home
)
I'll attach mine to Albert once it's finished it's current crop of asteroids work (they are taking 3 days each).
David Carrion has a number of project apps packaged up on his blog. This includes the Einstein app although if HBE has updated it to use less memory its probably the old one. His blog can be found here
BOINC blog
Hi! The Raspberry Pi app
)
Hi!
The Raspberry Pi app on Albert is still experimental, but feel free to give it a try. The app compiled by David and linked in his blog probably needs rebuilding, since we have now switched to compressed input files on Albert and for this you need a v1.33/1.34 generation app version. We are also beginning to do the same transition on Einstein@Home now.
Actually the test on Albert is also testing a new pool of BRP4 workunits, which are 1/8th the size of the regular ones (which are meant for desktop CPU and GPU). A Raspi which is moderately overclocked should be able to complete one of the new tasks in about 1 to 1.5 days.
The new app is optimized for low memory profile. It requires a bit less than half the RAM of a "naive" port of the BRP4 source, but as there is no free lunch, it is also a bit slower. With only 256 MB (or max 512 MB depending on HW and setup of the graphics mem), I think it's more important to have a low memory footprint. I have one running on my Raspbmc media center Raspi, so far w/o any problem.
Cheers
HB
What's gone from it? Did it
)
What's gone from it? Did it use some kind of LUT that could be disabled?
RE: What's gone from it?
)
The new version just does the FFTs in-place, some other computations are done in-place and some memory is recycled from previous steps. Unfortunately this slows down the code, but as I said...no free lunch ;-)
Cheers
HB
Bernd has now enabled the
)
Bernd has now enabled the validator on Albert that is taking care of the "Raspberry-Pi"-sized BRP4 workunits. All seems well. So the Albert@Home test run for the Raspberry Pis is now fully functional, end-to-end.
Cheers
HB
Do we have to wait until the
)
Do we have to wait until the final version of the Android Boinc Manager from Berkeley is ready to crunch the BRP`s on Mobile Phones?
Or will NativeBoinc support the app?
Milky way and a few other Projects have now over 900thousand valid credits with this software
http://nativeboinc.org/site/host_stats
it can be downloaded in the play store too.For those who wanna test it watch at
http://nativeboinc.org/site/uncat/start
Hi! We are still
)
Hi!
We are still experimenting with the port of the app to Android. We suffered a bit of a delay when one of the team (me :-( ) got sick for ca. two weeks, but now I'm back and we will resume work on the app. Please bear with us.
Cheers
HB
That´s nice to hear and i
)
That´s nice to hear and i hope you´re feeling well again.
I can´t help you with that unfortunately because i´ve no knowledge of that but what i know is that programming is not a simple thing and for sure it can take a lot of time depending on what you are trying to do.
So i wish you the best with that and hopefully it works in the next time because there are so many Phones and Tablets out there in the world and their Performance grows up and up.
I like that idea of Mobile crunching that would give all the Distributed Computing Networks new or rather more possibilitys and on user side more credit for very low energy costs.