Which brings up the question whether it is worthwhile to support non-NEON Android devices at all.
I'd like to hear feedback on this question. Are there enough old or low-end Android devices with ARMv6 CPUs around ??? Would volunteers care to run tasks on them that take (say) between 2 and 3 CPU days to complete (so, say, 6 to 9 days of elapsed time if you crunch 8 hours per day (or most likely night :-) )???
If there is sufficient demand we will provide this support, if not, dropping ARMv6-android will reduce pending tasks for the others (less waiting for very slow devices). Thoughts?
Cheers
HB
P.S.: FWIW, the RaspberryPi also doesn't support NEON, but OTOH it makes up for it by (usually) running under Raspbian, a Debian Linux port that uses the so called Hard-float ABI ==> better floating point performance for the same hardware when compared to Android's "soft(fp)" ABI. So the Raspi BRP4U performance seems to be somewhere in between the Android ARMv6 (VFP) and ARMv7 (NEON) app version performance. And it's easier to have a Raspi running 24/7 connected to mains than a phone that will most likely only crunch while connected to a charger.
New SETI@Home app version
Added by: matszpk , 2013-04-29 21:45
This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP.
Could this help our app as well or is it already in use?
New SETI@Home app version
Added by: matszpk , 2013-04-29 21:45
This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP.
Could this help our app as well or is it already in use?
It's interesting to read, in the discussion on SETI@Home, that libFFTS is considerably faster than FFTW for ARM. So yes, this could be interesting. FFTW was our natural choice for the initial app version on ARM because we use it for all CPU versions so far. But that doesn't mean it has to be that way, e.g. the BRP4 GPU versions use different FFT libs, obviously, for CUDA and OpenCL. And all those versions validate against each other quite happily. OTOH the libFFTS seems to be quite new and maybe it needs to settle and mature a bit longer.
Good to have some ARMv6 testers here! Given the speed of the devices, it takes some time to get enough validated results (say, around 200) that you will want to see before being confident that cross validation with ARMv6 works. I have one of the few other ARMv6 Android devices on Albert and the run-time is roughly the same.
I´ve buyed me an S3 before yesterday but not for crunching it´s such a great fast Smartphone.
But everyone has to decide this by himself.
I wish you many fast mobile devices if the project is released to Einstein.
You all are doing good work.
I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings.
If I find the time to write API wrappers, I will later try the FFTS library which is now used on Android over at SETI@Home, but for now, the version sticks to the good old FFTW.
I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings.
Cheers
HB
Err no. First one completed in about the same time as the 1.01 versions (168,000 seconds). I know its a bit early to tell seeing as its only the 1st one, will keep an eye on the others as they complete. Link to task is here
yeah, I think you are right. Doesn't seem faster at all. Maybe I didn't turn off the FFT wisdom file when I tested this one....(including a wisdom file is another thing I'm working on and this WOULD speed up things indeed). So stay tuned.
This one is looking a lot faster. Normally they take 47 hours, currently they are looking around 31-32 hours. A substantial improvement.
It still hasn't quite finished the 1st one yet (its on 96% after 30 hours). I will provide links once it completes.
Excellent, thanks!
The obvious question is: will it be possible to improve the Android app versions in a similar way? That remains to be seen(I'll need to make a wrapper app first that produces and dumps the FFTW3 'wisdom' on an Android device. Stay tuned.
RE: Which brings up the
)
I found this today in the Hardkernel Forum:
1,000,000 BOINC credits on ARM devices
http://forum.odroid.com/viewtopic.php?f=7&t=43
And NativeBoinc News says
New SETI@Home app version
Added by: matszpk , 2013-04-29 21:45
This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP.
Could this help our app as well or is it already in use?
RE: New SETI@Home app
)
It's interesting to read, in the discussion on SETI@Home, that libFFTS is considerably faster than FFTW for ARM. So yes, this could be interesting. FFTW was our natural choice for the initial app version on ARM because we use it for all CPU versions so far. But that doesn't mean it has to be that way, e.g. the BRP4 GPU versions use different FFT libs, obviously, for CUDA and OpenCL. And all those versions validate against each other quite happily. OTOH the libFFTS seems to be quite new and maybe it needs to settle and mature a bit longer.
Thanks for the pointer
Cheers
HB
RE: First Valid result on
)
Congrats :-)
Good to have some ARMv6 testers here! Given the speed of the devices, it takes some time to get enough validated results (say, around 200) that you will want to see before being confident that cross validation with ARMv6 works. I have one of the few other ARMv6 Android devices on Albert and the run-time is roughly the same.
Cheers
HB
Ok thank you I´ve buyed me
)
Ok thank you
I´ve buyed me an S3 before yesterday but not for crunching it´s such a great fast Smartphone.
But everyone has to decide this by himself.
I wish you many fast mobile devices if the project is released to Einstein.
You all are doing good work.
Hi fellow Raspberry Pi fans
)
Hi fellow Raspberry Pi fans ;-)
I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings.
If I find the time to write API wrappers, I will later try the FFTS library which is now used on Android over at SETI@Home, but for now, the version sticks to the good old FFTW.
Cheers
HB
RE: Hi fellow Raspberry Pi
)
Err no. First one completed in about the same time as the 1.01 versions (168,000 seconds). I know its a bit early to tell seeing as its only the 1st one, will keep an eye on the others as they complete. Link to task is here
Hi! yeah, I think you are
)
Hi!
yeah, I think you are right. Doesn't seem faster at all. Maybe I didn't turn off the FFT wisdom file when I tested this one....(including a wisdom file is another thing I'm working on and this WOULD speed up things indeed). So stay tuned.
Thanks for testing
Cheers
HB
OK, next attempt .... I just
)
OK, next attempt .... I just released version 1.05 for Raspberry Pi . If all goes well this should be 20 - 25 % faster than the previous version.
Feel free to cancel task that are/will be running under version 1.04, this will help to get 1.05 results in soon.
Thanks for testing!!
Cheers
HB
RE: OK, next attempt .... I
)
This one is looking a lot faster. Normally they take 47 hours, currently they are looking around 31-32 hours. A substantial improvement.
It still hasn't quite finished the 1st one yet (its on 96% after 30 hours). I will provide links once it completes.
RE: This one is looking a
)
Excellent, thanks!
The obvious question is: will it be possible to improve the Android app versions in a similar way? That remains to be seen(I'll need to make a wrapper app first that produces and dumps the FFTW3 'wisdom' on an Android device. Stay tuned.
Cheers
HBE