5 ms·

I cannot fathom how ttfp is important. It's time to first plot, not to every plot. After it's down to ~10 seconds, why on earth does anyone care?

by DNF2 6y ago

enriquto 6y ago
> I cannot fathom how ttfp is important. I personally do care for my concrete usage pattern. This is my use case: A long shell script that does a lot of things. At some point, inside a loop that runs hundreds of times, it needs to solve a couple of small linear systems and plot a simple graph. There's hundreds of png graphs, that are then combined into a video sequence. Right now, the computation is done by calling octave (inside the loop) and then gnuplot (to create the actual graph from the octave computed data points). I would like to replace each call to octave+gnuplot to a single call to julia. Yet, this would make my script run in a few hours instead of a few seconds, because for this usage pattern all plots are first plots Before you suggest that I should rewrite the whole thing in julia, maybe you are right but 1) it would take me a few weeks that I don't have 2) that's not my point. A good tool is a tool that can be used for purposes that it was not intended to, like this. If the time to first plot in julia was a millisecond instead of 10 seconds, then julia would be a much better tool.
- cbkeller 6y ago
  It’s not trivial to do, but compiling plots into your sysimg might actually fix that
  - enriquto 6y ago
    Thanks! Is there a way to compile all installed packages into the sysimage? If so, why isn't that the default?
    - cbkeller 6y ago
      Technically yes, but then IIRC you’d have to recompile the whole sysimg any time you update any single package, which could get to be a pain. The usual compromise seems to be to include just a handful of your most used packages in the sysimg (say Plots + Revise)
      - enriquto 6y ago
        > you’d have to recompile the whole sysimg any time you update any single package Are there any downsides to this? You never care how long does a system update take. You always care how long do your programs run.
        cbkeller 6y ago
        I’ve never tried it myself, but can’t think of any reason why it wouldn’t work in principle if you do want to go that route
        Sukera 6y ago
        The downside is that PackageCompiler (or SnoopCompile, for that matter) can only pack into the sysimage what it sees. This is usually done by "recording" which methods get called during a session and putting the compiled native code for those into the sysimage. If it's not called during setup, you'll still have dynamic compilation (as for any code that hasn't ever run).
- DNF2 6y ago
  But this is really the worst conceivable use case for Julia. Why are you interested in making this change, when Julia offers no advantage in this scenario?
  - aliceryhl 6y ago
    It would be a perfectly fine use-case for Julia if it wasn't so damn slow.
  - enriquto 6y ago
    > Why are you interested in making this change, when Julia offers no advantage in this scenario? Well I love julia the language. It's the interpreter quirks that I find annoying. If julia had something lean and superfast like luajit it would be incredible!
    - The_rationalist 6y ago
      If only they could switch to graalvm :m
  - whateverwhynot 6y ago
    I'm not the parent, but I faced exactly the same issue when I tried to switch to Julia from scilab. As for why I'd like to switch: Julia is a better language, it is way easy to run your script on a cluster and I've been bitten more than once by the two language problem... So Julia seems better for everything but for one of my most common use cases...
- stillyslalom 6y ago
  You may want to look at [DaemonMode.jl](https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl), which spins up a persistent Julia process in the background so you don't have to pay the TTFP penalty more than once, even when shell-scripting.
- sgt101 6y ago
  Could you cache the requests or write the parameters into a file and then make the call to Juila, and ask it to loop over the requests?
- stjohnswarts 6y ago
  I still have a soft spot for octave. It was my first matrix oriented program. I've moved on to pandas and c++ but I still pull up octave for signal analysis because it's just plain easier and has some great functions and I think it may have created folds in my brain as an EE undergrad that will always be there :)
- jarvist 6y ago
  As you already have the gnuplot commands, perhaps using Julia + https://github.com/gcalderone/Gnuplot.jl https://github.com/gcalderone/Gnuplot.jl might work? It's a very lightweight package, so even using it directly should be OK. I do all my plotting with Gnuplot.jl, as gnuplot is fast, and I can save .gpt files which reproduce the plots for later reference and making publication-quality.
