5 ms·

> the time to generate the first plot goes from 11.7 seconds to 7.8 seconds This should not take more than 100 milliseconds in this day and age, folks.

by m0zg 6y ago

gajomi 6y ago
FYI this is the _first_ call which is dominated by the JIT process. So not really "this time to plot" so much as the "time to compile". Calls to the resulting jitted function will be on the order of what you quote (I have not timed myself for the specific result they quote here but have done for similar in the past).
- m0zg 6y ago
  I know. Be that as it may, 7 seconds to load a module alone is nuts.
  - Certhas 6y ago
    The module also gets partially precompiled on load. If you make the module part of the systemimage it's as quick as you would expect.
    - jkinudsjknds 6y ago
      Does that just move the load time to the initial start up of the REPL before calling 'using Plots'? If not I'm surprised I've never seen that advice before.
  - bananaquant 6y ago
    Ha. I remember the time when it took over a minute.
muska3 6y ago
Sadly, this is very true. Yeah Julia is fast, but not as fast as python and matlab in the REPL and quick analysis work. I can get going with data analysis and plotting far faster for exploratory work due to the zero precompilation overhead in those languages, where as in Julia this overhead is brutal. Julia people will probably down-vote this, but sadly, as an interactive language this is it's Achilles heel. I have to explain to people why the code is taking so long to show up due to JIT et al., and non-experts don't understand that this is just an initial overhead.
- smabie 6y ago
  I agree that it's annoying, but creating a image isn't very difficult and solves the problem nicely.
- pjmlp 6y ago
  When one doesn't have a JIT and every piece of code that requires performance has to be rewritten in C, it is easy to be "fast".
djaque 6y ago
This is the info I was looking for. Julia is such an awesome language, but I can't use it due to latency. As soon as this gets fixed I would switch over all of my data analysis in a heartbeat.
- eigenspace 6y ago
  I don't think this is a great reason to avoid julia. Why is latency a concern for you? Are you running a lot of short, one-off scripts? If so, an easy solution is to just keep a julia session running and re-use it for each each script rather than constantly starting up and closing julia sessions. DaemonMode.jl [1] is a package that was recently developed that makes this workflow effortless. Another option if you've got some production code that needs to be run over and over again is to create a custom sysimage with everything AOT compiler. PackageCompiler.jl [2] makes this workflow pretty easy nowadays. [1] https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl [2] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
