5 ms·

Julia looked interesting to me, so I tried 1.0 after it came out. I have a oldish laptop (fine for my needs), and every time I tried to do seemingly anything, i

Julia looked interesting to me, so I tried 1.0 after it came out. I have a oldish laptop (fine for my needs), and every time I tried to do seemingly anything, it spent ~5 minutes recompiling libraries or something. So I've been waiting newer versions that hopefully stop doing that, or for me to buy a better computer.

SolarNet 7y ago
This is a core part of the design. It's part of why Julia is so useful for scientific computing, where one often has a large job that will require a lot of processing time, such that it is worth it to do an intensive JIT cycle every-time. And part of that is the analysis to take python-esque code and turning it into C levels of performance.
- aurelian15 7y ago
  I just looked into Julia (1.1) for scientific use (simulation of very simple dynamical systems) a few days ago. I have to admit that by the end of the day I was surprisingly frustrated. I felt that type annotations were insufficient (one of the reasons to move away from Python); in particular, I didn't find a way to specify statically sized array types as you can do with Eigen, a feature that I find incredibly useful to find mistakes at compile time. Furthermore, just plotting something (using Gadfly) took about 30 seconds the first time after Julia was started and about 20 seconds every consecutive call (on a high-end workstation, mind you). The next day I just ended up using C++/Eigen with a simple matplotlib binding [1]. The code is nearly indistinguishable from Python/Julia (except for having more verbose types where it makes sense, using "auto" otherwise), and the entire compile+run cycle takes less time for some short runs than it takes Julia to print "Hello World". That being said, I'm not advocating for people to use C++. I would love to use Julia, and applaud the developers for their hard work and contribution to scientific computing, but as it stands right now, it doesn't seem to be the right tool for me, since I'm relying on fast editing/execution cycles. [1] https://github.com/lava/matplotlib-cpp https://github.com/lava/matplotlib-cpp
  - adamnemecek 7y ago
    > I didn't find a way to specify the exact size of arrays in the type as you can do with Eigen https://github.com/JuliaArrays/StaticArrays.jl https://github.com/JuliaArrays/StaticArrays.jl
  - improbable22 7y ago
    The default Array does not have a size as part of its type. There's a package StaticArrays which does this, typically faster below about 100 elements. But this isn't useful for catching mistakes before you run it, obviously. Plotting is indeed slower than ideal, have not used Gadfly but Plots is more like 15s after restarting, then 10ms each time after. GR is faster, 5s or so the first.
  - zmk_ 7y ago
    About Gadfly. If you were plotting it in a notebook then the default is to make it an interactive figure. In that case a lot of overhead comes from the browser trying to render it. You can explicitly invoke e.g., draw(SVG(10cm,10cm), plot(...)) to make it much faster.
  - orbifold 7y ago
    Julia is what happens if you let amateurs develop a compiler. The few times I’ve tried it produced gigabytes worth of stuff super slowly. The majority of packages are half backed, the only way to discover any type error is to let the program run, which coupled with multi method dispatch and hellishly slow compile times for trivial amounts of code makes the whole experience super unpleasant. Modern C++ plus some python feels more pleasant to work with (lightning fast compiles).
    - pjmlp 7y ago
      In case you missed, LLVM and GCC enjoy lots of contributions from amateurs. Maybe they should stop accepting them then.
      - dmix 7y ago
        Amateurs developing a compiler != amateurs contributing to a compiler. Every popular project has clear project leads who guide most important decision making. Not that I have any position on Julia
- fundamental 7y ago
  Sure, though it does seem like there's still work to be done on the side of decreasing package load time since parsing/compiling/etc does not necessarily need to be done the second/third/etc time you load the same package. It's gotten better with past releases, though it still seems to have a ways to go.
- ddragon 7y ago
  While the aggressive JIT it's a core part of the current approach, it's still an implementation detail and not a property of the language design itself, and other compilation strategies are being developed, such as interpretation/less aggressive JIT for when you only want to run something simple a few times (like JuliaInterpreter.jl and the --compile=min flag), better sharing precompiled code between sessions (like PackageCompiler.jl and the variants) and possibly even AoT with reduced functionality (which will be useful for writing Julia libs for other languages and stuff like WASM).
  - caiocaiocaio 7y ago
    Yeah, a dev mode would be nice.