walshemj 6y ago
Me too not to go all four yorkshire man here, but I can remember when you would have to write your own plotting programs in Fortran and then wait for the pen plotter to slowly draw your plot. And not that long before that you would print the results out and manually plot them on graph paper.
saiojd 6y ago
You can't possibly be serious. As things stand, even just redefining a struct field requires restarting the interpreter, which forces you to wait ~10-30 seconds for everything to compile, over and over again. Maybe you only use Julia for small scripts, and can afford to never restart the interpreter?
- the-smug-one 6y ago
  Dang, why can Common Lisp do this so well and Julia so poorly?
  - eigenspace 6y ago
    The assumptions our compiler is able to make about types never changing (and a few other restrictions) allows for a lot of optimizations in julia that are not possible in Common Lisp. Julia's compiler is able to do a few things significantly more aggressively than CL. That said, there is some very interesting work happening on getting around these restrictions. There was a PR from Tim Holy a while ago that could have allowed it, but there were some problems with the PR, and there were also some associated costs that were deemed too steep to pay. That said, there's other great work on other ways around this. For instance, you can dynamically redefine structs all you want in Pluto.jl notebooks and there's no performance penalty! This is something that kinda just fell out as a natural consequence of it's reactive design.
- fishmaster 6y ago
  > even just redefining a struct field requires restarting the interpreter It really doesn't if you use a module.
  - saiojd 6y ago
    I mean, I still need to recompile the module no? Or do you split your project into several small modules to avoid this? (I've avoided this so far as I found the module system a bit tedious tbh, as it requires to explicitly list everything you need to export, as well as manually import stuff from the parent module).
whateverwhynot 6y ago
Well, with Julia it is time to first plot for every new session. So if your typical workflow is to start Julia and just do a single plot of the recently acquired data (quite common workflow in my field), Julia is an order of magnitude slower than python or scilab.
- cbkeller 6y ago
  If that’s your workflow it would probably be highly advisable to compile plots.jl into your sysimg

I cannot fathom how ttfp is important. It's time to first plot, not to every plot. After it's down to ~10 seconds, why on earth does anyone care?

by DNF2 6y ago

I cannot fathom how ttfp is important. It's time to first plot, not to every plot. After it's down to ~10 seconds, why on earth does anyone care?

enriquto 6y ago

> I cannot fathom how ttfp is important. I personally do care for my concrete usage pattern. This is my use case: A long shell script that does a lot of things. At some point, inside a loop that runs hundreds of times, it needs to solve a couple of small linear systems and plot a simple graph. There's hundreds of png graphs, that are then combined into a video sequence. Right now, the computation is done by calling octave (inside the loop) and then gnuplot (to create the actual graph from the octave computed data points). I would like to replace each call to octave+gnuplot to a single call to julia. Yet, this would make my script run in a few hours instead of a few seconds, because for this usage pattern all plots are first plots Before you suggest that I should rewrite the whole thing in julia, maybe you are right but 1) it would take me a few weeks that I don't have 2) that's not my point. A good tool is a tool that can be used for purposes that it was not intended to, like this. If the time to first plot in julia was a millisecond instead of 10 seconds, then julia would be a much better tool.

