rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7480
Credit: 43,876,295
RAC: 43,732
This is a shame, because I keep my laptop loaded with BU tasks, normally, but have 2 or 3 ARM devices that are crunching for other projects, but I would love to donate more power to this project, but can't for now - once the project gets famous and grows, could there be an ARM app - it would get 1000s and 1000s more devices involved...
But if you need 1 month for a WU this is not good.
/ 
Reply
Quote
This is a shame, because I keep my laptop loaded with BU tasks, normally, but have 2 or 3 ARM devices that are crunching for other projects, but I would love to donate more power to this project, but can't for now - once the project gets famous and grows, could there be an ARM app - it would get 1000s and 1000s more devices involved...
OMFG!
could you please consider that this projects needs IEEE 754 compatible FLOATING-POINT hardware and there is no ARM design available providing this?
software emulation could be coded (if anyone would be crazy enough) but you'd have a penalty in speed of at least 2 magnitudes.
so can we please have a note on the main page, that this is not going to happen?
/ Reply
Quote
This is a shame, because I keep my laptop loaded with BU tasks, normally, but have 2 or 3 ARM devices that are crunching for other projects, but I would love to donate more power to this project, but can't for now - once the project gets famous and grows, could there be an ARM app - it would get 1000s and 1000s more devices involved...
Conceptually, a computer is a computer is a computer, so why can't ARM do this? It's a valid question -- and there's a really, really good answer.
Super TL;DR answer: Theoretically, ARM could do it, but it's a stupid idea. Ain't gunna happen.
Normal TL;DR version: You'll probably never see this kind of app running on ARM processors. At least not unless the focus of those ARM CPUs changes radically and they start producing CPUs specifically targeted for the desktop market.
Full answer:
It's got nothing to do with nobody wanting to write the app. The ARM CPUs lack the necessary features to run these calculations efficiently.
It's not just, as other people have correctly said, the lack of IEEE floating point hardware. While that's a bare minimum (which ARM lacks) to be able to run these calculations at all, running them efficiently requires what's called SIMD instructions (Single-Instruction, Multiple-Data). On x86 CPUs, this is the SSE3, AVX, and FMA3 instruction sets that provide the turbo-charging that lets LLR run so fast. Run LLR on an older x86 CPU lacking those SIMD instructions and LLR is 10 to 40 times slower. If you were to create a version of LLR for ARM, it would need software emulation for the floating point routines, and would likely be an additional 100 times slower than those old desktop CPUs.
No amount of software engineering is going to compensate for the lack of necessary hardware in the CPU.
Could it be done? In theory, yes. But I'm probably underestimating how slow it would be if I said it would be over 1000 times slower than what a modern x86 CPU can do. Given how slow it would be, there's no incentive for anyone to put in the time to build such an app.
There's lots of things ARM processors are good at. It makes no sense to have them doing a task they're terrible at when there's more productive uses for them.
/ Reply
Quote
well, i did not want to give them a five figures penalty on this, but you are right, it would end up somewhere around that.
not even thinking of PI's...
the next one showing up with this suggenstion might earn one of my spare slide rulers. ;)
/ Reply
Quote
aww - that's a shame - I will crunch on here as much as I can, and I am (indirectly) donating money through http://www.bitcoinutopia.net/bitcoinutopia.
____________
Thanks, from Chris.
/ Reply
Quote
The LLR application uses "gwnum code". This code is written for INTEL processors. Therefore you cannot compile the LLR application for ARM based OS's ..... until there is "gwnum code" available for ARM processors.
this will hardly ever happen simpy because afaik there is no arm-design that is IEEE 754 compatible.
there are commercial libraries for newer arm-design which support this, but since they need to emulate on that limited arm hardware....
"gwnum code" is *NOT* written for Intel CPUs but for CPUs using the x86 and x86-64 archtecture, so AMD CPUs and VIA CPUs can be used ass well.
And as Arthur C. Clarke once said: "Any sufficiently advanced technology is indistinguishable from magic". The mere fact that NOW there is no arm-design that is IEEE 754 compatible says nothing about the future. We are just waiting for a programmer to eable it, one way or another.
/ Reply
Quote
The LLR application uses "gwnum code". This code is written for INTEL processors. Therefore you cannot compile the LLR application for ARM based OS's ..... until there is "gwnum code" available for ARM processors.
this will hardly ever happen simpy because afaik there is no arm-design that is IEEE 754 compatible.
there are commercial libraries for newer arm-design which support this, but since they need to emulate on that limited arm hardware....
"gwnum code" is *NOT* written for Intel CPUs but for CPUs using the x86 and x86-64 archtecture, so AMD CPUs and VIA CPUs can be used ass well.
And as Arthur C. Clarke once said: "Any sufficiently advanced technology is indistinguishable from magic". The mere fact that NOW there is no arm-design that is IEEE 754 compatible says nothing about the future. We are just waiting for a programmer to eable it, one way or another.
I don't know who the "we" is in your your last sentence, but it doesn't include anyone who understands how LLR works, CPU architectures, and vector processing. Anyone who thinks that some sufficiently motivated programmer is going to come up with an "LLR app for ARM" is badly misinformed and sadly mistaken.
Please read (or re-read) my earlier post in this thread. What is necessary is a change in the ARM hardware. No programmer is going to be able to make any current ARM CPU run this kind of calculation efficiently.
(If anyone feels like going down the "what's wrong with an inefficient app, if there's tons of ARM processors out there?" road, it's so inefficient it would mean that task deadlines that are currently one day would have to become one year, and no project is going to do that. And, no, these tasks can't be split up into smaller pieces.)
/ Reply
Quote
maybe it's time for a post in FAQ abot this.
/ Reply
Quote
Did I anywhere said "current ARM CPU" in my message?
____________
/ Reply
Quote
Did I anywhere said "current ARM CPU" in my message?
of course you can keep on trying to earn an *****-badge, but this is boring.
/ Reply
Quote
Did I anywhere said "current ARM CPU" in my message?
Fair enough. If you read what I wrote, I specifically said I was talking about existing CPUs and left open the theoretical possibility (of course) that ARM could design a CPU with the kind of desktop abilities that are necessary for efficiently doing these calculations. This would almost certainly be a desktop CPU and not a low power mobile CPU, but it would still be an "ARM processor."
I take it, from the statement you made, that you are aware of such plans. Would you be so kind as to provide a link to a credible source with information about plans to produce future ARM processors with vector (SIMD) IEEE double precision floating point hardware? Thank you!
/ Reply
Quote
Fair enough: http://www.arm.com/products/processors/technologies/vector-floating-point.php
/ Reply
Quote
Fair enough: http://www.arm.com/products/processors/technologies/vector-floating-point.php
Thanks.
VFP10 is a step in the right direction. When that's available, serious discussion about ARM versions of this software will be reasonable. It will still be slower (and a lot slower), but not nearly as bad as the current differential of several orders of magnitude.
Until then, we wait patiently.
/ Reply
Quote
VFP10 is a step in the right direction. When that's available, serious discussion about ARM versions of this software will be reasonable. It will still be slower (and a lot slower), but not nearly as bad as the current differential of several orders of magnitude.
Until then, we wait patiently.
if anyone is going to buy that design and goes into mass-production.
does anyone need a gadget capable of running vector math?
/ Reply
Quote
VFP10 is a step in the right direction. When that's available, serious discussion about ARM versions of this software will be reasonable. It will still be slower (and a lot slower), but not nearly as bad as the current differential of several orders of magnitude.
Until then, we wait patiently.
if anyone is going to buy that design and goes into mass-production.
does anyone need a gadget capable of running vector math?
We do. :)
/ Reply
Quote
DeleteNull
Volunteer developer
Volunteer tester
Send message
Joined: 29 Nov 14
Posts: 83
Credit: 374,931,522
RAC: 4,200
Volunteer developer
Volunteer tester
Send message
Joined: 29 Nov 14
Posts: 83
Credit: 374,931,522
RAC: 4,200
RaspberryPi has this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html (section 1.5.9)
/ Reply
Quote
RaspberryPi has this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html (section 1.5.9)
And the RaspberryPi just has to do with a ARMv6 CPU. BananaPi and others based upon the Allwinner A20 SOC do it with an ARMv7, which is more powerful.
/ Reply
Quote
RaspberryPi has this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html (section 1.5.9)
And the RaspberryPi just has to do with a ARMv6 CPU. BananaPi and others based upon the Allwinner A20 SOC do it with an ARMv7, which is more powerful.
In the meantime the Raspberry Pi 2 has come out, using an ARM Cortex-A7 with ARMv7 architecture/instruction set and that has been followed by the Raspberry Pi 3, using an ARM Cortex-A53 with ARMv8 architecture/instruction set. Biggest problem for the Raspberry as a crunching platform is the small amount of RAM: 1 GB.
/ Reply
Quote