4 ms·

> Finally, it is also likely that CPUs will become faster over time and that tooling around reducing TTFX will improve. I don't agree with this as a mitigation

> Finally, it is also likely that CPUs will become faster over time and that tooling around reducing TTFX will improve. I don't agree with this as a mitigation. This line of reasoning is why despite steady hardware improvements over the past few decades, responsiveness of (PC) programs and websites have stagnated or regressed. To the main TTFX issue - I won't consider Julia until this is taken seriously.

celrod 4y ago
Many of us in the Julia community (myself included) take it very seriously and spend a substantial amount of our time working to mitigate it.
phonebucket 4y ago
The quote provided explicitly suggests that tooling around reducing TTFX should also improve. It’s not suggesting improved CPU power as the sole mitigation.
skohan 4y ago
I totally agree, leaning on Moore's Law to solve performance issue doesn't work. When you have performance issues on the language itself, you're essentially paying a performance tax on every piece of code that executes, in a compounding way. So if Julia became a widespread programming language for general applications, you have those small delays leaking into all sorts of operations, and before you know it your whole system feels slow and bogged down. I have been testing some performance oriented software recently, and it's amazing how much more productive I feel when every keypress is immediately reflected on screen with no delay. We can adapt to poor performance, but it adds a constant cognitive load to deal with it. In my mind Julia is suited for limited applications, like doing work in a jupyter notebook, but is not suited for general applications unless the TTFX issue can be fixed.
- jakobnissen 4y ago
  In my opinion, there is no such thing as a "general application". What about generating static websites? Is that a "general application"? Is TTFX a big issue there? Currently, the Julia package Franklin.jl takes around 15 seconds to create the website the first time (changes in the source code update the page in less than one second). I'd argue no. What about Julia to produce generative art? Is TTFX an issue there? Etc. If "general applications" means _all possible applications_, then I'm not sure any language is suitable for general applications. Julia has weaknesses which limits what it's good at. Right now I think it has more weaknesses than other languages. Some of these limits will hopefully be removed or reduced in the future. But fundamentally, I don't see Julia as some kind of domain specific or niche language. Just like any language, it just has its own set of tradeoffs.
  - skohan 4y ago
    Yeah I would agree the use cases you mentioned are probably fine for Julia as well. I could be more precise and say that Julia is not relevant for performance-relevant applications. The problem with ignoring performance is, many applications can become a dependency of a performance relevant application even if that was not the original intent.
    - cjalmeida 4y ago
      We recently used Julia to solve (correctly) a super complex scheduling problem for a major airline. Our budget was 5min, Python would get not even close to a solution in that time. The tool is being actively used in production. Julia is not not only fine, but my go to language for performance problems.
      - skohan 4y ago
        Ok but comparing with Python is like a worst-case scenario, and long running tasks would amortize Julia’s performance issues. There are a great many use-cases/language comparisons you could find where Julia would be the worse performing language.
      - deleted 4y ago
        [deleted]
    - DNF2 4y ago
      You seem to confuse performance and latency. High performance is Julia's main selling point. Latency is its Achilles heel. It's being very actively worked on however.
      - skohan 4y ago
        Latency is a type of performance. For instance if you have even a few milliseconds latency it's relevant in terms of UI performance.
        4y ago
MaxBarraclough 4y ago
It seems very similar to what's going on with Java these days. If your plan is to do bytecode verification and class-loading only once requests are coming in, and to handle the first however many requests with interpretive execution (prior to JIT), you shouldn't be surprised to see poor performance for those first requests. Now, ahead-of-time compilation in the JVM is becoming more mainstream, and brings the expected benefits to, for instance, start-up time. [0] [0] https://spring.io/blog/2021/12/09/new-aot-engine-brings-spring-native-to-the-next-level https://spring.io/blog/2021/12/09/new-aot-engine-brings-spri...
ChrisRackauckas 4y ago
The load times on some core packages were reduced by an order of magnitude this month. For example, RecursiveArrayTools went from 6228.5 ms to 292.7 ms. This was due to the new `@time_imports` in the Julia v1.8-beta helping to isolate load time issues. See https://github.com/SciML/RecursiveArrayTools.jl/pull/217 https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . And that's just one of many packages which have seen this change just this month. This of course doesn't mean load times have been solved everywhere, but we now have the tooling to identify the root causes and it's actively being worked on from multiple directions.
bee_rider 4y ago
That seems more like a little aside on the compilation times front, rather than the main thrust of the author's argument.

