Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 Highlights

julialang.org

Post reply on HN
Print view View original

101–110 of 224 posts

Re: Julia 1.6 Highlights

#101

Post by StefanKarpinski »

odipar wrote: post #76
StefanKarpinski wrote: post #70

Earlier quoted context omitted.

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).

so are you for GC or against GC? In other posts you actually argue that GCs help you reduce complexity because manual memory management is too much of a hassle. May be immutable is not the correct term - persistent data structures is what I like support for: that is my use-case. I think you can have efficient persistent data structures without a GC, but that requires fast reference counting and in turn, that requires…

I love GC — it solves a ton of nasty problems in a programming language design with a single feature that users mostly don't have to worry about. Just because you have a GC, however, doesn't mean that it's a good idea to generate as much garbage as you can — garbage collection isn't free. That's where Java IMO went wrong. Java's design — objects are and subtypeable (by default) and mutable with reference semantics — generates an absolute epic amount of garbage. It seems like the hope was that improvements in GC technology would make this a non-issue in the future, but we're in the future and it hasn't turned out that way: even with vast amounts of money that have been spent on JVM GCs, garbage is still often an issue in Java. And this has given GC in general a bad name IMO quite unfairly. It just happens that Java simultaneously popularized GC and gave it a bad name by having a design that made it virtually impossible for the GC to keep up with the amount of garbage that was generated.

It is entirely possible to design a garbage collected language that doesn't generate so goddamned much garbage — and this works much, much better because a relatively simple GC can easily keep up. Julia and Go are good examples of this. Julia uses immutable types extensively and by default, while Go uses value semantics, which has a similar effect on garbage (but has other issues). With a language design that doesn't spew so much garbage, if you only care about throughput, a relatively simple generational mark-and-sweep collector is totally fine. This is what Julia has. If you also want to minimize GC pause latency, then you need to get fancier like Go (I think they have a concurrent collector that can be paused when it's time slice is up and resumed later).

Persistent data structures are a whole different question that I haven't really spent much time thinking about. Clojure seems to be the state of the art there but I have no idea if that's because of the JVM or despite it.

Re: Julia 1.6 Highlights

#102

Post by odipar »

ChrisRackauckas wrote: post #98
odipar wrote: post #76

Earlier quoted context omitted.

so are you for GC or against GC? In other posts you actually argue that GCs help you reduce complexity because manual memory management is too much of a hassle. May be immutable is not the correct term - persistent data structures is what I like support for: that is my use-case. I think you can have efficient persistent data structures without a GC, but that requires fast reference counting and in turn, that requires…

That's a major oversimplification. GC is good for ease of use and safety of a high level language. GC is never as performant as not requiring heap allocations at all. Julia has a GC, but also provides a lot of tools to avoid needing the GC in high performance computations. This combination gives ease of use and performance. Java sacrifices some performance for having this "one paradigm" of all objects, and then heavi…

I like your response, and yes, it was a major oversimplification and I'm sorry for that.

Indeed, it is always about design choices and trade-offs. I can see why BLAS code is important and why Julia is an optimal choice for computation heavy problems.

Re: Julia 1.6 Highlights

#103

Post by StefanKarpinski »

pron wrote: post #96
StefanKarpinski wrote: post #70

Earlier quoted context omitted.

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).

You're mixing two things here: memory management and memory layout. This "pointer-heavy programming" is, indeed, a bad fit for modern hardware in terms of processing speed due to cache misses, which is why even Java is now getting user-defined primitive types (aka inline types, aka value types), but in terms of memory management, in recent versions OpenJDK is pretty spectacular, not only in throughput but also latenc…

I'm not — memory layout and memory management are (fairly obviously, I would think) intimately related. In particular, pointer-heavy memory layouts put way more stress on the garbage collector. Java's choice of making objects mutable, subtypeable and have reference semantics, basically forces them to be individually heap-allocated and accessed via pointers. On the other hand, if you design your language so that you can avoid heap allocating lots of individual objects, then you can get away with a much simpler garbage collector. Java only needs spectacular GC technology because the language is designed in such a way that it generates a spectacular amount of garbage.

Re: Julia 1.6 Highlights

#104

Post by JulianMorrison »

mbauman wrote: post #99
JulianMorrison wrote: post #81

BTW, broken link on the documentation page, "The documentation is also available in PDF format: julia-1.6.0.pdf." No it isn't.

