5 ms·

Jumping the gun slightly, but TTFX likely about to get a lot better (5x+ improvement in times) in the next version (1.9). Via cachine of the native compiled cod

Jumping the gun slightly, but TTFX likely about to get a lot better (5x+ improvement in times) in the next version (1.9). Via cachine of the native compiled code. https://github.com/JuliaLang/julia/pull/47184#issuecomment-1337079281 https://github.com/JuliaLang/julia/pull/47184#issuecomment-1...

CyberDildonics 4y ago
I've been hearing about improvements for the last 8 years. It has been a constant complaint and a constant broken promise.
- adgjlsfhk1 4y ago
  Since 1.0 it has gotten way better. There's still work to do (obviously) but there has been continual improvement.
  - galangalalgol 4y ago
    My concern for TTFX is the case when X is something infrequent but sensitive to latency? This a ridiculous example but when it is time for the anti-collision feature on my car to kick in, I want it to run, not compile. I think the right answer is to run a bunch of tests to get all the paths compiled and then build a new system image. But I haven't found a ton of guidance on how to do that. Seems like a perfect pipeline task.
    - leephillips 4y ago
      That’s the idea. Here’s an example: https://discourse.julialang.org/t/a-julia-dataanalysis-sysimage-from-packagecompiler-its-so-easy-you-should-do-it-too/68127 https://discourse.julialang.org/t/a-julia-dataanalysis-sysim...
  - lambdatronics 4y ago
    I think Jevon's paradox is also hitting to some extent, coupled with the ecosystem getting bigger, so a typical project may have more transitive dependencies behind it. The functionality is going up, and the speed of compilation is going up, but the total latency is staying similar or increasing, in my experience.
    - adgjlsfhk1 4y ago
      that's definitely possible. I'm somewhat hopeful that some changes in 1.9 will let us cut back on transitive dependencies a lot, but it will take a few months to know for sure.
- thetwentyone 4y ago
  I'm not sure that there's been any "promises" to break. Folks have been saying that it's possible but it'll just take time and effort.
- patrick451 4y ago
  Indeed, every couple of years I try julia again, and every time it's still slow as molasses, all the while being told it's massively improved. One of the most annoying aspects of slow TTFX is when X is your language server. It takes like 10 minutes or something ridiculous for completions to start working after opening a moderately complex file. I had the same experience in vscode and emacs. For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update. [1] http://danluu.com/julialang/ http://danluu.com/julialang/
  - shele 4y ago
    Would it not be better at this point to move on?
  - markkitti 4y ago
    We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it. What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change. On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow" On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations. I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments. Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts. [1] https://github.com/JuliaLang/julia/pull/47184 https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527 https://github.com/JuliaLang/julia/pull/44527

CyberDildonics 4y ago

I've been hearing about improvements for the last 8 years. It has been a constant complaint and a constant broken promise.

adgjlsfhk1 4y ago
Since 1.0 it has gotten way better. There's still work to do (obviously) but there has been continual improvement.
- galangalalgol 4y ago
  My concern for TTFX is the case when X is something infrequent but sensitive to latency? This a ridiculous example but when it is time for the anti-collision feature on my car to kick in, I want it to run, not compile. I think the right answer is to run a bunch of tests to get all the paths compiled and then build a new system image. But I haven't found a ton of guidance on how to do that. Seems like a perfect pipeline task.
  - leephillips 4y ago
    That’s the idea. Here’s an example: https://discourse.julialang.org/t/a-julia-dataanalysis-sysimage-from-packagecompiler-its-so-easy-you-should-do-it-too/68127 https://discourse.julialang.org/t/a-julia-dataanalysis-sysim...
- lambdatronics 4y ago
  I think Jevon's paradox is also hitting to some extent, coupled with the ecosystem getting bigger, so a typical project may have more transitive dependencies behind it. The functionality is going up, and the speed of compilation is going up, but the total latency is staying similar or increasing, in my experience.
  - adgjlsfhk1 4y ago
    that's definitely possible. I'm somewhat hopeful that some changes in 1.9 will let us cut back on transitive dependencies a lot, but it will take a few months to know for sure.
thetwentyone 4y ago
I'm not sure that there's been any "promises" to break. Folks have been saying that it's possible but it'll just take time and effort.
patrick451 4y ago
Indeed, every couple of years I try julia again, and every time it's still slow as molasses, all the while being told it's massively improved. One of the most annoying aspects of slow TTFX is when X is your language server. It takes like 10 minutes or something ridiculous for completions to start working after opening a moderately complex file. I had the same experience in vscode and emacs. For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update. [1] http://danluu.com/julialang/ http://danluu.com/julialang/
- shele 4y ago
  Would it not be better at this point to move on?
- markkitti 4y ago
  We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it. What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change. On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow" On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations. I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments. Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts. [1] https://github.com/JuliaLang/julia/pull/47184 https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527 https://github.com/JuliaLang/julia/pull/44527