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

131–140 of 224 posts

Re: Julia 1.6 Highlights

#131

Post by CyberDildonics »

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…

Don't be ridiculous. If someone puts emphasis on nonsense, dismissing it is reasonable.

Re: Julia 1.6 Highlights

#132

Post by StefanKarpinski »

pron wrote: post #122
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 —…

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

Has a version of Java with value types been released?

Re: Julia 1.6 Highlights

#133

Post by the_duke »

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.

Did you try a manual git clone to rule out any network or FS issues?

Re: Julia 1.6 Highlights

#135

Post by 00117 »

krastanov wrote: post #12
f6v wrote: post #9

Is there a per-project way to manage dependencies yet? I find global package installation to be the biggest weakness of all the R projects out there. Anaconda can help, but it’s not widely used for R projects. And Docker... well, don’t get me started.

I might be misunderstanding your question, but this post is about Julia, not R. Julia has a pretty great per-project dependency management.

Julia is a competitor of R, hence the comparison.

Re: Julia 1.6 Highlights

#136

Post by pron »

StefanKarpinski wrote: post #132
pron wrote: post #122

Earlier quoted context omitted.

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

Has a version of Java with value types been released?

No, but there's finally a JEP, which normally means that release is imminent (I'm not involved with that project, so I have no inside information): https://openjdk.java.net/jeps/401

As part of this change, existing built-in primitive types (like int or double) will retroactively become instances of these more general objects.

Re: Julia 1.6 Highlights

#137

Post by bbatha »

pron wrote: post #106
StefanKarpinski wrote: post #103

Earlier quoted context omitted.

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

Go has only concurrency of the features you talk about but is often competitive with Java in benchmarks. In my experience I’ll take administration of go processes any day of the week over Java — I’ve lost count of the number of hours lost to debugging gc stalls, runaway heaps and other garbage collector related issues never once had those problems in go.

Go even reverted a generational collector because it had no performance benefits since most generational objects would be stack allocated anyway — Julia’s JIT and way more advanced llvm backend should do even better than go in keeping objects stack local and inline.

Re: Julia 1.6 Highlights

#138

Post by stabbles »

komuher wrote: post #51
cygx wrote: post #48

Earlier quoted context omitted.

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…

If u cant even read code dont lie xD n = length(ARGS) > 0 ? parse(Int, ARGS[1]) : 100 left = calc(101) # 0.1 println(stderr, "$(left) != $(right)") exit(1) end notify("Julia (no BLAS)\t$(getpid())") t = time() results = calc(n) elapsed = time() - t notify("stop")

not sure why this was downvoted to oblivion, as it seems to be correct

Re: Julia 1.6 Highlights

#139

Post by pron »

bbatha wrote: post #137
pron wrote: post #106

Earlier quoted context omitted.

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

Go has only concurrency of the features you talk about but is often competitive with Java in benchmarks. In my experience I’ll take administration of go processes any day of the week over Java — I’ve lost count of the number of hours lost to debugging gc stalls, runaway heaps and other garbage collector related issues never once had those problems in go. Go even reverted a generational collector because it had no per…

It's competitive in pretty forgiving benchmarks. And LLVM is way more advanced than Go's compiler, but not OpenJDK's. I'm not saying you have to prefer Java to Go, but its throughput is better. As to the stack-allocation claim, young generations might be hundreds of MBs; that might correspond to the stacks of 100K goroutines on some server workloads, but not of a few threads.

So I'm not saying you must prefer Java to Go (even though GC tuning is a thing of the past as of JDK 15 or 16), or that Go's performance isn't adequate for many reasonable workloads, only that 1. a flatter object landscape might still not match Java's memory management performance without sophisticated GCs, and 2. I wouldn't extrapolate from Go to Julia, as they are languages targeting very different workloads. E.g. Julia might well prefer higher throughput over lower latency, and Go's GC's throughput is not great.

Re: Julia 1.6 Highlights

#140

Post by detaro »

stabbles wrote: post #138
komuher wrote: post #51

Earlier quoted context omitted.

If u cant even read code dont lie xD n = length(ARGS) > 0 ? parse(Int, ARGS[1]) : 100 left = calc(101) # 0.1 println(stderr, "$(left) != $(right)") exit(1) end notify("Julia (no BLAS)\t$(getpid())") t = time() results = calc(n) elapsed = time() - t notify("stop")

not sure why this was downvoted to oblivion, as it seems to be correct

presumably because of the tone.
Post reply on HN