Julia 1.6 Highlights (opens in new tab)

I will make a blog post about it.

Yes. I used Flux.

I guess the reason is that Julia's type system and standard libraries really guide users to use types that the JIT can unbox as far as possible.

The combination. E.g multiple dispatch without JIT would be really slow as you are picking a method to run at runtime based on the type of all the function arguments.

That requires a linear search through a list of all possible combinations of input arguments.

In a single dispatch language like most object oriented languages, you can do a simple dictionary/hash table lookup. Much faster.

With the JIT Julia is able the optimize away most of these super slow lookups at runtime. Hence you get multiple dispatch for all functions but with fantastic performance. Nobody had done that before.

This video is good explaining the idea behind multiple dispatch in Julia if you have time:

https://www.youtube.com/watch?v=kc9HwsxE1OY

It's like C++ template specialisation, but it happens when the compiler realises you need a particular version. Which may be at runtime, if you changed something.

What the OP is talking about is julia's method-based JIT strategy coupling very well to multiple dispatch.

JIT is not new, multiple dispatch is not new, and multiple dispatch + JIT also isn't new, but nmo existing langauges combined them in a way that allows for the fantastic, efficient devirtualization of generic methods that julia is so good at.

This is why things like addition and multiplication are not generic functions in Common Lisp, it's too slow in CL because the CLOS is not able to efficiently devirtualize the dispatch. In julia, everything is a generic function, and we use this fact to great effect.

CLOS and Dylan laid a ton of important groundwork for these developments, but they're also not the same.

Languages with multiple dispatch aren't rare, but a language having it as the core language paradigm, combined with a compiler capable of completely resolving the method calls during compile time, and therefore able to remove all runtime costs of the dispatch, and a community that fully embraced the idea of creating composable ecosystems is something unique to Julia. I don't think anyone has scaled multiple dispatch to the level of Julia's ecosystem before.

Common lisp’s typesystem is just not really as useful for this sort of thing. In particular it doesn’t have parameter used types so you can’t make eg a matrix of complex numbers. This breaks (1) a lot of the opportunity for optimisation by inlining (because you can’t assume that all the multiplications in your matrix{float} multiplication are regular float multiplications) or generic code (because you can’t have a generic matrix type and need a special float-matrix); and (2) opportunities for saving memory with generic data structures because the types must be associated to the smallest units and not the container (eg every object in a float matrix must be tagged with the fact that it is a float because in theory you could put a complex number in there and then you’d need to know to do a different multiplication operation).

I guess you could try to hack together some kind of templating feature to make new type-specific classes on the fly, but this won’t work well with subtyping. Your template goes system could probably have (matrix float) as a subclass of matrix, but not of (matrix real) or (matrix number). I think you’d lose too much in Common Lisp’s hodge-podge type system.

A big innovation of Julia was figuring out how to make generic functions and multiple dispatch work in a good way with the kind of generic data structures you need for good performance. And this was not a trivial problem at all. Julia’s system let’s you write generic numeric matrix code while still having float matrix multiplication done by LAPACK, which seems desirable.

The other thing is that Julia is a language where generic functions are a low-level thing all over the standard library whereas Common Lisp has a mix of a few generic functions (er, documentation is one; there are more in cltl2), a few “pre-clos” generic functions like mathematical functions, sequence functions and to some extent some array functions, and a whole lot of non-generic functions.

Wikipedia has a nice table [1] on the Multiple Dispatch page, that describes one studies' findings about the use of multiple dispatch in languages supporting it, in practice.

Although CLOS and others do support it, Julia seems to take the cake by most metrics, highlighting that it is a core paradigm of the language, more so than in the others.

Even better check Stanza language for modern version and interpretation of Lisp, Scheme and Dylan. It supports multi-method/multiple dispatches, hybrid dynamic and static typing, high and low level programming to name a few productive features.

[1]http://lbstanza.org/

I agree, this is a game changer. Previously time to first plot (TTFP) was >1 minute for me, which made julia completely unusable for my day-to-day exploratory data analysis, visualisation, quick random number experiments etc. Now TTFP is less than 10 seconds. I'm now ready (and excited) to jump ship from R and python!

No idea if this is really a fair comparison but just to get a brief idea of current speeds:

   julia> @time let
          using Plots
          plot([sin, cos])
          end
        11.267558 seconds (17.98 M allocations: 1.114 GiB, 4.83% gc time)

Versus Matlab which probably takes about 15 seconds just to open the editor but plotting is very fast.

   >> tic
   fplot( @(x) [sin(x) cos(x)])
   toc
   Elapsed time is 0.374394 seconds.

Julia is just about as fast as Matlab after the first run for plotting.

I’ve also been running the release candidates, and I get something like 6 seconds to first plot on my 2013 laptop, including the time for `using Plots` and the time to actually draw the first plot. A huge improvement; kudos to the developers.

I think that’s true for small structs made of floats but not true for something like an immutable lisp-style linked list.

It doesn’t, it just doesn’t have a $100B GC like Java does. Rather than spending that kind of money trying to compensate for a language design that generates massive amounts of garbage (ie Java), Julia takes the approach of making it easier to avoid generating garbage in the first place, eg by using immutable structures that can be stack allocated and having nice APIs for modifying pre-allocated data structures in place.

The biggest struggle Julia's GC has is that in multi-threaded workloads, it sometimes isn't aggressive enough to reclaim memory leading to OOM.

In your experience, what are the current limitations?

