Julia 1.6 Highlights • Hacker News Board

Re: Julia 1.6 Highlights

#211

Post by Buttons840 » Sat, Mar 27, 2021, 1:01 AM UTC

wiz21c wrote: post #187

Buttons840 wrote: post #157

I recently ported a reinforcement learning algorithm from PyTorch to Julia. I did my best to keep the implementations the same, with the same hyperparameters, network sizes, etc. I think I did a pretty good job because the performance was similar, solving the CartPole environment in the a similar number of steps, etc. The Julia implementation ended up being about 2 to 3 times faster. I timed the core learning loops,…

could you tell us more ? It looks like a very in depth / interesting benchmark

I will make a blog post about it.

Re: Julia 1.6 Highlights

#212

Post by socialdemocrat » Sat, Mar 27, 2021, 1:15 AM UTC

mbauman wrote: post #192

socialdemocrat wrote: post #156

Earlier quoted context omitted.

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 th…

FWIW, Julia does segment its method tables into multiple layers depending upon size and type. Multiple dispatch is a strict superset of single-dispatch, and indeed the first layer is just a dictionary/hash table lookup on the first argument. If there's only one result there, you're done (and have the same ~cost for the same ~complexity).

Thanks, I didn't know that! Has it always been like that? I wondering where I got the idea that it was always a linear search from? Maybe that is just the conceptual way of explaining it.

Re: Julia 1.6 Highlights

#213

Post by jpfr » Sat, Mar 27, 2021, 1:58 AM UTC

staticfloat wrote: post #147

dan-robertson wrote: post #144

Earlier quoted context omitted.

I wonder how much Julia could be helped with some uneval/image-saving magic. So when you run the repl you instead get a pre-built binary with plot already loaded and several common specialisations already compiled.

We call these "system images" and you can generate them with PackageCompiler [0]. Unfortunately, it's still a little cumbersome to create them, but this is something that we're improving from release to release. One possible future is where an environment can be "baked", such that when you start Julia pointing to that environment (via `--project`) it loads all the packages more or less instantaneously. The downside i…

Easy, you only have to add a handful of „battery included“ packages to the default system image.

That however means that some packages get a preferred status in the Julia ecosystem.

Re: Julia 1.6 Highlights

#214

Post by dan-robertson » Sat, Mar 27, 2021, 2:25 PM UTC

eigenspace wrote: post #65

odipar wrote: post #53

I like Julia (mostly because of multiple dispatch). The only thing that's lacking is an industry strength Garbage Collector, something that can be found in the JVM. I know that you shouldn't produce garbage, but I happen to like immutable data structures and those work better with optimised GCs.

Julia's garbage collector is quite good. > I know that you shouldn't produce garbage, but I happen to like immutable data structures and those work better with optimised GCs. If you use immutable data-structures in julia, you're rather unlikely to end up with any heap allocations at all. Unlike Java, Julia is very capable of stack allocating user defined types.

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

Re: Julia 1.6 Highlights

#215

Post by bananaquant » Sat, Mar 27, 2021, 3:15 PM UTC

RyEgswuCsn wrote: post #186

snicker7 wrote: post #163

Earlier quoted context omitted.

> 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, kno…

> 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. I think what s/he meant…

Julia optimizes for a different thing. You can get your result, as in the actual useful thing that the code does/produces, much faster than with C/C++. You can skip type annotations, not worry about the memory usage, and write your code interactively using REPL or the excellent Revise.jl package.

If you have saved a couple of minutes or hours of coding and are only going to run that code a handful of times, it should not matter if it runs a second or two slower than C/C++. This is the same rationale that Python and other scripting languages have. But unlike Python, you should be able to match the speed of C/C++ or get pretty close by optimizing your code.

Re: Julia 1.6 Highlights

#216

Post by teleforce » Sun, Mar 28, 2021, 1:06 AM UTC

pjmlp wrote: post #78

beeforpork wrote: post #50

Julia is such a wonderful language. There are many design decisions that I like, but most importantly to me, its ingenious idea of combining multiple dispatch with JIT compilation still leaves me in awe. It is such an elegant solution to achieving efficient multiple dispatch. Thanks to everyone who is working on this language!

