3 ms·

>The TTFP is too damn high and I don't think it will ever be fixed. I just installed and ran on my macbook - took me 7 minutes to get it installed and run thro

by sgt101 3y ago

>The TTFP is too damn high and I don't think it will ever be fixed. I just installed and ran on my macbook - took me 7 minutes to get it installed and run through to a first plot, most of that was installing and compiling the Plots library. Once it's installed and available I can run it in about 1 second and then execute using Plots function test_plot() x = range(0, 10, length=100) y = sin.(x) plot(x, y) end @time test_plot() which gives me a result of 0.048700s and a nice plot. I don't think this is the defining issue with Julia now - it definitely used to be 10 years ago - but now it's more than competitive with Python in this regard. The issue is really support and buy in for all the new cool libraries that folks make available to use.

jampekka 3y ago
That's not TTFP. TTFP is putting that code into a file (e.g. ttfp.jl) and running: $ time ./julia-1.9.4/bin/julia ttfp.jl 0.325806 seconds (202.80 k allocations: 13.208 MiB, 84.23% compilation time) real 0m2.401s user 0m2.357s sys 0m0.553s I.e. the TTFP is 2.4 seconds, not 0.33 seconds. That said, 2.4s is huge progress (e.g. with Julia 1.6.0 it's 10 seconds for me) and acceptable for most simple plotting. But just adding e.g. "using DynamicalSystems" brings this to 14 seconds, which is not acceptable for iterative editing. And it makes any Julia program using "DynamicalSystems" wildly impractical to use in a pipeline with other programs.
- adgjlsfhk1 3y ago
  Also for the record, 1.10 rc1 brings the time down to 1.1 seconds (from 1.9 seconds in version 1.9 on my laptop). There's still more work to do, but there's been a ton of progress on this in the last year or so.
  - sertbdfgbnfgsd 3y ago
    No point having this conversation. These people are still repeating memes from 5 years ago. I've met one of them in the wild, it was quite eye opening.
    - jampekka 3y ago
      You are probably having a different conversation. This is my conversation: $ time ./julia-1.10.0-rc2/bin/julia -e "using Plots; using DynamicalSystems;" 0m5.433s This is a different conversation from julia> @time plot(x, y) 0.000465 seconds (484 allocations: 45.992 KiB) But I agree that the conversation is pointless. The TTFX will never be fixed for Julia to be used with sane workflows because the few still using Julia don't want to accept the problem. But the flamewars are fun anyhow and maybe they prevent the next Julia from making the same mistakes.
      - adgjlsfhk1 3y ago
        I think this conversation is absolutely worth having. It's great to see that 1.10 is ~3x faster here, and there's probably another ~2 to 3x improvement or so from profiling DynamicalSystems to see where the time is going. That said, for sub second startup time with lots of packages, I highly recommend using PackageCompiler to make a custom system image which brings the using time down to roughly 0.
        jampekka 3y ago
        Is shaving seconds-per-package import a feasible way to get the startup time fast enough for script-type workflows? Before long you end up importing 10 packages and it will be too slow even if each package is 1s. I appreciate that the devs seem to want to do it "the right way" but that seems have taken quite a while. Wouldn't something like slow interpreter option for "glue code" be feasible? Most code doesn't need to be fast, and waiting for the "hot functions" to compile on change wouldn't be too bad. And you could still AOT for maximum speed when needed. This is essentially how Javascript JITs manage to start up so fast. Another fine "hack" for many cases would be to keep the Julia process running (like a daemon) but making sure the state is clean when a script is run on it. Something like PackageCompiler is workable, at least for the short term. Long compiles are OK if they don't have to be done all the time. I indeed manage to get < 1s TTFP with DynamicalSystems with it (last time I tried a while ago I didn't manage). The UX for creating sysimages could be nicer, but doesn't seem anything that a quick script can't fix. Maybe I'll give Julia another go in my next analysis. From what I gather there's now a new approach for caching the compilation results. I really hope it will succeed, but I'm a bit jaded from the many "Julia 1.x fixes the TTFX" news.
cozzyd 3y ago
So I tried this after I installed julia on my system (Fedora) and installed the Plots package. It took about a second or so, not too bad, slower than ROOT or matplotlib but not too different from octave... but the default backend is not interactively zoomable at all as far as I can tell? Ok, I can do Pkg.add("PyPlot") to use matplotlib, but now this takes an extra ~10 seconds? It would probably have been faster to mmap a shared file, dump the data there, then, fork a new python process and plot it... maybe I try the plotly backend (which doesn't need any new packages, that's nice), but now it opens in my browser? By now my .julia directory has balloned to 2.8 GB (!!!) and I'm bored of this test and go back to making my quick plots in ROOT :). edit: oops, maybe PythonPlot is what i should use, not PyPlot. But when I try that I see: ┌ Warning: `PythonPlot` 1.0.3 is not compatible with this version of `Plots`. The declared compatibility is 1 - 1.0.2.[ and doesn't seem to be any faster

by sgt101 3y ago

jampekka 3y ago

That's not TTFP. TTFP is putting that code into a file (e.g. ttfp.jl) and running: $ time ./julia-1.9.4/bin/julia ttfp.jl 0.325806 seconds (202.80 k allocations: 13.208 MiB, 84.23% compilation time) real 0m2.401s user 0m2.357s sys 0m0.553s I.e. the TTFP is 2.4 seconds, not 0.33 seconds. That said, 2.4s is huge progress (e.g. with Julia 1.6.0 it's 10 seconds for me) and acceptable for most simple plotting. But just adding e.g. "using DynamicalSystems" brings this to 14 seconds, which is not acceptable for iterative editing. And it makes any Julia program using "DynamicalSystems" wildly impractical to use in a pipeline with other programs.

