Live data from Hacker News

Julia 1.6 Highlights

julialang.org

61–70 of 224 posts

Re: Julia 1.6 Highlights

#61
post #43

I've been running the 1.6 release candidates, and the compilation speed improvements have been massive. There have been plenty of instances in the past where I've tried to 'quickly' show off some Julia code, and I end up waiting ~45 seconds for a plot to show or a minute for a Pluto notebook to run, and that's not to mention waiting for my imports to finish. It's still slower than Matlab for the first run, but it's a…

What kind of speed do you see now?

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.

Re: Julia 1.6 Highlights

#63

Earlier quoted context omitted.

Sorry for the inconvenience and thanks for the advice. We'll do our best to ensure this doesn't happen again.

You guys are doing great. Julia is really taking shape. Can't wait to jump ship from Python. It's also nice to see that you (personally) are sponsoring zig development. There is so much more room for improvement in the arena of programming languages. Infrastructure like this is a huge multiplier.

I'm excited about Zig and I've spent many evenings looking at Andrew's streams. I haven't gotten the time to try it out properly myself but I'm looking forward to it.

Re: Julia 1.6 Highlights

#64
post #48

Earlier quoted context omitted.

I'm not a huge Julia user, but typically if they don't specifically mention they're segmenting runtime from compilation time with Julia, that's a bit of a red flag, because unlike Rust, Go, or C++ the compilation step isn't separate in Julia. To the user it just looks like it's running, when in reality it's compiling, then running, without really letting you know in between.

In the matrix multiplication example, the measurement is done via a simple t = time() results = calc(n) elapsed = time() - t So startup time at least isn't included. One might argue that this is still biased against Julia due to its compilation strategy, but fixing that would mean you'd have to figure out what the appropriate way to get 'equivalent' timings for any of the other languages would be as well - something…

The problem is a minor placement issue for the `@simd` macro: https://github.com/kostya/benchmarks/pull/317

Re: Julia 1.6 Highlights

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

Re: Julia 1.6 Highlights

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

I didn't even know julia GC had issues. Care to elaborate?

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.

Re: Julia 1.6 Highlights

#67

Earlier quoted context omitted.

I didn't even know julia GC had issues. Care to elaborate?

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

Ouch.

Re: Julia 1.6 Highlights

#68

How easy it is to produce a compiled executable in 1.6? I took a cursory look at the docs but couldn't spot the steps for doing so.

That's coming. Pieces are there but still need polish and integration. Fib was around 44kb with no runtime required. Check out staticcompiler.jl

In your experience, what are the current limitations?

Re: Julia 1.6 Highlights

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

A low-latency GC would also be great. But again, the JVM only has that due to many millions of dollars spent over decades.

Re: Julia 1.6 Highlights

#70

Earlier quoted context omitted.

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

Ouch.

I mean I’m not trying to hate on Java — pointer-heavy programming was all the rage when it was designed, and GC was a hot research topic, so there was good reason to be optimistic about that approach. But it turns out that it’s very hard to make up for generating tons of garbage and pointer-heavy programming hasn’t aged well given the way hardware has evolved (pointers are large and indirection is expensive).
Post reply on HN