A dummy question from a rainy sunday morning…
I use Julia for two different kinds of work:
- Heavy Computations (as a replacement for C++/Fortran…)
- Light Computations (as a replacement for Python/Matlab…)
That is great to have a single expressive language to do both ! My “mental load” is much lower
I must confess that, coming from C++, I am already very satisfied with the Julia language and the compiler state (perf and speed). I wait serenely PARTR to be released and I already wrote that the ability to produce Julia dynamic libraries would be great to incorporate in C++ applications.
Long start-up times for light computing (e.g. casual plotting) are not too problematic for my usual workflow, but I see that it is an annoying problem for a lot of Julians.
If I understand correctly, the path taken to reduce this start-up time (compile time?) is to compile faster or to cache more compiled parts. I naïvely wonder why it is not possible to go the other way and have a fully interpreted mode with no compilation at all (Python?) for light computations (plots). Or an automatic compilation starting when a repetitive computation happens to be long enough for the compilation being amortized (Java?).
@jeff.bezanson discusses something along those lines above
Thank you, I did not knew about
I wonder if it is the end of the story… (
julia --compile=no ?)
I made the following experiment consider the following script.jl
@time using Plots
julia-1.0.2/bin/julia script.jl returns:
2.846402 seconds (7.18 M allocations: 394.265 MiB, 4.75% gc time)
0.081629 seconds (326.78 k allocations: 16.775 MiB, 8.42% gc time)
11.445984 seconds (45.55 M allocations: 2.205 GiB, 8.51% gc time)
julia-1.0.2/bin/julia --compile=min script.jl returns:
1.979290 seconds (4.19 M allocations: 241.822 MiB, 3.82% gc time)
0.005710 seconds (4.74 k allocations: 297.531 KiB)
0.556606 seconds (1.06 M allocations: 45.601 MiB, 2.51% gc time)
Which is indeed much faster !
But when I try to execute the previous script line by line in the REPL
the last line
@time plot(a,sin.(a)) makes julia crash…
I hadn’t heard of it either – and couldn’t find it in the docs; if indeed it isn’t there, it may be just because of this instability. I tried it on two of my test suites, and it segfaulted on both. (Worked on very simple code; not sure if it has to do with importing wrapped C libraries? That was a commonality, at least.)
But, yeah, having this sort of thing be more of a core feature (perhaps also using this with the compiler running in the background, or the like, as discussed elsewhere) would be wonderful.
Tried it on a third large-ish test suite – another segfault.
If you get segfaults with this please file an issue. We do intend for it to at least work. It’s not documented right now because it can be, say, 500x slower than normal Julia, so if you hit a serious computation you’ll get stuck. We do eventually plan to switch to the compiler automatically in these cases, as you say, at which point the lower latency will hopefully become the default.
I also get the same error. Also when I try to execute
from the cmd window, it displays an error
Microsoft Windows [Version 10.0.17134.286]
(c) 2018 Microsoft Corporation. All rights reserved.
Greetings! ! !ERROR: could not open file C:\Users\chatura\script.jl
 include at .\boot.jl:317 [inlined]
 include_relative(::Module, ::String) at .\loading.jl:1044
 include(::Module, ::String) at .\sysimg.jl:29
 exec_options(::Base.JLOptions) at .\client.jl:231
 _start() at .\client.jl:425
Greetings! ! ! _
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.0.2 (2018-11-08)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
The script.jl is there in the folder “C:\Users\chatura\script.jl” with the three commands.
That sounds wonderful!
As for the segfault, I opened an issue here: https://github.com/JuliaLang/julia/issues/30504