4 ms·

> The unnecessarily-long-for-debugging compilation times certainly put me off. I think I do like the semantics of Julia better than Python, but the compilation

by ubj 4y ago

> The unnecessarily-long-for-debugging compilation times certainly put me off. I think I do like the semantics of Julia better than Python, but the compilation times is a deal-breaker for me. Perhaps I might make the switch once this gets fixed in the upcoming years :) I like Julia, but this is a point of frustration for me as well. Compilation time is fine for smaller scripts. But whenever I've tried using more powerful packages such as the SciML ones (DifferentialEquations.jl, DiffEqFlux.jl, Symbolics.jl), the precompilation time during the edit/debug cycle can be excruciating. It's a shame because the SciML packages are so amazing. I'm waiting until Julia's static compilation process improves and is standardized. On-the-fly compilation that disappears every time you close the REPL will never be fast enough to give users a good experience when working with highly complex code. EDIT: Just to be clear, I'm overall confident that things will improve. The folks at Julia have already made good progress in reducing precompilation times from where they used to be. Looking forward to seeing further advancements in the future.

DNF2 4y ago
I'm not experienced with the SciML ecosystem, but they have apparently put huge efforts into improving compilation lag, and this has been going on for quite some time: https://twitter.com/ChrisRackauckas/status/1561278092043325440 https://twitter.com/ChrisRackauckas/status/15612780920433254... Quote: "Coming very soon: a version of DifferentialEquations.jl that fully precompiles the solvers on Vector{Float64}, virtually eliminating the any #julialang #sciml JIT lag."
- crabbygrabby 4y ago
  It's still rough. They've been at it for yrs and it's a perpetual bed of sand... A lot of machines will fail to install it because it's so resource intense to install... Promising idea overall, maybe in three yrs or so it'll be worth using for something outside of research.
  - ChrisRackauckas 4y ago
    It's 0.1 seconds now and faster than one can type, as shown by the GIF. What is the speed where it's not rough?
- ubj 4y ago
  Nice, that Twitter announcement looks fantastic! Looking forward to trying out the new precompiled version. And agreed that the folks at SciML (and the rest of Julia) have put amazing efforts into reducing the compilation lag from where it used to be :) I'm optimistic that things will improve--it'll just take some time.
  - crabbygrabby 4y ago
    Theyve been at it for half a decade or so. Ignoring compilation times they shuffle the code around so frequently it's only real use imo is for the authors to publish papers and stay three steps ahead of any of it's users hoping for a stable tool after a few cycles give up. It's a shame but it's academia at its finest.
    - DNF2 4y ago
      This part of your criticism seems quite disingenuous. You're simultaneously criticizing them for not improving their code quickly enough, and for changing it too much.
      - crabbygrabby 4y ago
        I appreciate your view but seeing as how most Julia projects work this way I sometimes wonder if it's just a problem with the language itself. Not trying to be a troll with impossible expectations, but genuinely the code is unstable, and yes they have been working on it for a long time.
    - ChrisRackauckas 4y ago
      We started working on it at JuliaCon 2021, where it was at 22 seconds. See the issue that started the work: https://github.com/SciML/DifferentialEquations.jl/issues/786 https://github.com/SciML/DifferentialEquations.jl/issues/786. As you could see from the tweet, it's now at 0.1 seconds. That has been within one year. Also, if you take a look at a tutorial, say the tutorial video from 2018, https://youtu.be/KPEqYtEd-zY https://youtu.be/KPEqYtEd-zY, you'll see that the code is still exactly the same an unbroken over the half decade. So no, compile times have only been worked on for about a year and code from half a decade ago still runs just fine.
- jakobnissen 4y ago
  How does that even work? Even with full precompilation, the LLVM time should still be there, no? In my usual Julia workloads, LLVM time is a significant fraction of compile time, so full precompilation only takes 30-50% off latency.
  - DNF2 4y ago
    I thought you could strip out LLVM now? I don't really know, it's above my pay grade.
    - ChrisRackauckas 4y ago
      You can strip it out with a system image, and you don't even need more than the basic StaticArrays and Loop vectorization stuff in the image to get almost all of it
