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

181–190 of 224 posts

Re: Julia 1.6 Highlights

#181

Post by chalst »

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!

Julia is the first language to really show that multiple dispatch can be efficient in performance-critical code, but I'm not really sure why: JIT concepts were certainly familiar to implementors of Common Lisp and Dylan.

Re: Julia 1.6 Highlights

#182

Post by chalst »

chalst wrote: post #181
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!

Julia is the first language to really show that multiple dispatch can be efficient in performance-critical code, but I'm not really sure why: JIT concepts were certainly familiar to implementors of Common Lisp and Dylan.

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.

Re: Julia 1.6 Highlights

#183

Post by kruxigt »

SatvikBeri wrote: post #28
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've rewritten two major pipelines from numpy-heavy, fairly optimized Python to Julia and gotten a 30x performance improvement in one, and 10x in the other. It's pretty fast!

I have the same experience, but make that 100x.

Re: Julia 1.6 Highlights

#184

Post by pansa2 »

newswasboring wrote: post #173
pansa2 wrote: post #168

Earlier quoted context omitted.

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

They are talking about two different systems. Static compilation is a separate project which is trying to include only those compiled code that is required. That isn't ready yet for normal people like me, but if you have the knowhow and your program meets certain requirements you can get a tiny binary. PackageCompiler.jl just compiles everything and packages it up. It generates huge files, because it doesn't discrimi…

I see, thanks. Looks like static compilation will only work if the entire program is “type stable”, which AFAICT means that the type of every variable can be deduced statically.

Re: Julia 1.6 Highlights

#185

Post by sieste »

peatmoss wrote: post #56
MisterBiggs wrote: post #14

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…

In terms of “don’t make me think about why Julia is fast but feels slow for casual use” this release is going to be a game changer. I just did a “using Plots” in 1.6.0, and it was fast enough to not care about the delta between Plots and, say, R loading ggplot. Huge kudos to the Julia team.

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!

Re: Julia 1.6 Highlights

#186

Post by RyEgswuCsn »

snicker7 wrote: post #163
machineko wrote: post #36

Earlier quoted context omitted.

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, 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 to say is that Julia is not "magically" faster than other languages. The real questions are:

1. Can unoptimised Julia code run as fast as unoptimised c/c++ code? I think the linked benchmark suggests this is not really the case.

2. Can optimised Julia code run faster than comparably (i.e. requiring similar amount of effort and expertise) optimised c/c++ code? If not, then why use Julia?

Re: Julia 1.6 Highlights

#187

Post by wiz21c »

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

Re: Julia 1.6 Highlights

#188

Post by tgv »

DNF2 wrote: post #179
tgv wrote: post #175

Earlier quoted context omitted.

Idk, but just a few weeks ago I started looking at Julia, partly because of the performance claims. I wanted to write a program a bit heavier than your average starter program, so I wrote a back-tracker (automatic layout for stripboards, to be precise). It was * interesting (not fun) to find out how Julia works * annoying AF to discover that much of the teaching material was hidden behind some 3rd party website, pres…

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

You can verify that the teaching materials are not really up to scratch. Even nim and zig, which have less resources behind them, I think, do a better job there. The manual is a reference manual, and it was difficult to find all the operations on arrays. E.g., the difference between Array{Int} and Array{Int,1} is not clarified from the start.

And as I said: I wrote a straight-forward backtracker. It just recursive function calls: check a possible state for the current item, and when successful, update the overall state and move on to the next item; on return, try another state for the current item, until the search space is exhausted. There's not a lot to optimize, nor is there a lot of work for a JIT compiler.

> on the most flimsy basis

I've got more gripes. Forward type declaration to name one. But I'm not spewing disdain: I just don't see Julia take a larger role in general software development.

Re: Julia 1.6 Highlights

#189

Post by DNF2 »

tgv wrote: post #188
DNF2 wrote: post #179

Earlier quoted context omitted.

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

You can verify that the teaching materials are not really up to scratch. Even nim and zig, which have less resources behind them, I think, do a better job there. The manual is a reference manual, and it was difficult to find all the operations on arrays. E.g., the difference between Array{Int} and Array{Int,1} is not clarified from the start. And as I said: I wrote a straight-forward backtracker. It just recursive fu…

I have no particular opinion on the teaching materials, I just use the manual and the discussion fora, so I don't know. But if a third party offers teaching materials, it's not so strange if it resides on their third party website.

As for performance, I'm not really talking about 'optimization'. Your implementation may simply have used some pattern that should be avoided, such as global variables, type instabilities, abstract types in structs, or some inappropriate data structures. If it's a microbencmhark, then there are some things to keep in mind.

These are not really optimizations, but basic performance principles. I cannot know that you are unaware of them, but your statement that 'there's not a lot to optimize' make me suspect that this could be the case. The unusual thing about Julia is that it's both dynamic and compiled, so that code that would simply not compile in static languages instead ends up slow.

Re: Julia 1.6 Highlights

#190

Post by zzleeper »

sieste wrote: post #185
peatmoss wrote: post #56

Earlier quoted context omitted.

In terms of “don’t make me think about why Julia is fast but feels slow for casual use” this release is going to be a game changer. I just did a “using Plots” in 1.6.0, and it was fast enough to not care about the delta between Plots and, say, R loading ggplot. Huge kudos to the Julia team.

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!

That was also a huge problem for me. I sometimes open Stata/R/Python/Excel, run a few snippets, and I'm done.

All four take seconds to start (or even less), and Julia felt like a huge step back in productivity.

If it's really fixed, might be good trying again.

Post reply on HN