adgjlsfhk1 3y ago
Also for the record, 1.10 rc1 brings the time down to 1.1 seconds (from 1.9 seconds in version 1.9 on my laptop). There's still more work to do, but there's been a ton of progress on this in the last year or so.
- sertbdfgbnfgsd 3y ago
  No point having this conversation. These people are still repeating memes from 5 years ago. I've met one of them in the wild, it was quite eye opening.
  - jampekka 3y ago
    You are probably having a different conversation. This is my conversation: $ time ./julia-1.10.0-rc2/bin/julia -e "using Plots; using DynamicalSystems;" 0m5.433s This is a different conversation from julia> @time plot(x, y) 0.000465 seconds (484 allocations: 45.992 KiB) But I agree that the conversation is pointless. The TTFX will never be fixed for Julia to be used with sane workflows because the few still using Julia don't want to accept the problem. But the flamewars are fun anyhow and maybe they prevent the next Julia from making the same mistakes.
    - adgjlsfhk1 3y ago
      I think this conversation is absolutely worth having. It's great to see that 1.10 is ~3x faster here, and there's probably another ~2 to 3x improvement or so from profiling DynamicalSystems to see where the time is going. That said, for sub second startup time with lots of packages, I highly recommend using PackageCompiler to make a custom system image which brings the using time down to roughly 0.
      - jampekka 3y ago
        Is shaving seconds-per-package import a feasible way to get the startup time fast enough for script-type workflows? Before long you end up importing 10 packages and it will be too slow even if each package is 1s. I appreciate that the devs seem to want to do it "the right way" but that seems have taken quite a while. Wouldn't something like slow interpreter option for "glue code" be feasible? Most code doesn't need to be fast, and waiting for the "hot functions" to compile on change wouldn't be too bad. And you could still AOT for maximum speed when needed. This is essentially how Javascript JITs manage to start up so fast. Another fine "hack" for many cases would be to keep the Julia process running (like a daemon) but making sure the state is clean when a script is run on it. Something like PackageCompiler is workable, at least for the short term. Long compiles are OK if they don't have to be done all the time. I indeed manage to get < 1s TTFP with DynamicalSystems with it (last time I tried a while ago I didn't manage). The UX for creating sysimages could be nicer, but doesn't seem anything that a quick script can't fix. Maybe I'll give Julia another go in my next analysis. From what I gather there's now a new approach for caching the compilation results. I really hope it will succeed, but I'm a bit jaded from the many "Julia 1.x fixes the TTFX" news.

cozzyd 3y ago

So I tried this after I installed julia on my system (Fedora) and installed the Plots package. It took about a second or so, not too bad, slower than ROOT or matplotlib but not too different from octave... but the default backend is not interactively zoomable at all as far as I can tell? Ok, I can do Pkg.add("PyPlot") to use matplotlib, but now this takes an extra ~10 seconds? It would probably have been faster to mmap a shared file, dump the data there, then, fork a new python process and plot it... maybe I try the plotly backend (which doesn't need any new packages, that's nice), but now it opens in my browser? By now my .julia directory has balloned to 2.8 GB (!!!) and I'm bored of this test and go back to making my quick plots in ROOT :). edit: oops, maybe PythonPlot is what i should use, not PyPlot. But when I try that I see: ┌ Warning: `PythonPlot` 1.0.3 is not compatible with this version of `Plots`. The declared compatibility is 1 - 1.0.2.[ and doesn't seem to be any faster