moelf 6y ago
with PackageCompiler.jl, you can do this within 100 ms
- m0zg 6y ago
  Why is this not the default?
  - improbable22 6y ago
    This bakes in a particular version of the Plots library. Which is mostly great, but you need to re-bake to move on to a new version. (All the standard libraries are baked in by default, in much the same way I think, and so can't be updated without making a new version of Julia. But they all load fast.)
  - eigenspace 6y ago
    Because it involves making a julia sysimage with the Plots.jl functions AOT compiled into it. PackageCompiler.jl makes this quite easy and straightforward though, it takes like 5 minutes and you won't have to worry about plotting latency again until you upgrade Julia or Plots.jl. Here's the instructions: https://julialang.github.io/PackageCompiler.jl/dev/examples/plots/ https://julialang.github.io/PackageCompiler.jl/dev/examples/...
    - m0zg 6y ago
      Why doesn't it cache the results of a compilation automatically the first time you hit the module after any change? This shouldn't be difficult. Much of Julia's target audience don't know what "AOT" is.
      - eigenspace 6y ago
        > This shouldn't be difficult. It is actually exceedingly difficult due to multiple dispatch. There's an effectively infinite number of different method signatures a function can have. Currently, anything you want to AOT needs to go into a big monolithic sysimage with the full julia runtime. We might be able to eventually do a shared library approach that you can dynamically link to, but it'll take time. Doing this automatically without the user opting in would make latency problems worse, not better.
fermienrico 6y ago
Most people who advocate Julia have never built production ready systems.
- eigenspace 6y ago
  Most people who advocate anything have never built production ready systems because that's not a thing most people do. There are important and knowledgeable people in the Julia community who build production ready systems as their full time jobs though. What is your point?
  - fermienrico 6y ago
    I disagree. If a language is positioning itself as a python alternative, it needs to handle production readiness. If I were to guess, python is used in more production environments than in prototyping environments, but I don't have data to prove. What's most likely true is that production systems aren't a minuscule portion of a language's application - it is a significant chunk and Julia just isn't there yet. Hopeful though.
    - eigenspace 6y ago
      > If I were to guess, python is used in more production environments than in prototyping environments. Then you have a stunning misunderstanding of Python's demographics.
      - fermienrico 6y ago
        I’d be curious if you have data. Also, if we define execution of a Python line as a metric: Instagram alone will dwarf all prototypers in Python. What would be a good metric to indicate “popularity”? If it’s number of installs, then Python tinkerers would win and I agree with you.
        eigenspace 6y ago
        > I’d be curious if you have data. Sounds like a hard thing to measure, but I'm sure someone has good estimates. > Also, if we define execution of a Python line as a metric: Instagram alone will dwarf all prototypers in Python. What would be a good metric to indicate “popularity”? Code cycles isn't really what I would mean by language use, but if we go by that metric Julia's production code also dwarfs non-production code cycles. The Celeste project alone was running at petaflops[1] at it's peak, that is 10^15 floating point operations per second. One of the biggest targets for Julia is deploying it at scale on super-computing clusters. There are almost surely many more CPU cycles being devoted to production scale julia code than random repl code, but that's got to be true for almost any language being used at scale. Also, counting Python line executions in production code is a little squirreley, because almost surely those lines are really just a thin wrapper around a big hunk of C code if it's a production system. > If it’s number of installs, then Python tinkerers would win and I agree with you. I'd also say just number lines written or projects started, the tinkerers win hands down. [1] https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl...
tastyminerals 6y ago
What?! There are static languages that compile faster: Nim, D... Honestly, I used ggplotD library and it takes roughly two seconds to compile and miliseconds to show the plot.
zchristensen7 6y ago
To be fair, this metric represents the absolute worse case scenario for latency in Julia. Even before 1.5 you could technically get a first plot in less than 7.8 seconds using SimplePlots.jl. This also doesn't speak to the performance once you have your first plot. I've crashed my computer a good number of times using Matlab or R to interactively manipulate a complicated 3D structure. I was able to add some crazy stuff to my plots before this happened in Julia.

> the time to generate the first plot goes from 11.7 seconds to 7.8 seconds This should not take more than 100 milliseconds in this day and age, folks.

by m0zg 6y ago

> the time to generate the first plot goes from 11.7 seconds to 7.8 seconds This should not take more than 100 milliseconds in this day and age, folks.

gajomi 6y ago

FYI this is the _first_ call which is dominated by the JIT process. So not really "this time to plot" so much as the "time to compile". Calls to the resulting jitted function will be on the order of what you quote (I have not timed myself for the specific result they quote here but have done for similar in the past).

m0zg 6y ago
I know. Be that as it may, 7 seconds to load a module alone is nuts.
- Certhas 6y ago
  The module also gets partially precompiled on load. If you make the module part of the systemimage it's as quick as you would expect.
  - jkinudsjknds 6y ago
    Does that just move the load time to the initial start up of the REPL before calling 'using Plots'? If not I'm surprised I've never seen that advice before.
- bananaquant 6y ago
  Ha. I remember the time when it took over a minute.

muska3 6y ago

Sadly, this is very true. Yeah Julia is fast, but not as fast as python and matlab in the REPL and quick analysis work. I can get going with data analysis and plotting far faster for exploratory work due to the zero precompilation overhead in those languages, where as in Julia this overhead is brutal. Julia people will probably down-vote this, but sadly, as an interactive language this is it's Achilles heel. I have to explain to people why the code is taking so long to show up due to JIT et al., and non-experts don't understand that this is just an initial overhead.

smabie 6y ago
I agree that it's annoying, but creating a image isn't very difficult and solves the problem nicely.
pjmlp 6y ago
When one doesn't have a JIT and every piece of code that requires performance has to be rewritten in C, it is easy to be "fast".

djaque 6y ago

This is the info I was looking for. Julia is such an awesome language, but I can't use it due to latency. As soon as this gets fixed I would switch over all of my data analysis in a heartbeat.

eigenspace 6y ago
I don't think this is a great reason to avoid julia. Why is latency a concern for you? Are you running a lot of short, one-off scripts? If so, an easy solution is to just keep a julia session running and re-use it for each each script rather than constantly starting up and closing julia sessions. DaemonMode.jl [1] is a package that was recently developed that makes this workflow effortless. Another option if you've got some production code that needs to be run over and over again is to create a custom sysimage with everything AOT compiler. PackageCompiler.jl [2] makes this workflow pretty easy nowadays. [1] https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl [2] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl

moelf 6y ago

with PackageCompiler.jl, you can do this within 100 ms

m0zg 6y ago
Why is this not the default?
- improbable22 6y ago
  This bakes in a particular version of the Plots library. Which is mostly great, but you need to re-bake to move on to a new version. (All the standard libraries are baked in by default, in much the same way I think, and so can't be updated without making a new version of Julia. But they all load fast.)
- eigenspace 6y ago
  Because it involves making a julia sysimage with the Plots.jl functions AOT compiled into it. PackageCompiler.jl makes this quite easy and straightforward though, it takes like 5 minutes and you won't have to worry about plotting latency again until you upgrade Julia or Plots.jl. Here's the instructions: https://julialang.github.io/PackageCompiler.jl/dev/examples/plots/ https://julialang.github.io/PackageCompiler.jl/dev/examples/...
  - m0zg 6y ago
    Why doesn't it cache the results of a compilation automatically the first time you hit the module after any change? This shouldn't be difficult. Much of Julia's target audience don't know what "AOT" is.
    - eigenspace 6y ago
      > This shouldn't be difficult. It is actually exceedingly difficult due to multiple dispatch. There's an effectively infinite number of different method signatures a function can have. Currently, anything you want to AOT needs to go into a big monolithic sysimage with the full julia runtime. We might be able to eventually do a shared library approach that you can dynamically link to, but it'll take time. Doing this automatically without the user opting in would make latency problems worse, not better.

fermienrico 6y ago

Most people who advocate Julia have never built production ready systems.

eigenspace 6y ago
Most people who advocate anything have never built production ready systems because that's not a thing most people do. There are important and knowledgeable people in the Julia community who build production ready systems as their full time jobs though. What is your point?
- fermienrico 6y ago
  I disagree. If a language is positioning itself as a python alternative, it needs to handle production readiness. If I were to guess, python is used in more production environments than in prototyping environments, but I don't have data to prove. What's most likely true is that production systems aren't a minuscule portion of a language's application - it is a significant chunk and Julia just isn't there yet. Hopeful though.
  - eigenspace 6y ago
    > If I were to guess, python is used in more production environments than in prototyping environments. Then you have a stunning misunderstanding of Python's demographics.
    - fermienrico 6y ago
      I’d be curious if you have data. Also, if we define execution of a Python line as a metric: Instagram alone will dwarf all prototypers in Python. What would be a good metric to indicate “popularity”? If it’s number of installs, then Python tinkerers would win and I agree with you.
      - eigenspace 6y ago
        > I’d be curious if you have data. Sounds like a hard thing to measure, but I'm sure someone has good estimates. > Also, if we define execution of a Python line as a metric: Instagram alone will dwarf all prototypers in Python. What would be a good metric to indicate “popularity”? Code cycles isn't really what I would mean by language use, but if we go by that metric Julia's production code also dwarfs non-production code cycles. The Celeste project alone was running at petaflops[1] at it's peak, that is 10^15 floating point operations per second. One of the biggest targets for Julia is deploying it at scale on super-computing clusters. There are almost surely many more CPU cycles being devoted to production scale julia code than random repl code, but that's got to be true for almost any language being used at scale. Also, counting Python line executions in production code is a little squirreley, because almost surely those lines are really just a thin wrapper around a big hunk of C code if it's a production system. > If it’s number of installs, then Python tinkerers would win and I agree with you. I'd also say just number lines written or projects started, the tinkerers win hands down. [1] https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl...

tastyminerals 6y ago

What?! There are static languages that compile faster: Nim, D... Honestly, I used ggplotD library and it takes roughly two seconds to compile and miliseconds to show the plot.

zchristensen7 6y ago

To be fair, this metric represents the absolute worse case scenario for latency in Julia. Even before 1.5 you could technically get a first plot in less than 7.8 seconds using SimplePlots.jl. This also doesn't speak to the performance once you have your first plot. I've crashed my computer a good number of times using Matlab or R to interactively manipulate a complicated 3D structure. I was able to add some crazy stuff to my plots before this happened in Julia.