julia> @time (using Plots; display(plot(1:0.1:10, sin.(1:0.1:10))))
9.694037 seconds (18.29 M allocations: 1.164 GiB, 4.17% gc time, 0.40% compilation time)
In an ideal world Julia would have two backends:
- A fast, hand-made JIT backend (something like LuaJIT) which is mostly interpreted and only JIT-compiled in frequently run code paths.
- The current slow, almost-AOT-like LLVM backend which is only used for precompilation of packages
It's just like Debug/Release bulids in C++, except that the Debug builds are lightning fast to compile (but slower at runtime) and Release builds are slower to compile (but hyper-optimized for runtime speed). I guess there's going to be an immense engineering effort if something like this happens, given that Julia today is immensely coupled with the LLVM compiler/runtime. But that's just my pipe dream.
It's more useful to think of Julia's latency as a fundamental constraint of the compilation model. People don't complain that Python can't deliver static binaries, or that C++ is unsuitable for scripting. Julia's compiler can do both (although the "static binaries" haven't materialized, because noone seriously works on it), but the tradeoff is that you suffer from latency. That's fundamental. Future versions of Julia may cut the compilation time down further, but it will never be instant or even close to instant.
So, like other languages, it means you have to look at the strengths and weaknesses of the language for your use case. For myself, I can't imagine a situation where I want to plot something right now and not in 15 seconds. Whenever I plot something, it's always after minutes or (usually) hours of data analysis. Most of my Julia use is either long, interactive sessions where ten seconds of startup doesn't matter much, or long-running pipelines where it doesn't, either.
If you have N scripts that produce N plots for a paper, you can't just drop them in a makefile or you will pay the 15 second penalty over and over and over every time you build. You can't reset the interactive session as a matter of habit to aggressively control state build-up. Even iterating on a dashboard becomes painful with a long startup time. You have to treat your Julia session like a child, not like cattle. That's limiting and not everyone wants to it, especially now that they are used to treating python sessions like cattle and reaping the benefits.
It seems like every time julia is mentioned, someone has to clarify this.
I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like the interpreter in LuaJIT (https://luajit.org/) and HashLink (https://hashlink.haxe.org/) is what comes into my mind.
:/
As Julia relies on Unicode for its neatly formatted variable names this is an annoying limitation that the developers can't even do much about.
Unicode has over 100k symbols, including about 3500 emoji. But a continuous set of 26 small letters, either in lowercase or uppercase(or both) is too much bloat apparently.
[0]: https://stackoverflow.com/questions/17908593/how-to-find-the...
It's just so bewildering when on one hand lowercase superscript is missing exactly one letter for the full coverage, and at the same time Unicode has characters like "Grinning cat face with smiling eyes"(U+1F638). Just what I needed.
It's a bit disappointing because together with the integration in the REPL this feature in Julia works well enough to give a glimpse of the potential but when trying to experiment more it shows gaps that make it a bit of a trial-and-error situation. Better direct support in standardized encodings could make this much more usable and maybe not just in one specific language.
Original paper was awesome. Execution of the language IMO hasn’t been good despite of great marketing.
I tried paste the code but it was hard to read. You can search Histograms in this page https://datasciencejuliahackers.com/03_probability_intro.jl....
Did you have a more specific question about mapping or iteration in Julia?
If you have a mapping dict defined I think the syntax is just `replace!.(rainData.month, monthMap...)`, not tested though.
[sin(x) for x in vec]
map(sin, vec)
sin.(vec)
rainData.month = map(mth -> myEsEnDict[mth], rainData.month)
There are quite a lot of different ways of mapping in Julia, including functions like `map`, `mapreduce`, `replace`, and various syntaxes for broadcasting and array comprehensions.
For maximum SIMD performance there are also things like `vmap` and `vmapreduce` from LoopVectorization.jl.
One of the other commenters also mentioned the `replace` function, which could be used in place of a loop.
Pluto: Jupyter without hidden state.
I can't wait to try it out. I did my thesis work in Julia ~5 years ago but abandoned it afterwards precisely because state management was so painful. At that time, Julia took 30 seconds to start (compile the plotting library), so you basically had to use live sessions, and they had all the usual stateful foot-guns, which made for a very painful overall experience. Performance was still pretty rough last time I tried it (build caching on the libraries didn't happen on install and even post-install wasn't Just Working), but Pluto sounds like a strong enough mitigation to be worth a try!
auto-precompile
Hacker News presents: X is all you need for Hackers considered harmful