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

121–130 of 224 posts

Re: Julia 1.6 Highlights

#121

Post by StefanKarpinski »

otde wrote: post #87
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 this particular Julia code is pretty misleading, and I'm (probably) one of the most qualified people in this particular neck of the woods. I wrote a transpiler for Julia that converts a Brainfuck program to a native Julia function at parse time, which you can then call like you would any other julia function. Here's code I ran, with results: julia> using GalaxyBrain, BenchmarkTools julia> bench = bf""" >++[ -…

I love the Julia community

Re: Julia 1.6 Highlights

#122

Post by pron »

StefanKarpinski wrote: post #101
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…

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

> garbage is still often an issue in Java.

Not anymore. That future is here. Java is getting "flattenable" types not because of GC, but because of iteration.

Re: Julia 1.6 Highlights

#123

Post by siproprio »

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"

> (@v1.6) pkg> add Plots Installing known registries into `~\.julia` Cloning registry from "https://github.com/JuliaRegistries/General.git" Fetching: [==> ] 3.4 %

I gave up because it's just too slow (more than 15 min to get to 3%).

Maybe plotting is indeed faster, but I don't think I'll actually get to that point.

Re: Julia 1.6 Highlights

#124

Post by siproprio »

eigenspace wrote: post #111
siproprio wrote: post #105

Earlier quoted context omitted.

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

I believe that's still not going to capture the startup time of Matlab itself, right?

It's faster than opening the editor, though.

Re: Julia 1.6 Highlights

#125

Post by 3JPLW »

siproprio wrote: post #123
siproprio wrote: post #119

Earlier quoted context omitted.

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"

> (@v1.6) pkg> add Plots Installing known registries into `~\.julia` Cloning registry from " https://github.com/JuliaRegistries/General.git " Fetching: [==> ] 3.4 % I gave up because it's just too slow (more than 15 min to get to 3%). Maybe plotting is indeed faster, but I don't think I'll actually get to that point.

Is your home folder on a network drive?

Re: Julia 1.6 Highlights

#126

Post by dagw »

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"

Is this on Windows? I've experienced the same for the past few releases in Windows. For some reason that clone step is ridiculously slow.

Re: Julia 1.6 Highlights

#127

Post by siproprio »

3JPLW wrote: post #125
siproprio wrote: post #123

Earlier quoted context omitted.

> (@v1.6) pkg> add Plots Installing known registries into `~\.julia` Cloning registry from " https://github.com/JuliaRegistries/General.git " Fetching: [==> ] 3.4 % I gave up because it's just too slow (more than 15 min to get to 3%). Maybe plotting is indeed faster, but I don't think I'll actually get to that point.

Is your home folder on a network drive?

Nope.

Re: Julia 1.6 Highlights

#128

Post by siproprio »

dagw wrote: post #126
siproprio wrote: post #119

Earlier quoted context omitted.

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"

Is this on Windows? I've experienced the same for the past few releases in Windows. For some reason that clone step is ridiculously slow.

Yes.

Re: Julia 1.6 Highlights

#129

Post by StefanKarpinski »

fermienrico wrote: post #84
StefanKarpinski wrote: post #59

Earlier quoted context omitted.

This appears to be a set of benchmarks of how fast a brainfuck interpreter implemented in different programming languages is on a small set of brainfuck programs? What a bizarre thing to care about benchmarks for. Are you planning on using Julia by writing brainfuck code and then running it through an interpreter written in Julia?

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. Of course, microbenchmarks are hard — they are all fairly arbitrary and random.

In a delightful twist, it seems that there is a Julia implementation of a Brainfuck JIT that is much faster than the fastest interpreter that is benchmarked here, so even by this somewhat esoteric benchmark, Julia ends up being absurdly fast.

https://news.ycombinator.com/item?id=26585042

Re: Julia 1.6 Highlights

#130

Post by adgjlsfhk1 »

StefanKarpinski wrote: post #110
adgjlsfhk1 wrote: post #74

Earlier quoted context omitted.

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.

fyi, I'm oscardssmith on most other channels.
Post reply on HN