2 ms·

> A long wait for Julia 2.0, particularly if standalone executable compilation would be addressed, can not possibly help the adoption of Julia from my perspecti

> A long wait for Julia 2.0, particularly if standalone executable compilation would be addressed, can not possibly help the adoption of Julia from my perspective. It's the opposite. Julia 2.0 would not bring standalone executable compilation, but instead would require compiler work for language changes. The whole point of saying "we don't need to do a 2.0 right now" is that folks on the compiler team believe working on things like standalone compilation and improved caching of LLVM code (i.e. fixing TTFP) are a better use of time than changes to language semantics (i.e. a 2.0).

waffletower 4y ago
If PackageManager changes can be addressed in 1.10, 1.11+ etc., I would be elated. Again, TTFP does not need to 'addressed' -- the acronym instead needs to be eliminated from usage -- a shift to use of 'startup-time' can help a change of mindset to open the Julia community up to a broader range of applications and adopters. Otherwise, Julia simply continues to feed its currently narrow niche of applications.
- ChrisRackauckas 4y ago
  I think by PackageManager here you mean package compiler, and yes these improvements do not need a 2.0. v1.8 included a few things to in the near future allow for building binaries without big dependencies like LLVM, and finishing this work is indeed slated for the v1.x releases. Saying "we are not doing a 2.0" is precisely saying that this is more important than things which change the user-facing language semantics. And TTFP does need to be addressed. It's a current shortcoming of the compiler that native and LLVM code is not cached during the precompilation stages. If such code is able to precompile into binaries, then startup time would be dramatically decreased because then a lot of package code would no longer have to JIT compile. Tim Holy and Valentin Churavy gave a nice talk at JuliaCon 2022 about the current progress of making this work: https://www.youtube.com/watch?v=GnsONc9DYg0 https://www.youtube.com/watch?v=GnsONc9DYg0 . This is all tied up with startup time and are all in some sense the same issue. Currently, the only way to get LLVM code cached, and thus startup time essentially eliminated, is to build it into what's called the "system image". That system image is the binary that package compiler builds (https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl). Julia then ships with a default system image that includes the standard library in order to remove the major chunk of code that "most" libraries share, which is why all of Julia Base works without JIT lag. However, that means everyone wants to have their thing, be it sparse matrices to statistics, in the standard library so that it gets the JIT-lag free build by default. This means the system image is huge, which is why PackageCompiler, which is simply a system for building binaries by appending package code to the system image, builds big binaries. What needs to happen is for packages to be able to precompile in a way that then caches LLVM and native code. Then there's no major compile time advantage to being in the system image, which will allow things to be pulled out of the system image to have a leaner Julia Base build without major drawbacks, which would then help make the system compile. That will then make it so that an LLVM and BLAS build does not have to be in every binary (which is what takes up most of the space and RAM), which would then allow Julia to much more comfortably move beyond the niche of scientific computing.
  - waffletower 4y ago
    'startup-time' vs. 'TTFP' are just semantics, but a crucial distinction. The focus on 'time-to-first-plot' is entrenched in the dominant workflow of the Julia community. If you want a broader range of adoption, the word choice matters. Having experienced a very similar dialogue in the Clojure community over startup time, and seen the new range of applications emerge as the issue was effectively addressed, I was startled by the very narrow and focussed acronym (TTFP) in the Julia community. I am happy that there is progress on the code caching front and will look to the link you shared. Thanks for elucidating this further!
    - borodi 4y ago
      The group working on it, (Valentin, Tim Holy etc) agree with you, which is why we are tending to call it TTFX(time to first X) instead of TTFP, so it includes everything, not just plotting. It's just that when plotting the delay is very visible.

waffletower 4y ago

If PackageManager changes can be addressed in 1.10, 1.11+ etc., I would be elated. Again, TTFP does not need to 'addressed' -- the acronym instead needs to be eliminated from usage -- a shift to use of 'startup-time' can help a change of mindset to open the Julia community up to a broader range of applications and adopters. Otherwise, Julia simply continues to feed its currently narrow niche of applications.

ChrisRackauckas 4y ago
I think by PackageManager here you mean package compiler, and yes these improvements do not need a 2.0. v1.8 included a few things to in the near future allow for building binaries without big dependencies like LLVM, and finishing this work is indeed slated for the v1.x releases. Saying "we are not doing a 2.0" is precisely saying that this is more important than things which change the user-facing language semantics. And TTFP does need to be addressed. It's a current shortcoming of the compiler that native and LLVM code is not cached during the precompilation stages. If such code is able to precompile into binaries, then startup time would be dramatically decreased because then a lot of package code would no longer have to JIT compile. Tim Holy and Valentin Churavy gave a nice talk at JuliaCon 2022 about the current progress of making this work: https://www.youtube.com/watch?v=GnsONc9DYg0 https://www.youtube.com/watch?v=GnsONc9DYg0 . This is all tied up with startup time and are all in some sense the same issue. Currently, the only way to get LLVM code cached, and thus startup time essentially eliminated, is to build it into what's called the "system image". That system image is the binary that package compiler builds (https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl). Julia then ships with a default system image that includes the standard library in order to remove the major chunk of code that "most" libraries share, which is why all of Julia Base works without JIT lag. However, that means everyone wants to have their thing, be it sparse matrices to statistics, in the standard library so that it gets the JIT-lag free build by default. This means the system image is huge, which is why PackageCompiler, which is simply a system for building binaries by appending package code to the system image, builds big binaries. What needs to happen is for packages to be able to precompile in a way that then caches LLVM and native code. Then there's no major compile time advantage to being in the system image, which will allow things to be pulled out of the system image to have a leaner Julia Base build without major drawbacks, which would then help make the system compile. That will then make it so that an LLVM and BLAS build does not have to be in every binary (which is what takes up most of the space and RAM), which would then allow Julia to much more comfortably move beyond the niche of scientific computing.
- waffletower 4y ago
  'startup-time' vs. 'TTFP' are just semantics, but a crucial distinction. The focus on 'time-to-first-plot' is entrenched in the dominant workflow of the Julia community. If you want a broader range of adoption, the word choice matters. Having experienced a very similar dialogue in the Clojure community over startup time, and seen the new range of applications emerge as the issue was effectively addressed, I was startled by the very narrow and focussed acronym (TTFP) in the Julia community. I am happy that there is progress on the code caching front and will look to the link you shared. Thanks for elucidating this further!
  - borodi 4y ago
    The group working on it, (Valentin, Tim Holy etc) agree with you, which is why we are tending to call it TTFX(time to first X) instead of TTFP, so it includes everything, not just plotting. It's just that when plotting the delay is very visible.