celrod 4y ago

Many of us in the Julia community (myself included) take it very seriously and spend a substantial amount of our time working to mitigate it.

phonebucket 4y ago

The quote provided explicitly suggests that tooling around reducing TTFX should also improve. It’s not suggesting improved CPU power as the sole mitigation.

skohan 4y ago

I totally agree, leaning on Moore's Law to solve performance issue doesn't work. When you have performance issues on the language itself, you're essentially paying a performance tax on every piece of code that executes, in a compounding way. So if Julia became a widespread programming language for general applications, you have those small delays leaking into all sorts of operations, and before you know it your whole system feels slow and bogged down. I have been testing some performance oriented software recently, and it's amazing how much more productive I feel when every keypress is immediately reflected on screen with no delay. We can adapt to poor performance, but it adds a constant cognitive load to deal with it. In my mind Julia is suited for limited applications, like doing work in a jupyter notebook, but is not suited for general applications unless the TTFX issue can be fixed.

jakobnissen 4y ago
In my opinion, there is no such thing as a "general application". What about generating static websites? Is that a "general application"? Is TTFX a big issue there? Currently, the Julia package Franklin.jl takes around 15 seconds to create the website the first time (changes in the source code update the page in less than one second). I'd argue no. What about Julia to produce generative art? Is TTFX an issue there? Etc. If "general applications" means _all possible applications_, then I'm not sure any language is suitable for general applications. Julia has weaknesses which limits what it's good at. Right now I think it has more weaknesses than other languages. Some of these limits will hopefully be removed or reduced in the future. But fundamentally, I don't see Julia as some kind of domain specific or niche language. Just like any language, it just has its own set of tradeoffs.
- skohan 4y ago
  Yeah I would agree the use cases you mentioned are probably fine for Julia as well. I could be more precise and say that Julia is not relevant for performance-relevant applications. The problem with ignoring performance is, many applications can become a dependency of a performance relevant application even if that was not the original intent.
  - cjalmeida 4y ago
    We recently used Julia to solve (correctly) a super complex scheduling problem for a major airline. Our budget was 5min, Python would get not even close to a solution in that time. The tool is being actively used in production. Julia is not not only fine, but my go to language for performance problems.
    - skohan 4y ago
      Ok but comparing with Python is like a worst-case scenario, and long running tasks would amortize Julia’s performance issues. There are a great many use-cases/language comparisons you could find where Julia would be the worse performing language.
    - deleted 4y ago
      [deleted]
  - DNF2 4y ago
    You seem to confuse performance and latency. High performance is Julia's main selling point. Latency is its Achilles heel. It's being very actively worked on however.
    - skohan 4y ago
      Latency is a type of performance. For instance if you have even a few milliseconds latency it's relevant in terms of UI performance.
      - 4y ago

MaxBarraclough 4y ago

It seems very similar to what's going on with Java these days. If your plan is to do bytecode verification and class-loading only once requests are coming in, and to handle the first however many requests with interpretive execution (prior to JIT), you shouldn't be surprised to see poor performance for those first requests. Now, ahead-of-time compilation in the JVM is becoming more mainstream, and brings the expected benefits to, for instance, start-up time. [0] [0] https://spring.io/blog/2021/12/09/new-aot-engine-brings-spring-native-to-the-next-level https://spring.io/blog/2021/12/09/new-aot-engine-brings-spri...

ChrisRackauckas 4y ago

The load times on some core packages were reduced by an order of magnitude this month. For example, RecursiveArrayTools went from 6228.5 ms to 292.7 ms. This was due to the new `@time_imports` in the Julia v1.8-beta helping to isolate load time issues. See https://github.com/SciML/RecursiveArrayTools.jl/pull/217 https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . And that's just one of many packages which have seen this change just this month. This of course doesn't mean load times have been solved everywhere, but we now have the tooling to identify the root causes and it's actively being worked on from multiple directions.

bee_rider 4y ago

That seems more like a little aside on the compilation times front, rather than the main thrust of the author's argument.