At the outset a lot of this I might be responsible for (I might be contributing to the problem). But I want to use it they way I want to use it; maybe my
expectations are out of line? On the other hand, there are some clear performance problems with Julia ARM in general, so at least in part, there will be
applicability beyond just me. This can also serve as a handoff from my previous quesiton. Also, these are all performance usability issues that one-time occur at the beginning, I'm seeing no issues during the middle of execution.
The project I'm trying to create is have a highly efficient numerics component to software that runs on a drone, so pretty specialized, but you could
imagine that the same application could be used in another way. More generally put a productized use of Julia in an embedded device.
Here are my problems
1) Using the embedded version of Julia (libjulia) within another program -- you know my (node-julia) thing -- leads to the Julia GC attempting to use
more memory than is available which leads to an exception "could not allocate pools" randomly at program startup, but if that doesn't
happen immediately, it never happens. Using Julia directly (REPL) version it never happens. This hardware does have less memory than all general
purpose equipment (laptops) -- 500 MB and no swap space (there really is no possibility for using swap). This seems like a typical requirement on
embedded devices. I feel that if there was an option to jl_init_with_image to set the maximum pool allocation size -- like to say 150 MB, that would solve the immediate problem.. I could do this, but it would be nice to have some direction. Or maybe I'm misreading the problem I have only the error
2) Just in time compilation. this might be particular to this device, or it might be a general problem of low-powered ARM-based systems, but compilation cost is enormous. To give you an idea, simply pressing the "up-arrow" key in the Julia REPL incurs a 10-second cost while the code for command history is compiled. It's snappy after that though. I did try using compile-all, but that crashed Julia. That was against an earlier version of Julia ARM
though and is perhaps fixed now. I wonder how long it would take to compile otherwise? There was a suggestion in one of the Julia issues about essentially a cross-compile-all feature that might be invented, which would allow me to deliver a packaged version of Julia containing mostly compiled-to-native library sys-all.so of Base/Core or something like that. Would there also be a package variant? Compile individual packages similarly?
3) Minor issue. Some of the libraries that Julia uses/provides are named weirdly and the specialized version is symbolically linked to the generic version (backwards from what is typically done).. This is ok when used by Julia internally but it confuses ld when linked into another program