4 ms·

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 som

• 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.
      • crabbygrabby 4y ago
        I think you misunderstood me, all good. The diffeq/sciml landscape has been a WIP for half a decade with lots of pieces of it changing rapidly and regularly. But so has the rest of the ecosystem. I think we both know how often this code has changed, but for some reason the Julia people are always like "oh we have packages for that" or "oh that's rock solid" and then you check the package it's a flag plant and does nothing or is broken from a minor version change, then you try to use it, maybe even fix it, and it breaks Julia base... I'm not going to waste anymore time with digging into this to file an issue or prove a point. I think passerbys should be made aware of the state of things in the language without spin from people making a living selling it. No personal offence to you, just please consider not overselling, it's damaging to people who jump in expecting a good experience.
• 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