Hum, thanks for that info! It was very important to me. Maybe I will need to use a bespoke ODE solver to avoid using DiffEq packages which are indeed very big.
I have since noticed that there is a package GitHub - SciML/OrdinaryDiffEq.jl: High performance differential equation solvers for ordinary differential equations, including neural ordinary differential equations (neural ODEs) and scientific machine learning (SciML), which is āa component package in the DifferentialEquations ecosystem. It holds the ordinary differential equation solvers and utilitiesā, and ācan be used independently of DifferentialEquations.jlā. @ChrisRackauckas can probably comment on whether using it will reduce the precompilation memory usage.
Yup thatās the way to do it. Indeed, when you think of DifferentiaEquations.jl on ODEs, itās actually just calling into OrdinaryDiffEq. If you donāt need events you can even use SimpleDiffEq.jl.
2 Likes
This is amazing! Precisely what I needed. The solver inside do not need events. Do you plan to support simple algorithms like a fixed-step RK4 inside this package? (If so, I can submit a PR to add this)
Yeah, a SimpleRK4 would be good to have here.
2 Likes
Pi Zero is probably a bit low on the RAM for a stock Julia build.
If you can build a custom system image - removing all the things that are not necessary. Perhaps even PackageCompile your entire application into a minimal system image.
I think 1.4.1 would be much better than 1.0.x.
-viral
2 Likes
Thanks for the suggestion! I think there will be no problem to build a custom system image with PackageCompiler removing all the unnecessary packages from stdlib. However, now that you mention, I think 512MB of RAM will really not be enough to build Julia and/or build the sysimg. AFAIK, there is no way to ācross-compileā the sysimg right?
I might be completely off base here but reading the 512MB constraint just thought Iād mention that people (including myself) have successfully deployed Julia apps on Herokuās free tier, which has only 512MB RAM - as an example Matt Baumanās Covid dashboard here
3 Likes
I think it depends on exactly which packages you use and how much RAM each needs for precompilation. I got hung up specifically on DifferentialEquations (hadnāt finished in something like an hour when I gave up) but other stuff worked fine. Donāt remember if I tried Plots. But in any case my experiment was at least 6 months ago and I didnāt know to use a smaller version of the DiffEq packages.
Can anyone who has a SBC with 512 MB of RAM and already has Julia installed, please, add SatelliteToolbox.jl and see if it can pre-compile?
P.S.: If I install Raspberry in a VM with 512 MB of RAM, will I have a representative setup to test?
I also can use PackageCompiler to create an executable, but I want to avoid that. My goal is to have the very same code I use in the simulator
Itās is some sense the same (and some not), but even if not, Iām confused why you couldnāt use that same compiled code in the simulator? If however, it runs on say x86 in the simulator, then that would be a much bigger difference. Generated ARM code should be equivalent (not exact same timings), and if not, a compiler/julia bug, and those canāt be ruled out.
Note, when I say compiler/julia bug, that also applies without PackageCompiler.jl, as Julia is always compiled, just not with a separate compile step. For greater difference and speed you could use -O3 (while my understanding is thereās not much difference to the default -O2 in later Julia releases). Using higher levels, 2 or 3, makes a lot more sense with PackageCompiler, while without -O1 makes a lot of sense (for faster compile/startup of code), and at least on non-embedded.
1 Like
You mean Julia compiled code by PackageCompiler? AFAIK, a system image created by PackageCompiler depends on the architecture. Thus, I think I cannot build a system image in x86 and use it in ARM.
It is not looking good on the Pi Zero. It has been pre-compiling for 12 minutes and has gone into swap.
I will give it a couple of more minutes before killing the process. 
2 Likes
Thank you very much!!
Did you check how much the CPU is throttling with a passive heatsing? It will continue working even if it heats up, just with somewhat diminished performance. I get this on the 4B with a nontrivial (but not nearly full) load after a minute or two with the passive heatsink.
I realize that the current topic is converging to using one of the earlier/less beefy models, but after having tried it I am wondering what niche the 4B fills. The 3B(+) is a decent mini-computer, while being fanless and totally silent. The Zero feels like magic for $5, you can do wonderful things with it. But when you start thinking about cooling and airflow and all that, you might as well just get a PC, possibly with passive cooling.
1 Like
Just FYI, on the topic of RPI4 temps: I have mine using the PoE Hat which comes with a built-in fan. Even under load it doesnāt go much above 72-73C. I got it to spike to 78C with a cpuburn stress test.
1 Like
Hum, does the Pi 3 is that much better in terms of throttling ? Given the specs, it is more than enough for my application. I mean, without considering the precompilation / Julia build.
I dug my 3B+ out of the cabinet and just launched @time using SimpleDiffEq.
Finished in 341 seconds. Will try OrdinaryDiffEq next.
EDIT: add OrdinaryDiffEq failed with an error about building VectorizationBase, failure to precompile CpuId, so canāt time that right now.
This is with Julia v1.2.0 (what happened to be on my Raspberry Pi from when I last played with it).
I might try to update the Julia installation and see if I can get past that error but it may be a day or two before I get to it.
1 Like
I think I can use SimpleDiffEq and just pick some required functions in SatelliteToolbox. Perhaps, I will need to finally start splitting SatelliteToolbox into smaller packages.
Thanks for the help!