Comment by cmeacham98 | Hacker News Reader

Comment by cmeacham98 | Hacker News Reader

Parent Full thread

You seem to be falling into the same trap you lament in your comment:

- The other side is "these people" that "won't stop"

- They're striving for "hyper-efficiency" at the cost of "hundreds and thousands of hours"

- People who complain about this issue don't (or do significantly less of) reading documentation/code/etc

People talk about TTFP because it is a real issue that is off-putting for many programmers that would otherwise love to use Julia. Julia is roughly an order of magnitude slower than python in this instance on my computer, and that's not a good first impression.

That doesn't mean that everyone is going to be impacted by this issue (obvious ex: you aren't), but this isn't akin to a flamewar because unlike editor choice (which is opinion), Julia would be better for everyone if TTFP was improved. Whether or not it should be prioritized as a development goal is up to the Julia team, but it's not just some difference of opinion like interpreted vs compiled or functional vs OO.

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?

> 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.

It’s not trivial to do, but compiling plots into your sysimg might actually fix that

Thanks! Is there a way to compile all installed packages into the sysimage? If so, why isn't that the default?

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)

> 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.

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

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).

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?

It would be a perfectly fine use-case for Julia if it wasn't so damn slow.

> 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!

If only they could switch to graalvm :m

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...

You may want to look at [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.

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?

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 :)

As you already have the gnuplot commands, perhaps using Julia + 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.

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.

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?

Dang, why can Common Lisp do this so well and Julia so poorly?

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.

> even just redefining a struct field requires restarting the interpreter

It really doesn't if you use a module.

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).

Usually as long as I develop I have structs that I change inside a small module, then I can recompile just the module and access the new struct, e.g. for neural networks.

It's not perfect but it's something.

Useful trick, I'll try that, thanks.

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.

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

Reply on news.ycombinator.com