Posted 9 Jan 2015 by
Michael Goetz
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!
Posted 9 Jan 2015 by
Michael Goetz
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.)
Posted 3 Jan 2015 by
Michael Goetz
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.
Posted 3 Jan 2015 by
Michael Goetz
Iam using
<rsc_fpops_est>8e10</rsc_fpops_est>but its never accurate. Tell me about a fix so I can give you the code.
We set rsc_fpops_est dynamically based on the size of the candidate and the FFT size. It uses the same mechanism that's used to calculate the credits.
In ops you can define Exact fraction done? but I dont know if its ever working.
Not in ops. I don't think they ever modified the web page for it. You have to use SQL to set a field in the app table. Look at the columns in the app table -- it will be obvious which column it is. Set the value to 1.
None of that, however, is the problem. In the PrimeGrid wrapper, the wrapper creates a pipe from LLR's stdout, and reads that pipe. Whenever it sees the percentage string, it uses that number to send to the BOINC API to report percentage complete. For some reason, that's not working in the wrapper here. Something was changed. Unless this is fixed, none of the rest matters.
Posted 3 Jan 2015 by
Michael Goetz
It's not that it's inaccurate -- it's actually not working at all.
The app (in this case, the wrapper) is supposed to call a BOINC API periodically to tell the BOINC client what the current completion percentage is. It appears that this is not happening -- there's a bug in the wrapper somewhere.
You see the percentage appear to climb upwards, but that's only because when the app doesn't call the API, recent BOINC clients "guess" about the completion percentage and show you what it aught to be based on the elapsed time and how long BOINC expects the task to run. It's totally bogus. With an older BOINC client, the percentage would just stay at 0.00 the entire time.
I suspect the wrapper isn't calling the API because it's not seeing the % string coming out of LLR. You changed what goes into stderr, and that probably affected the detection of the % complete.
It should be an easy fix.
(I'm talking about the Windows wrapper. It's possible the behavior under Linux/Mac is different.)
Hope this helps!
Mike
Posted 1 Jan 2015 by
Michael Goetz
Prime Grid has a nice sieving app. Do you think they would
give you a copy of it?
Our sieving apps are open source and freely available to anyone who wants to use them. Actually, all of our apps are open source.
There's a lot of 'glue', however, that needs to be built to manage the sieve data on the server. That's the hard part.