I advise you to check Common Lisp CLOS and Dylan.

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/

Re: Julia 1.6 Highlights

#217

Post by RyEgswuCsn » Sun, Mar 28, 2021, 2:09 AM UTC

bananaquant wrote: post #215

RyEgswuCsn wrote: post #186

Earlier quoted context omitted.

> 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. I think what s/he meant…

Julia optimizes for a different thing. You can get your result, as in the actual useful thing that the code does/produces, much faster than with C/C++. You can skip type annotations, not worry about the memory usage, and write your code interactively using REPL or the excellent Revise.jl package. If you have saved a couple of minutes or hours of coding and are only going to run that code a handful of times, it should…

Yes I get your point. I guess I should have phrased my first question like the following

1. Can unoptimised Julia code run faster than unoptimised Python code (with numpy being used to do the heavy lifting)?

Let's say one is prototyping some algorithm so iteration speed is more relevant than running speed. Then one can choose either Julia or Python (with the help of numpy perhaps) and get an implementation in similar timeframes. So Julia won't necessarily be more attractive here.

Now if the prototype proved that running speed is very critical to the successful application of the algorithm, then it would mean the developer now has to optimise the hell out of it. One can either:

1. Optimise the Julia codebase, if Julia was used to prototype, following the many tips and tricks available (e.g. type stability, various macros, etc.).

2. Port the algorithm to C/C++, applying the many performance best practices that people have accumulated over the years.

So if the optimised C/C++ port is capable of being any faster than the optimised Julia code, then the rational choice would be to port the implementation using C/C++; it would also mean Python would have some advantage over Julia in the prototyping phase too due to its popularity. Otherwise I'd agree that using a single language to both do prototyping and production is the best.

Re: Julia 1.6 Highlights

#218

Post by cbolton » Sun, Mar 28, 2021, 6:03 PM UTC

siproprio wrote: post #105

MisterBiggs wrote: post #61

Earlier quoted context omitted.

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 Matl…

> Matlab which probably takes about 15 seconds just to open the editor Try this: matlab -nosplash -nodesktop -r "tic; fplot( @(x) [sin(x) cos(x)]); toc"

This took 25 seconds on my laptop (15 seconds the second time, when the filesystem was warm).

Re: Julia 1.6 Highlights

#219

Post by DNF2 » Mon, Mar 29, 2021, 9:25 AM UTC

RyEgswuCsn wrote: post #217

bananaquant wrote: post #215

Earlier quoted context omitted.

Julia optimizes for a different thing. You can get your result, as in the actual useful thing that the code does/produces, much faster than with C/C++. You can skip type annotations, not worry about the memory usage, and write your code interactively using REPL or the excellent Revise.jl package. If you have saved a couple of minutes or hours of coding and are only going to run that code a handful of times, it should…

Yes I get your point. I guess I should have phrased my first question like the following 1. Can unoptimised Julia code run faster than unoptimised Python code (with numpy being used to do the heavy lifting)? Let's say one is prototyping some algorithm so iteration speed is more relevant than running speed. Then one can choose either Julia or Python (with the help of numpy perhaps) and get an implementation in similar…

This depends on what you mean by '(un)optimized code'. Because there's a difference between unoptimized and naive code.

'Unoptimized' code should still observe most of the performance tips in the manual (such as avoiding globals and type instability), while 'naive' code frequently does not. With some experience, you never write naive code, even for quick prototypes.

In those cases, Julia should outperform other dynamic lanuages significantly, and approach static languages in most cases.

Proper optimization means going in and removing allocations, ensuring that operations vectorize (simd), tailoring data structures for performance, adding parallelism etc. In the latter case Julia should virtually _always_ match static languages closely, otherwise it merits investigation.

Re: Julia 1.6 Highlights

#220

Post by DNF2 » Mon, Mar 29, 2021, 9:30 AM UTC

siproprio wrote: post #119

StefanKarpinski wrote: post #116

Earlier quoted context omitted.

Please file an issue describing the situation: https://github.com/JuliaLang/julia/issues/new

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"

This is a Windows issue, I'm pretty sure. My solution is easy, install Julia under WSL. In fact, after moving from MacOS to Windows, this is my goto solution: install as much as I can under WSL.

Problem disappeared.