3 ms·
Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Also, for serious numerical work, startup time is eclipsed by run
by leephillips 6y ago
Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Also, for serious numerical work, startup time is eclipsed by run time, so it tends not to be relevant. I did most of my physics simulations in Fortran, which is a great language for the task, but if I were writing a new simulation code today I would use Julia. It is the only language in the petaflop club that is actually better to program in than Fortran. (+1 for gnuplot.)
- enriquto 6y ago> Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Yes, I tried it upon its release and, while much faster, the startup time is still dramatically sub-par, especially when loading packages. This means that when I call Julia scripts from makefiles, etc., a considerable amount of running time is spent in re-compiling over and over the same packages. I agree that my usage pattern is not at all representative, but still it seems that Julia is not a good "unix citizen", since it tries to force you to do everything inside its own REPL, instead of the native one. This is indeed my main point of friction with Julia. If it started instantaneously it would be essentially perfect. This is not a matter of dividing the startup time by 2, but at least by 200.
- leephillips 6y agoI understand. I haven’t tried this myself, but others have had luck, for this use case, in using sysimages: https://julialang.github.io/PackageCompiler.jl/dev/sysimages/ https://julialang.github.io/PackageCompiler.jl/dev/sysimages...
- enriquto 6y agoThanks! I was told about this on a previous HN thread, but I have still to try it. Will do as soon as I have some time. It looks really promising.
- TheRealKing 6y agoCan you elaborate on why it "is actually better to program in than Fortran"?
- leephillips 6y agoThe type system and dispatch paradigm provide a powerful method of code and project organization, and facilitate a type of code reuse that you don’t get with Fortran: the ability to pull other people packages into my project and use their types and methods. That’s one thing. EDIT: Also, having a REPL, and a nice one, is a big deal.
- enriquto 6y agoCan you expand a bit on the need for "types" in numerical computation? They sort of seem like overkill to me. The only types I use are float and double, but I could really do with just doubles. OK, admittedly I also need complex numbers (two floats) and ad numbers (however they are represented, typically by two floats also). But that's it. They are numbers after all, associative and commutative. The "dispatch paradigm" that these types require seems really simple, as it is implemented by e.g. generics in C as in tgmath.h. I'm wholly unconvinced--or more honestly, wholly ignorant--of the interest of a really complicated and powerful type system with multiple dispatch, broadcasting and whatnot that is offered by Julia. Fortran really seems enough for me. [And I do not care at all for the REPL, but that is a separate issue.]
- leephillips 6y agoI think I have a pretty good answer to your question in this article: https://lwn.net/Articles/834571/ https://lwn.net/Articles/834571/ It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply the differential equation solver that you just wrote to quaternion-valued functions with no extra work.