5 ms·

> the time to first plot is unlikely to ever go below a hundred milliseconds How is that controversial or disappointing!? Why would anyone bother optimizing th

> the time to first plot is unlikely to ever go below a hundred milliseconds How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster. `python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window. To be clear, I do believe there is much more work to be done to decrease latency in Julia, but your targets are ridiculous. And as a regular on their bugtracker and forum, the devs definitely acknowledge these issues and have many times said it is one of their main priorities. By the way, if you want streaming live updated plots, this latency to first frame is not a problem. It is already straightforward to make such fast live plots in Julia (although it does not fit my personal taste for how to do it).

enriquto 5y ago
> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00
- krastanov 5y ago
  Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file. Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.
  - enriquto 5y ago
    Sure! That's why I set a somewhat reasonable target at being just 5x or 10x times slower than a specific-purpose plotting tool. But even that is considered to be chimerical! (or, in your words, "ridiculous")
    - krastanov 5y ago
      Now you are just putting words in my mouth. I would completely agree that 10x latency to first plot is a reasonable target (i.e. first plot in about a second, like you get in python and much faster than what you get in matlab/mathematica). And plenty of devs closer to core of Julia and the plotting libraries in it would agree. And to be clear, I do expect my second plot to be ready in tens of milliseconds.
  - reikonomusha 5y ago
    Why is it such a ridiculous comparison? Gnuplot is still interpreting a language, loading plotting code, etc. If Julia folks wanted to, they could bundle pre-compiled plotting code that loads as fast as memory moves bytes. They don’t want to, of course, likely because it’s inelegant, but they could, and a general-purpose language doesn’t stop them from doing that.
    - krastanov 5y ago
      You can already bundle pre-compiled plotting code in your Julia sys-image if you want. But Julia is not a plotting tool so it would be ridiculous to optimize it just for plotting. I want ODE solvers to have less latency, should I start expecting gnuplot to have built-in ODE solvers or the official installer of Julia to have the ODE libraries pre-compiled? Maybe this example would make it clearer: why does your argument not apply to Python? Should we expect python libraries to come pre-cached so that the first time I load `sympy` I do not need to wait for tens of seconds to have .pyc files created. Or about matlab? Again, I am all on board with the idea that julia needs lower latency and if you look at what their devs say, they also agree with that. But expecting Julia to be super low-latency (lower-latency than python/c/matlab) for your pet task is silly.
      - reikonomusha 5y ago
        I gave a proof-of-concept argument as to why something doesn’t need to take as long straight out of the box with no customization. Python is doing it sub-1s. You can also include a non-optimizing interpreter. My point is that being a general purpose language doesn’t inherently limit you in any way; instead it’s one’s choice of implementation strategy. Another strategy: when a user installs Julia, they select “fast-loading” libraries. You’d be surprise how small changes in UI/UX make huge perceived differences in quality and performance. I bet “Julia can already do this” too, but nobody does it because it’s not idiomatic and it’s not recommended up front. At the end of the day, people don’t complain about Python or MATLAB as much because they feel nicer. If it feels nicer because of some other reason than absolute time, then they’re doing something about UX that Julia is not, because everybody really does feel Julia is extremely sluggish to use.
  - ku-man 5y ago
    "... it is silly to compare a full general purpose language against a special-purpose tool..." Wait, wait... isn't Julia a general purpose language? At least is what the fanboys keep repeating ad-nauseaum

enriquto 5y ago

> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00

krastanov 5y ago
Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file. Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.
- enriquto 5y ago
  Sure! That's why I set a somewhat reasonable target at being just 5x or 10x times slower than a specific-purpose plotting tool. But even that is considered to be chimerical! (or, in your words, "ridiculous")
  - krastanov 5y ago
    Now you are just putting words in my mouth. I would completely agree that 10x latency to first plot is a reasonable target (i.e. first plot in about a second, like you get in python and much faster than what you get in matlab/mathematica). And plenty of devs closer to core of Julia and the plotting libraries in it would agree. And to be clear, I do expect my second plot to be ready in tens of milliseconds.
- reikonomusha 5y ago
  Why is it such a ridiculous comparison? Gnuplot is still interpreting a language, loading plotting code, etc. If Julia folks wanted to, they could bundle pre-compiled plotting code that loads as fast as memory moves bytes. They don’t want to, of course, likely because it’s inelegant, but they could, and a general-purpose language doesn’t stop them from doing that.
  - krastanov 5y ago
    You can already bundle pre-compiled plotting code in your Julia sys-image if you want. But Julia is not a plotting tool so it would be ridiculous to optimize it just for plotting. I want ODE solvers to have less latency, should I start expecting gnuplot to have built-in ODE solvers or the official installer of Julia to have the ODE libraries pre-compiled? Maybe this example would make it clearer: why does your argument not apply to Python? Should we expect python libraries to come pre-cached so that the first time I load `sympy` I do not need to wait for tens of seconds to have .pyc files created. Or about matlab? Again, I am all on board with the idea that julia needs lower latency and if you look at what their devs say, they also agree with that. But expecting Julia to be super low-latency (lower-latency than python/c/matlab) for your pet task is silly.
    - reikonomusha 5y ago
      I gave a proof-of-concept argument as to why something doesn’t need to take as long straight out of the box with no customization. Python is doing it sub-1s. You can also include a non-optimizing interpreter. My point is that being a general purpose language doesn’t inherently limit you in any way; instead it’s one’s choice of implementation strategy. Another strategy: when a user installs Julia, they select “fast-loading” libraries. You’d be surprise how small changes in UI/UX make huge perceived differences in quality and performance. I bet “Julia can already do this” too, but nobody does it because it’s not idiomatic and it’s not recommended up front. At the end of the day, people don’t complain about Python or MATLAB as much because they feel nicer. If it feels nicer because of some other reason than absolute time, then they’re doing something about UX that Julia is not, because everybody really does feel Julia is extremely sluggish to use.
- ku-man 5y ago
  "... it is silly to compare a full general purpose language against a special-purpose tool..." Wait, wait... isn't Julia a general purpose language? At least is what the fanboys keep repeating ad-nauseaum