sundarurfriend 4y ago
> I like Julia, but this is a point of frustration for me as well. It's a point of frustration for most of the community, it's just something we're willing to put up with (and work around) for the other benefits of the language. If the tradeoff doesn't seem worth it to you, it's totally fine to wait it out until it's in a more acceptable place for you. There's a lot of focus on improvements surrounding this in the recent and upcoming versions, precisely because of this frustration, but it's still going to be a gradual process.

by ubj 4y ago

DNF2 4y ago

I'm not experienced with the SciML ecosystem, but they have apparently put huge efforts into improving compilation lag, and this has been going on for quite some time: https://twitter.com/ChrisRackauckas/status/1561278092043325440 https://twitter.com/ChrisRackauckas/status/15612780920433254... Quote: "Coming very soon: a version of DifferentialEquations.jl that fully precompiles the solvers on Vector{Float64}, virtually eliminating the any #julialang #sciml JIT lag."

crabbygrabby 4y ago
It's still rough. They've been at it for yrs and it's a perpetual bed of sand... A lot of machines will fail to install it because it's so resource intense to install... Promising idea overall, maybe in three yrs or so it'll be worth using for something outside of research.
- ChrisRackauckas 4y ago
  It's 0.1 seconds now and faster than one can type, as shown by the GIF. What is the speed where it's not rough?
ubj 4y ago
Nice, that Twitter announcement looks fantastic! Looking forward to trying out the new precompiled version. And agreed that the folks at SciML (and the rest of Julia) have put amazing efforts into reducing the compilation lag from where it used to be :) I'm optimistic that things will improve--it'll just take some time.
- crabbygrabby 4y ago
  Theyve been at it for half a decade or so. Ignoring compilation times they shuffle the code around so frequently it's only real use imo is for the authors to publish papers and stay three steps ahead of any of it's users hoping for a stable tool after a few cycles give up. It's a shame but it's academia at its finest.
  - DNF2 4y ago
    This part of your criticism seems quite disingenuous. You're simultaneously criticizing them for not improving their code quickly enough, and for changing it too much.
    - crabbygrabby 4y ago
      I appreciate your view but seeing as how most Julia projects work this way I sometimes wonder if it's just a problem with the language itself. Not trying to be a troll with impossible expectations, but genuinely the code is unstable, and yes they have been working on it for a long time.
  - ChrisRackauckas 4y ago
    We started working on it at JuliaCon 2021, where it was at 22 seconds. See the issue that started the work: https://github.com/SciML/DifferentialEquations.jl/issues/786 https://github.com/SciML/DifferentialEquations.jl/issues/786. As you could see from the tweet, it's now at 0.1 seconds. That has been within one year. Also, if you take a look at a tutorial, say the tutorial video from 2018, https://youtu.be/KPEqYtEd-zY https://youtu.be/KPEqYtEd-zY, you'll see that the code is still exactly the same an unbroken over the half decade. So no, compile times have only been worked on for about a year and code from half a decade ago still runs just fine.
jakobnissen 4y ago
How does that even work? Even with full precompilation, the LLVM time should still be there, no? In my usual Julia workloads, LLVM time is a significant fraction of compile time, so full precompilation only takes 30-50% off latency.
- DNF2 4y ago
  I thought you could strip out LLVM now? I don't really know, it's above my pay grade.
  - ChrisRackauckas 4y ago
    You can strip it out with a system image, and you don't even need more than the basic StaticArrays and Loop vectorization stuff in the image to get almost all of it

sundarurfriend 4y ago

> I like Julia, but this is a point of frustration for me as well. It's a point of frustration for most of the community, it's just something we're willing to put up with (and work around) for the other benefits of the language. If the tradeoff doesn't seem worth it to you, it's totally fine to wait it out until it's in a more acceptable place for you. There's a lot of focus on improvements surrounding this in the recent and upcoming versions, precisely because of this frustration, but it's still going to be a gradual process.