Thanks for the report: https://github.com/JuliaLang/julia/issues/40190 Edit: it's now building: https://github.com/JuliaLang/docs.julialang.org/runs/2196972...

Much appreciated.

Re: Julia 1.6 Highlights

#105

Post by siproprio »

MisterBiggs wrote: post #61
Sukera wrote: post #43

Earlier quoted context omitted.

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 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"

Re: Julia 1.6 Highlights

#106

Post by pron »

StefanKarpinski wrote: post #103
pron wrote: post #96

Earlier quoted context omitted.

You're mixing two things here: memory management and memory layout. This "pointer-heavy programming" is, indeed, a bad fit for modern hardware in terms of processing speed due to cache misses, which is why even Java is now getting user-defined primitive types (aka inline types, aka value types), but in terms of memory management, in recent versions OpenJDK is pretty spectacular, not only in throughput but also latenc…

I'm not — memory layout and memory management are (fairly obviously, I would think) intimately related. In particular, pointer-heavy memory layouts put way more stress on the garbage collector. Java's choice of making objects mutable, subtypeable and have reference semantics, basically forces them to be individually heap-allocated and accessed via pointers. On the other hand, if you design your language so that you c…

I would say no. To have stellar performance, you'll need compaction, you'll need parallelism (of GC threads), and you'll need concurrency between the GC threads and mutator threads; and for good throughput/footprint tradeoff you'll need generational collection. True, you might not need to contend with allocation rates that are that high, but getting, say, concurrent compaction (as in ZGC) and/or partial collections (as in G1), requires a sophisticated GC. E.g. Go isn't as pointer-heavy as (pre-Valhalla) Java, and its GC is simple and offers very good latency, but it doesn't compact and it throttles, leading to lower throughput (I mean total program sluggishness) than you'd see in Java, even with a much higher allocation rate. The thing is that even with a low allocation rate, you'd get some challenging heaps, only later, say, every 10 seconds instead of every 5.

It's true that a simpler GC might get you acceptable performance for your requirements if your allocation rate is relatively low, but you still won't get OpenJDK performance. So I'd say that if you design your language to require fewer objects, then you can get by with a simple GC if your performance requirements aren't too demanding.

All that dereferencing puts a higher load on data structure traversal (which is why Java is getting "flattenable" types) than on the GC. The main reason for Java's particular GC challenges isn't its pointer-heavy (pre-Valhalla) design but the mere fact that it is the GCed platform that sees the heaviest workloads and most challenging requirements by far. Java's GC needs to work hard mostly for the simple reason that Java is asked to do a lot (and the better some automated mechanism works, the more people push it).

Re: Julia 1.6 Highlights

#108

Post by StefanKarpinski »

ChrisRackauckas wrote: post #98
odipar wrote: post #76

Earlier quoted context omitted.

so are you for GC or against GC? In other posts you actually argue that GCs help you reduce complexity because manual memory management is too much of a hassle. May be immutable is not the correct term - persistent data structures is what I like support for: that is my use-case. I think you can have efficient persistent data structures without a GC, but that requires fast reference counting and in turn, that requires…

That's a major oversimplification. GC is good for ease of use and safety of a high level language. GC is never as performant as not requiring heap allocations at all. Julia has a GC, but also provides a lot of tools to avoid needing the GC in high performance computations. This combination gives ease of use and performance. Java sacrifices some performance for having this "one paradigm" of all objects, and then heavi…

I don't know that the object model is why writing a BLAS in Java doesn't make sense. After all they special case `float` and `double` as primitives, which bifurcates the whole type system and is its own whole issue, but means that you can store them efficiently inline. I'm actually not sure what stops someone from writing a BLAS in Java except that it would be hard and there's no point.

Re: Julia 1.6 Highlights

#109

Post by triztian »

cbkeller wrote: post #41
triztian wrote: post #37

Earlier quoted context omitted.

I’ve also looked for this, does it mean that I have to install julia on the target machine and it’ll recompile when running? Or are there steps to produce a binary (much like Go or C or Rust)??

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.

Thank you for your reply! PackageCompiler looks like the right way.

Do you happen have any links to the static binary procedure? Or links to the current state of efforts for this?

Re: Julia 1.6 Highlights

#110

Post by StefanKarpinski »

adgjlsfhk1 wrote: post #74
newswasboring wrote: post #57

Earlier quoted context omitted.

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

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.

This is very legit issue that the compiler team has their eye on and plans to work on.
Post reply on HN