cbkeller 6y ago
It’s not trivial to do, but compiling plots into your sysimg might actually fix that
- enriquto 6y ago
  Thanks! Is there a way to compile all installed packages into the sysimage? If so, why isn't that the default?
  - cbkeller 6y ago
    Technically yes, but then IIRC you’d have to recompile the whole sysimg any time you update any single package, which could get to be a pain. The usual compromise seems to be to include just a handful of your most used packages in the sysimg (say Plots + Revise)
    - enriquto 6y ago
      > you’d have to recompile the whole sysimg any time you update any single package Are there any downsides to this? You never care how long does a system update take. You always care how long do your programs run.
      - cbkeller 6y ago
        I’ve never tried it myself, but can’t think of any reason why it wouldn’t work in principle if you do want to go that route
      - Sukera 6y ago
        The downside is that PackageCompiler (or SnoopCompile, for that matter) can only pack into the sysimage what it sees. This is usually done by "recording" which methods get called during a session and putting the compiled native code for those into the sysimage. If it's not called during setup, you'll still have dynamic compilation (as for any code that hasn't ever run).
DNF2 6y ago
But this is really the worst conceivable use case for Julia. Why are you interested in making this change, when Julia offers no advantage in this scenario?
- aliceryhl 6y ago
  It would be a perfectly fine use-case for Julia if it wasn't so damn slow.
- enriquto 6y ago
  > Why are you interested in making this change, when Julia offers no advantage in this scenario? Well I love julia the language. It's the interpreter quirks that I find annoying. If julia had something lean and superfast like luajit it would be incredible!
  - The_rationalist 6y ago
    If only they could switch to graalvm :m
- whateverwhynot 6y ago
  I'm not the parent, but I faced exactly the same issue when I tried to switch to Julia from scilab. As for why I'd like to switch: Julia is a better language, it is way easy to run your script on a cluster and I've been bitten more than once by the two language problem... So Julia seems better for everything but for one of my most common use cases...
stillyslalom 6y ago
You may want to look at [DaemonMode.jl](https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl), which spins up a persistent Julia process in the background so you don't have to pay the TTFP penalty more than once, even when shell-scripting.
sgt101 6y ago
Could you cache the requests or write the parameters into a file and then make the call to Juila, and ask it to loop over the requests?
stjohnswarts 6y ago
I still have a soft spot for octave. It was my first matrix oriented program. I've moved on to pandas and c++ but I still pull up octave for signal analysis because it's just plain easier and has some great functions and I think it may have created folds in my brain as an EE undergrad that will always be there :)
jarvist 6y ago
As you already have the gnuplot commands, perhaps using Julia + https://github.com/gcalderone/Gnuplot.jl https://github.com/gcalderone/Gnuplot.jl might work? It's a very lightweight package, so even using it directly should be OK. I do all my plotting with Gnuplot.jl, as gnuplot is fast, and I can save .gpt files which reproduce the plots for later reference and making publication-quality.

walshemj 6y ago

Me too not to go all four yorkshire man here, but I can remember when you would have to write your own plotting programs in Fortran and then wait for the pen plotter to slowly draw your plot. And not that long before that you would print the results out and manually plot them on graph paper.

saiojd 6y ago

You can't possibly be serious. As things stand, even just redefining a struct field requires restarting the interpreter, which forces you to wait ~10-30 seconds for everything to compile, over and over again. Maybe you only use Julia for small scripts, and can afford to never restart the interpreter?

the-smug-one 6y ago
Dang, why can Common Lisp do this so well and Julia so poorly?
- eigenspace 6y ago
  The assumptions our compiler is able to make about types never changing (and a few other restrictions) allows for a lot of optimizations in julia that are not possible in Common Lisp. Julia's compiler is able to do a few things significantly more aggressively than CL. That said, there is some very interesting work happening on getting around these restrictions. There was a PR from Tim Holy a while ago that could have allowed it, but there were some problems with the PR, and there were also some associated costs that were deemed too steep to pay. That said, there's other great work on other ways around this. For instance, you can dynamically redefine structs all you want in Pluto.jl notebooks and there's no performance penalty! This is something that kinda just fell out as a natural consequence of it's reactive design.
fishmaster 6y ago
> even just redefining a struct field requires restarting the interpreter It really doesn't if you use a module.
- saiojd 6y ago
  I mean, I still need to recompile the module no? Or do you split your project into several small modules to avoid this? (I've avoided this so far as I found the module system a bit tedious tbh, as it requires to explicitly list everything you need to export, as well as manually import stuff from the parent module).

whateverwhynot 6y ago

Well, with Julia it is time to first plot for every new session. So if your typical workflow is to start Julia and just do a single plot of the recently acquired data (quite common workflow in my field), Julia is an order of magnitude slower than python or scilab.

cbkeller 6y ago
If that’s your workflow it would probably be highly advisable to compile plots.jl into your sysimg