I made a video about reducing Julia’s latency after a conversation with a friend who said that they really wish all of this information was in one place.
Hence, you get this video. Possibly part one of two, where in the second I cover the packages I referenced in the outro of this one (JuliaFormatter, JET, Aqua, and Cthulhu).
Feedback is very welcome! I will mention, though, that while I do talk about some advanced topics, I try to not go into too much detail so if I glossed over some parts of the video or didn’t mention stuff (how PackageCompiler can do so much more or that the part that I discussed will hopefully one day be redundant) it might be because I decided not to put it in.
Thanks for watching and filling out my workflow survey if you did
Very cool tutorial, taught me a few things, and I loved the drawings
A minor caveat was that the code was changing way too fast (and maybe in too small a font) for me to follow. Perhaps something to keep in mind for the next video?
I also agree that these tips and tricks should stop being part of an unspoken lore and start being explicitly documented in one place. I would love to draft a blog post for the Julia blog, something like “Modern Julian workflows”, where I give an annotated list of what it takes to easily use, and then develop, packages. If you and my idol @jakobnissen would like to contribute, we could get this going.
He was one of the two channels whose style I wanted to emulate along with code_report. Tris got me into Rust, Conor got me into array languages, I hope I can get someone into Julia
Creating new packages, and utilizing Revise.jl the way you showed us, is pretty much contradicting the purpose of a REPL to me.
A REPL is meant to give me straight access to a development environment, and not something that needs complicated setup, that the vast majority of newbies will not even consider to use.
I certainly wouldn’t, and you outline one of the core issues with our REPL workflow. But the proposed solution is even worse to me, than just having to wait half an eternity for the REPL to come up, and then me having to think to close it, if there are still old functions stored.
It complicates things just further, in my opinion.
And we do have an interpreter, that I would like to use as the default backend for the REPL.
No huge startup, and more suitable for small code.
I just think adding @interpret for every execution can be skipped, and loading it in manually seems also counterintuitive to new users.
Is there a huge benefit to JIT all the code at the standard REPL instead?
The interpreter is painful slow for anything more than trivial code. The Debugger is run by the Interpreter, and you don’t have to search very far to find someone be bemoaning the Debugger’s speed. This is why the Debugger has partial compiled mode where most modules are compiled and only user code is interpretered.
Tim Holy has mentioned elsewhere (sorry don’t have a link on hand) that the interpreter could benefit from running the Julia level optimizations before running (cut out the LLVM comp time), but it hasn’t been a higher priority than getting precompilation and such. The introduction of JuliaSyntax should make it easier to trace the optimized Julia IR back to source code, so adding this should be possible now
and I think that’s exactly what you’re looking for. It can be ok for small amount of code, but yes, interpreting will be really slow, even slower than Python, since Python isn’t just an interpreter… It’s actually a compiler to its now very optimized bytecode. Though it’s been getting faster recently and Python is adding JIT.
While the package you mentioned only interprets when you use the @interpret macro, and running globally does always, maybe an opposite package could be made, that has @compiled to force compilation in the interpreter selectively… and I would like at least all package code to do that implicitly since it’s already precompiled.
With packages precompiled (when recompilation doesn’t happen; too frequently) I think Julia is (almost) good as is. You would want to use that precompiled native code (similar to C fast code in Python), and I think the above disables that.
You might want some lesser compilation (but again may force precompilation? throwing out already precompiled unnecessarily), e.g.
julia -O1
I think the main problem with recompilation in Julia is too much optimization, because of inlining, and e.g. --inline=no might help, and this is I think implicit in the above. It’s possible it would force recompilation… I would want use the precompiled code if you can, recompile as little as you could, i.e. inline less for new recompiled code, but keep the inlining you’ve already done.