Currently you can make a relocatable “bundle” / “app” with PackageCompiler.jl, but the bundle itself includes a Julia runtime.

Making a nice small static binary is technically possible using an approach similar to what GPUCompiler.jl does, but the CPU equivalent of that isn’t quite ready for primetime.

You probably want to check out PackageCompiler.jl (https://julialang.github.io/PackageCompiler.jl/dev/)

no it has not, they now have different rules for repl, which is part of scope awkwardness

Should that issue be closed then?

Ohh, is that what the programmers were doing all through Halt and Catch Fire? Waiting for compilation? I couldn't understand how they got away with acting like naughty 5 year olds, throwing things at each other constantly.

Yeah, we've managed to get Julia itself running pretty well on the M1, there are still a few outstanding issues such as backtraces not being as high-quality as on other platforms. You can see the overall tracking issue [0] for a more granular status on the platform support.

For the package ecosystem as a whole, we will be slowly increasing the number of third-party packages that are built for aarch64-darwin, but this is a major undertaking, so I don't expect it to be truly "finished" for 3-6 months. This is due to both technical issues (packages may not build cleanly on aarch64-darwin and may need some patching/updating especially since some of our compilers like gfortran are prerelease testing builds, building for aarch64-darwin means that the packages must be marked as compatible with Julia 1.6+ only--due to a limitation in Julia 1.5-, etc...) as well as practical (Our packaging team is primarily volunteers and they only have so much bandwidth to help fix compilation issues).

[0] https://github.com/JuliaLang/julia/issues/36617

Cool, I'll start with 1.6, but it looks interesting of course :)

Seems like you're the founder of Julia. Why such a knee jerk reaction? Did you read the benchmark page? The table of content is right at the top.

Optics of this type of reaction is seen everywhere in the Julia community. My advice is to embrace negativity around the language, try to understand if it is fabrication or legitimate, and address the shortcomings.

Julia is a beautiful language and hope some of the warts of the language gets fixed.

Your relative skill and time invested in Julia vs Go makes that a not very fair comparison, I think. A 100x difference in performance is probably a sign of something that could be fixed in your code (common one: type instability). In general, Julia is being used to implement things like competitive versions of BLAS. Your Julia code can almost certainly be made much faster.

Coming from a Python and C++ background, I found it sufficient to just read the docs and do some Advent of Code problems to get productive in Julia. What videos are you talking about? https://docs.julialang.org/en/v1/manual/performance-tips/ I found to be a pretty good document on why and when Julia can be slow.

I simply do not understand how some people are able to form so strong opinions in such a short time, and spew out disdain and negativity on the most flimsy basis. It's a matter of temperament, I guess.

Julia performance should be on par with Go, if it's slower, read the performance tips in the manual. As for teaching material on 3rd party websites, I don't know what you mean. The Julia manual is available from the julialang.org website.

As for re-writing DifferentialEquations, that is extremely strongly tied to the multiple dispatch paradigm, re-writing it would be hard. What you can get is wrappers like diffeqpy and diffeqr, which call out to Julia.

I love the Julia community

@btime reports the minimum execution time, since all increases are attributable to noise. Use @benchmark to get mean, median and maximum instead.

Beautiful

This is really cool!

But note that OP uses larger cells (`int` = 32 bit in the C version, `Int` = 64 bit in the Julia version) while GalaxyBrain seems to use 8 bit cells. Not that I expect this to make a major difference (but perhaps a minor one?)

That is very cool.

They are measuring compile time and runtime speed, not just runtime speed like for statically compiled langauges

> Second to write very fast julia u need to knew a lot of "tricks" and in most cases u won't be doing it as easy as writing normal code.

That's true in literally any language. Some languages require inlined assembly. Others require preprocessor directives. In almost all languages, you need to understand the difference between stack and heap, know how to minimize allocations, know how to minimize dynamic dispatch, know how to efficiently structure cache-friendly memory layouts. And of course, data structures & algorithms 101.

In terms of performance, Julia provides the following:

1. Zero-cost abstractions. And since it has homoiconic macros, users can create their own zero-cost abstractions, e.g. AoS to SoA conversions, auto-vectorization. Managing the complexity-performance trade-off is critical. But you don't see that in micro-benchmarks.

2. Fast iteration speed. Julia is optimized for interactive computing. I can compile any function into its SSA form, LLVM bytecode, or native assembler. And I can inspect this in a Pluto notebook. Optimizing Julia is fun, which is less true in other languages.

To be fair Julia gives you better tools to analyze your code and figure out how to write more efficient. Being able to look at all the steps a JIT compiler will perform on an individual function helps a lot in building an intuition about what you should and should not do while writing high performance Julia code

Much appreciated.

Small nitpick; its Project.toml (or JuliaProject.toml, to avoid name clashes) not Projects.toml

Or you can activate a local project in a directory, add packages and the Project.toml gets created for you.

Since 0.7 (which was 1.0 with deprecations) In julia 0.6 and before it was exactly as bad as described. (though there were things like Playground.jl to kind of work around it)

Julia is a competitor of R, hence the comparison.

Doesn’t mean it’s adopted though.

After the issue, I nuked the .julia folder, and now it is taking too long to clone the "JuliaRegistries/General.git" repo.

By the download speed, it might take a few hours before I can plot something.

It also seems that just doing "git clone JuliaRegistries/General.git" is much faster than doing "] add Plots"

A quick bit of googling shows that people have been complaining about and reporting this for years.

I see. But you should work on your release process if thing like this happen.