anonova 7y ago
Yes, this is ones of my problems with Julia. It seems to be optimized for long runs and REPL/notebook usage. Take, for example, a simple program that creates a line plot (https://docs.juliaplots.org/latest/tutorial/ https://docs.juliaplots.org/latest/tutorial/): using Plots x = 1:10 y = rand(10) plot(x, y) After installing the package, the first run has to precompile(?), and subsequent runs use the package cache. But ~25 s to create a simple plot is incredibly slow and frustrating to work with. $ julia --version julia version 1.1.1 $ time julia plot.jl julia plot.jl 73.71s user 4.45s system 110% cpu 1:11.04 total $ time julia plot.jl julia plot.jl 24.41s user 0.39s system 100% cpu 24.633 total $ time julia plot.jl julia plot.jl 23.38s user 0.36s system 100% cpu 23.519 total
- improbable22 7y ago
  While this probably isn't a practical way to do any real work, running it with --compile=min gives some idea what might be possible soon: $ julia --compile=min -e '@time (using GR; plot(rand(20)))' 0.375836 seconds (368.83 k allocations: 20.190 MiB, 1.65% gc time) $ julia --compile=min -e '@time (using Plots; plot(rand(20)))' 4.302867 seconds (6.41 M allocations: 371.485 MiB, 5.07% gc time)
- ViralBShah 7y ago
  The time to second plot will be a few milliseconds, in the same process - in the same Julia session. So, while the time to first plot is frustrating, it is ok if your interactive session times are longer. Of course, we continue to work on improving compile times. About half of the time is spent in LLVM compilation, which has actually become slower over time.
  - tomrod 7y ago
    What prevents the plot compilation from being pre-compiled at install?
- jebej 7y ago
  The Plots package adds a significant overhead right now. Try using PyPlot (matplotlib) directly. These days you can use exactly the same syntax (dot-call) as in Python. $ time julia -e "using PyPlot;x=1:10;y=rand(10);plot(x,y);" real 0m5.676s
mlevental 7y ago
my bigger problem is how unstable all of the apis are. every single time i try to follow a guide/tutorial i get compilation errors because packages have shifted.
- eigenspace 7y ago
  Now that 1.0 is out, APIs have stabilized a ton, even in the package ecosystem. But depending n your stability needs, packages might still be changing too fast. I’d say for most people, there’s so much great progress and improvements happening that the breakages are well worth it.
  - locoman88 7y ago
    ... there’s so much great progress and improvements happening that the breakages are well worth it. This. According to the fanboys, Julia, and its ecosystem, is production ready, but the reality is that it's far from it. They rushed to release v1.0 when there were still lots of sharp corners to cut and polish. What the Julia community needs to do now is: 1. Admit that the language is not ready yet and that there are lots of room for improvement, and 2. Stop badmouthing Pyhton and R

SolarNet 7y ago

This is a core part of the design. It's part of why Julia is so useful for scientific computing, where one often has a large job that will require a lot of processing time, such that it is worth it to do an intensive JIT cycle every-time. And part of that is the analysis to take python-esque code and turning it into C levels of performance.

aurelian15 7y ago
I just looked into Julia (1.1) for scientific use (simulation of very simple dynamical systems) a few days ago. I have to admit that by the end of the day I was surprisingly frustrated. I felt that type annotations were insufficient (one of the reasons to move away from Python); in particular, I didn't find a way to specify statically sized array types as you can do with Eigen, a feature that I find incredibly useful to find mistakes at compile time. Furthermore, just plotting something (using Gadfly) took about 30 seconds the first time after Julia was started and about 20 seconds every consecutive call (on a high-end workstation, mind you). The next day I just ended up using C++/Eigen with a simple matplotlib binding [1]. The code is nearly indistinguishable from Python/Julia (except for having more verbose types where it makes sense, using "auto" otherwise), and the entire compile+run cycle takes less time for some short runs than it takes Julia to print "Hello World". That being said, I'm not advocating for people to use C++. I would love to use Julia, and applaud the developers for their hard work and contribution to scientific computing, but as it stands right now, it doesn't seem to be the right tool for me, since I'm relying on fast editing/execution cycles. [1] https://github.com/lava/matplotlib-cpp https://github.com/lava/matplotlib-cpp
- adamnemecek 7y ago
  > I didn't find a way to specify the exact size of arrays in the type as you can do with Eigen https://github.com/JuliaArrays/StaticArrays.jl https://github.com/JuliaArrays/StaticArrays.jl
- improbable22 7y ago
  The default Array does not have a size as part of its type. There's a package StaticArrays which does this, typically faster below about 100 elements. But this isn't useful for catching mistakes before you run it, obviously. Plotting is indeed slower than ideal, have not used Gadfly but Plots is more like 15s after restarting, then 10ms each time after. GR is faster, 5s or so the first.
- zmk_ 7y ago
  About Gadfly. If you were plotting it in a notebook then the default is to make it an interactive figure. In that case a lot of overhead comes from the browser trying to render it. You can explicitly invoke e.g., draw(SVG(10cm,10cm), plot(...)) to make it much faster.
- orbifold 7y ago
  Julia is what happens if you let amateurs develop a compiler. The few times I’ve tried it produced gigabytes worth of stuff super slowly. The majority of packages are half backed, the only way to discover any type error is to let the program run, which coupled with multi method dispatch and hellishly slow compile times for trivial amounts of code makes the whole experience super unpleasant. Modern C++ plus some python feels more pleasant to work with (lightning fast compiles).
  - pjmlp 7y ago
    In case you missed, LLVM and GCC enjoy lots of contributions from amateurs. Maybe they should stop accepting them then.
    - dmix 7y ago
      Amateurs developing a compiler != amateurs contributing to a compiler. Every popular project has clear project leads who guide most important decision making. Not that I have any position on Julia
fundamental 7y ago
Sure, though it does seem like there's still work to be done on the side of decreasing package load time since parsing/compiling/etc does not necessarily need to be done the second/third/etc time you load the same package. It's gotten better with past releases, though it still seems to have a ways to go.
ddragon 7y ago
While the aggressive JIT it's a core part of the current approach, it's still an implementation detail and not a property of the language design itself, and other compilation strategies are being developed, such as interpretation/less aggressive JIT for when you only want to run something simple a few times (like JuliaInterpreter.jl and the --compile=min flag), better sharing precompiled code between sessions (like PackageCompiler.jl and the variants) and possibly even AoT with reduced functionality (which will be useful for writing Julia libs for other languages and stuff like WASM).
- caiocaiocaio 7y ago
  Yeah, a dev mode would be nice.

anonova 7y ago

Yes, this is ones of my problems with Julia. It seems to be optimized for long runs and REPL/notebook usage. Take, for example, a simple program that creates a line plot (https://docs.juliaplots.org/latest/tutorial/ https://docs.juliaplots.org/latest/tutorial/): using Plots x = 1:10 y = rand(10) plot(x, y) After installing the package, the first run has to precompile(?), and subsequent runs use the package cache. But ~25 s to create a simple plot is incredibly slow and frustrating to work with. $ julia --version julia version 1.1.1 $ time julia plot.jl julia plot.jl 73.71s user 4.45s system 110% cpu 1:11.04 total $ time julia plot.jl julia plot.jl 24.41s user 0.39s system 100% cpu 24.633 total $ time julia plot.jl julia plot.jl 23.38s user 0.36s system 100% cpu 23.519 total

improbable22 7y ago
While this probably isn't a practical way to do any real work, running it with --compile=min gives some idea what might be possible soon: $ julia --compile=min -e '@time (using GR; plot(rand(20)))' 0.375836 seconds (368.83 k allocations: 20.190 MiB, 1.65% gc time) $ julia --compile=min -e '@time (using Plots; plot(rand(20)))' 4.302867 seconds (6.41 M allocations: 371.485 MiB, 5.07% gc time)
ViralBShah 7y ago
The time to second plot will be a few milliseconds, in the same process - in the same Julia session. So, while the time to first plot is frustrating, it is ok if your interactive session times are longer. Of course, we continue to work on improving compile times. About half of the time is spent in LLVM compilation, which has actually become slower over time.
- tomrod 7y ago
  What prevents the plot compilation from being pre-compiled at install?
jebej 7y ago
The Plots package adds a significant overhead right now. Try using PyPlot (matplotlib) directly. These days you can use exactly the same syntax (dot-call) as in Python. $ time julia -e "using PyPlot;x=1:10;y=rand(10);plot(x,y);" real 0m5.676s

mlevental 7y ago

my bigger problem is how unstable all of the apis are. every single time i try to follow a guide/tutorial i get compilation errors because packages have shifted.

eigenspace 7y ago
Now that 1.0 is out, APIs have stabilized a ton, even in the package ecosystem. But depending n your stability needs, packages might still be changing too fast. I’d say for most people, there’s so much great progress and improvements happening that the breakages are well worth it.
- locoman88 7y ago
  ... there’s so much great progress and improvements happening that the breakages are well worth it. This. According to the fanboys, Julia, and its ecosystem, is production ready, but the reality is that it's far from it. They rushed to release v1.0 when there were still lots of sharp corners to cut and polish. What the Julia community needs to do now is: 1. Admit that the language is not ready yet and that there are lots of room for improvement, and 2. Stop badmouthing Pyhton and R