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

161–170 of 224 posts

Re: Julia 1.6 Highlights

#161

Post by socialdemocrat »

machineko wrote: post #36
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

I think i can answer that, first of all Julia isnt as fast as C/C++/Nim etc. in most cases Julia is just fast in scientific computing that's all. (there is only one "scientific" benchmark on kostya benchmarks) 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. And all people writing this benchmark is measuring compilation time (XD?) o…

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

Re: Julia 1.6 Highlights

#162

Post by neolog »

StefanKarpinski wrote: post #129
fermienrico wrote: post #84

Earlier quoted context omitted.

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…

When I wrote that I was under the impression that the brainfuck interpreter implementations were the only benchmarks in the repo. There are, however (I now realize), also benchmarks for base64 decoding, JSON parsing, and writing your own matmul (rather than calling a BLAS matmul, which is not generally recommended), so this is more reasonable than I thought but still a somewhat odd collection of tasks to benchmark. O…

I'm a daily Julia user but tbh I've gotta agree with parent commenter. I think Jeff's attitude in the "What's bad about Julia" talk is the right way to handle criticism: listen to the person, ask about their use cases, understand how Julia could be improved for that user. Accepting criticism makes a good product, and seeing project leaders do it makes a good impression.

Re: Julia 1.6 Highlights

#163

Post by snicker7 »

machineko wrote: post #36
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

I think i can answer that, first of all Julia isnt as fast as C/C++/Nim etc. in most cases Julia is just fast in scientific computing that's all. (there is only one "scientific" benchmark on kostya benchmarks) 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. And all people writing this benchmark is measuring compilation time (XD?) o…

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

Re: Julia 1.6 Highlights

#164

Post by systems »

socialdemocrat wrote: post #160
systems wrote: post #80

Earlier quoted context omitted.

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

Seems like a reasonable trade off to me. The previous behavior was just really annoying in practice.

its an exceptional behaviour, its a code smell, good code, should try to make exceptions normal

its a very poor design they don't have variable declaration, and they have to go head over heels to provide acceptable behaviour

anyway, it is a bad thing in the language, lets not defend it (i hope)

julia still have a lot to offer, i guess it can afford one design flaw

Re: Julia 1.6 Highlights

#165

Post by StefanKarpinski »

neolog wrote: post #159
StefanKarpinski wrote: post #101

Earlier quoted context omitted.

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

> 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). How possible would it be for Julia to add this? I keep thinking Julia would be great for graphical environments and gaming, but high GC latency won't work there.

Very doable, “just” a bunch of moderately tricky compiler work. Will happen at some point. Things that would make it happen sooner: someone interested in compiler work decides to do it; some company decides to fund it.

Re: Julia 1.6 Highlights

#166

Post by StefanKarpinski »

neolog wrote: post #162
StefanKarpinski wrote: post #129

Earlier quoted context omitted.

When I wrote that I was under the impression that the brainfuck interpreter implementations were the only benchmarks in the repo. There are, however (I now realize), also benchmarks for base64 decoding, JSON parsing, and writing your own matmul (rather than calling a BLAS matmul, which is not generally recommended), so this is more reasonable than I thought but still a somewhat odd collection of tasks to benchmark. O…

I'm a daily Julia user but tbh I've gotta agree with parent commenter. I think Jeff's attitude in the "What's bad about Julia" talk is the right way to handle criticism: listen to the person, ask about their use cases, understand how Julia could be improved for that user. Accepting criticism makes a good product, and seeing project leaders do it makes a good impression.

Not my best but as I said, I was genuinely confused about the benchmarks.

Re: Julia 1.6 Highlights

#167

Post by tfehring »

ku-man wrote: post #54
cbkeller wrote: post #41

Earlier quoted context omitted.

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 forgot to mention that a 'Hello World' standalone file is about 0.5 GB!

I think something to that effect was implicit in "the bundle itself includes a Julia runtime," but I vouched for this comment anyway since it's an important limitation and the parent comment evidently wasn't explicit enough to prevent confusion.

Re: Julia 1.6 Highlights

#168

Post by pansa2 »

tfehring wrote: post #167
ku-man wrote: post #54

Earlier quoted context omitted.

You forgot to mention that a 'Hello World' standalone file is about 0.5 GB!

I think something to that effect was implicit in "the bundle itself includes a Julia runtime," but I vouched for this comment anyway since it's an important limitation and the parent comment evidently wasn't explicit enough to prevent confusion.

Elsewhere someone says “Fib was around 44kb with no runtime required”. Which is correct?

Re: Julia 1.6 Highlights

#169

Post by c-cube »

odipar wrote: post #118
StefanKarpinski wrote: post #101

Earlier quoted context omitted.

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

Thanks for the reply! Unfortunately, persistent data structures tend to produce (short-lived) garbage which the JVM is very good at collecting! So yes, Clojure benefits immensely from the JVM. It is also an interesting research topic whether (optimised) reference counting would be a better approach. Regarding objects, there is also a "middle ground" to consider: Split big (immutable) arrays in smaller ones, connect t…

About the refcounting approach, you may want to look at the Perceus paper. It's refcounting with dynamic reuse of memory that isn't shared (like a sort of runtime linear typing), and it's used in Koka for functional programming.

Re: Julia 1.6 Highlights

#170

Post by stellalo »

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

That’s interesting: did you use Flux?
Post reply on HN