Groups 162 of 99+ julia-users › test planning: Julia on PINE64 ... ? 10 posts by 4 authors cdm 12/13/15 anyone in line for one of these ARM boards http://pine64.com/ with plans to test Julia on a Ubuntu version of the SBC ... ? certainly looks interesting ... Tamas Papp 12/13/15 Assuming that the comparative advantage of Julia is in scientific programming, do people really run these on such very low-powered hardware? I am not questioning this, just curious what the use cases are. A colleague built a Blackberry Pi 2 "desktop" last year to try it out and it was barely coping with basic things. Best, Tamas - show quoted text - cdm 12/13/15 while this SBC would represent a substantial improvement over the Pi systems currently in market, i suspect that the most notable aspect is the price ... generally, as the price points come down, clusters become much more feasible ... parallelism is next. Tamas Papp 12/13/15 AFAIK typical SBC CPUs are not heavily optimized for floating point; there is an order of magnitude difference compated to an x86. I don't understand how a cluster would make economic sense, even for tasks that parellelize well (and then there is the network overhead). Best, Tamas On Sun, Dec 13 2015, cdm wrote: - show quoted text - cdm 12/13/15 probably less about what is typical today and more about what is next ... ARM is engineering processors for what is next: https://en.wikipedia.org/w/index.php?title=ARM_big.LITTLE&redirect=no newer ARM processors are designed with parallelism explicitly targeted and floating point issues resolved: https://en.wikipedia.org/wiki/ARM_Cortex-A53 https://en.wikipedia.org/wiki/Superscalar_processor https://en.wikipedia.org/wiki/ARM_architecture#VFP http://www.arm.com/products/processors/instruction-set-architectures/index.php http://projectne10.github.io/Ne10/ people are building ARM clusters: http://www.nextplatform.com/2015/02/27/prototype-arm-clusters-muscle-hpc/ http://www.nextplatform.com/2015/06/16/mont-blanc-sets-the-stage-for-arm-hpc/ http://www.montblanc-project.eu/arm-based-platforms people are running Julia on ARM systems and Julia has parallelism as a focus, so there will be a natural nexus. Scott Jones 12/14/15 On Sunday, December 13, 2015 at 4:13:11 AM UTC-5, Tamas Papp wrote: Assuming that the comparative advantage of Julia is in scientific programming, do people really run these on such very low-powered hardware? Well, I'd dispute that assumption. Although there are a number of things that can be improved in Julia to make it a *better* general-purpose language, and some holes like decent debugging support filled, it *already* is better than most languages in a number of ways. If it can be pared down to essentials, it will be a great language for programming things like the Pi, even with the current ARM chips. The idea that Julia should *only* be focused on scientific computing is rather aggravating to those of us using it for general purpose programming. At least the press release for the Moore Foundation's grant said: "The Julia Language project’s mission is to create a free and open-source language that is general purpose but designed to excel at numerical computing and data science." (Emphasis is my own). Tamas Papp 12/15/15 On Mon, Dec 14 2015, Scott Jones wrote: > On Sunday, December 13, 2015 at 4:13:11 AM UTC-5, Tamas Papp wrote: >> >> Assuming that the comparative advantage of Julia is in scientific >> programming, do people really run these on such very low-powered >> hardware? >> > > Well, I'd dispute that assumption. Although there are a number of things > that can be improved in Julia to make it a *better* general-purpose > language, and some holes like decent debugging support filled, it *already* > is better than most languages in a number of ways. > If it can be pared down to essentials, it will be a great language for > programming things like the Pi, even with the current ARM chips. > > The idea that Julia should *only* be focused on scientific computing is > rather aggravating to those of us using it for general purpose programming. > At least the press release for the Moore Foundation's grant said: > "The Julia Language project’s mission is to create > a free and open-source language that is *general purpose* but designed to > excel at numerical computing and data science." > (Emphasis is my own). Apologies if I caused you aggravation, that was not my intention. I did not mean to frame the question as "why Julia on architecture ", but as "why for running Julia". Best, Tamas Scott Jones 12/15/15 On Tuesday, December 15, 2015 at 3:56:44 AM UTC-5, Tamas Papp wrote: Apologies if I caused you aggravation, that was not my intention. No apologies necessary, the aggravation was not from you, but from the *idea* of Julia *only* being a technical/scientific language, and that being used as a justification for not worrying about things that are important for general programming. Julia is already a great language, not just for technical/scientific projects, and is getting better daily. I did not mean to frame the question as "why Julia on architecture ", but as "why for running Julia". In this particular case, I'd love to see (a pared down) Julia running on things like the Raspberry Pi or Lego Mindstorms, so that my kids (or I) don't have to learn another language to program them. As far as my kids, I'd much rather have them learning to program with Julia rather than Java or C/C++, or even Python or JavaScript. (I do like Lua though, they learned some Lua with the ComputerCraft mod in MineCraft over a year ago) Best to you too! Scott Tamas Papp 12/15/15 On Tue, Dec 15 2015, Scott Jones wrote: > I did not mean to frame the question as "why Julia on architecture ", >> but as "why for running Julia". > > > In this particular case, I'd love to see (a pared down) Julia running on > things like the Raspberry Pi or Lego Mindstorms, > so that my kids (or I) don't have to learn another language to program them. AFAIK Julia is available in Raspbian. May not be the most recent version though, but 3.2 looks like it is there: http://archive.raspbian.org/raspbian/pool/main/j/julia/ Best, Tamas Páll Haraldsson 12/16/15 On Sunday, December 13, 2015 at 9:51:31 AM UTC, Tamas Papp wrote: AFAIK typical SBC CPUs are not heavily optimized for floating point; there is an order of magnitude difference compared to an x86. I don't understand how a cluster would make economic sense, even for tasks that parellelize well (and then there is the network overhead). I'm sure you are right about ARM's floating point not being as good as x86, especially for ARMv6, but is this changing for ARMv7 and the 64/32-bit ARMv8-A? Even Intel in their latest Xeon Phi uses Atom cores (same, or possibly modified, haven't read too closely yet) as in smartphones, just more of them AND yes lots of cache. That of course helps with floating-point/HPC, and in general the better memory hierarchy. That is however both helpful for FPU and integer, and ARM isn't slow anymore for integer at least. I just saw the other day that on some benchmark (I forget which, not sure if it uses FPU) from 3 months ago, that the A9[X] in the iPhone 6s/iPad slightly beats a MacBook from this year at 1.2 GHz, with non-Atom ("mobile"), Core M CPU ("laptop", would you not call that "mobile"-kind?). Anyway, for the argument, let's say the FPU is slow[er]. You also have GPUs commonly (are you ignoring those?), and I see latest Adreno in Qualcomm has unified "[virtual] memory" with the CPU (not sure why they put in virtual). GPGPU is good with at least some of the GPUs (Adreno says latest is 40% faster), such as Nvidia's. Sadly Mali400-MP2 or at least Utgard the microarch it's based on, in the PINE64, is listed with "Graphics", not "Graphics & Compute" on the table: https://en.wikipedia.org/wiki/Mali_(GPU) And it doesn't have fused-multiply-add (while some do) and "Some Malis support cache coherency for the L2 cache with the CPU" Commonly GPUs use single-precision (double not really in consumer, any maybe not at all in mobile?), but it might do - with tricks, or not.. [About clusters: Look into Unum (Universal number) that will replace traditional floating point, not only for speed/energy (while then needing? better hardware), but also more correct answers.. AND turn "embarrassingly serial" code into data parallel ("the easiest kind").. I may write a post here, in a separate thread, we shouldn't high-jack this one. Maybe add my thought to the Flexnum one?] >AFAIK Julia is available in Raspbian. May not be the most recent version though, but 3.2 looks like it is there: >http://archive.raspbian.org/raspbian/pool/main/j/julia/ Doesn't this need to be fixed? 0.4.x even more important on those slower computers? OR is the overhead of compiling going up? Is there a fast compile/less optimization/"almost interpreted".. needed/already available? Or useful, as counter-productive at runtime..? Could there be a way to optimize different functions differently? Already done, say with inlined (leaf) functions optimized more? (And others for code space density and fast compilation). P.S. Was Blackberry Pi 2 just a typo or did I miss something? Best, Tamas On Sun, Dec 13 2015, cdm wrote: > while this SBC would represent a substantial improvement > over the Pi systems currently in market, i suspect that the > most notable aspect is the price ... > > generally, as the price points come down, clusters become > much more feasible ... > > parallelism is next.