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

151–160 of 224 posts

Re: Julia 1.6 Highlights

#151

Post by BlackFingolfin »

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""" >++[ -…

This is really cool!

But note that OP uses larger cells (`int` = 32 bit in the C version, `Int` = 64 bit in the Julia version) while GalaxyBrain seems to use 8 bit cells. Not that I expect this to make a major difference (but perhaps a minor one?)

Re: Julia 1.6 Highlights

#152

Post by cbkeller »

eigenspace wrote: post #100
fiddlerwoaroof wrote: post #95

Earlier quoted context omitted.

It’s not true that CLOS generic dispatch is slow: Robert Strandh and other have done a bunch of work showing that it’s possible to implement it efficiently without giving up the dynamic redefinition features that make CLOS such a nice system. There’s at least one video game project (Kandria) that’s been funding an implementation of these ideas so that generic functions can be used in a soft real-time system like a vi…

Yes, I don't doubt at all that it's possible to make CLOS dispatch fast. What I'm saying is that because historically people using CLOS had to pay a (often negligible) runtime cost for dispatch, it limited the number of places developers were willing to allow generic dispatch. Julia makes the runtime cost of (type stable) dispatch zero, and hence does not even give julia programmers an *option* to write non-generic f…

In this context, I think there might be an argument to be made that Julia is to multiple dispatch (or multiple dispatch + JAOT) as the iPhone is to “touchscreen computers that can make phone calls”.

It’s not that it’s the first, but it seems to be the first where the use of multiple dispatch throughout the community was sufficiently pervasive to kick-start the emergence of the strong network effects we’re now seeing w/r/t composability.

I would not be surprised to see more languages working to emulate this kind of combination of multiple dispatch and JAOT compilation in the future.

Re: Julia 1.6 Highlights

#153

Post by adgjlsfhk1 »

StefanKarpinski wrote: post #134
adgjlsfhk1 wrote: post #130

Earlier quoted context omitted.

fyi, I'm oscardssmith on most other channels.

Hi, Oscar! Nice user name :P

It's my backup username discovered when I was 10 or so, and I wanted something that wasn't my name and would be available everywhere.

Re: Julia 1.6 Highlights

#154

Post by patagurbon »

eigenspace wrote: post #120
triztian wrote: post #112

Earlier quoted context omitted.

I'd love to be able to contribute to this, somewhat new to Julia, but I'm sure I could help with something ... Do you have any links to what has been currently done? EDIT: Found this thread so far: https://discourse.julialang.org/t/statically-compiled-and-st...

This is the PR to look at if you want to try and help: https://github.com/tshort/StaticCompiler.jl/pull/46 I think this isn't really a great place for beginners though unfortunately. This project is tightly coupled to undocumented internals of not only julia's compiler, but also LLVM.jl and GPUCompiler.jl. It'll require a lot of learning to be able to meaningfully contribute at this stage.

Where do you recommend an experienced Julia user start working on internals/core tools?

Re: Julia 1.6 Highlights

#155

Post by Tarrosion »

eigenspace wrote: post #85
superdimwit wrote: post #68

Earlier quoted context omitted.

In your experience, what are the current limitations?

There's all sorts of limitations right now. E.g. you can't allocate an array right now, dynamic dispatch is prohibited, there are some bugs too. Most of this is just a relic from StaticCompiler.jl being a very straightforward slight repurposing of GPUCompiler.jl. It will take some work to make it robust on CPU code, but the path to doing so it pretty strightforward. It just requires dedicated work, but it's not a top…

What's the difference between StaticCompiler.jl and PackageCompiler.jl? Doesn't the latter also let you build "apps"?

Re: Julia 1.6 Highlights

#156

Post by socialdemocrat »

skohan wrote: post #72
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!

What does it mean exactly? Or what is novel here?

The combination. E.g multiple dispatch without JIT would be really slow as you are picking a method to run at runtime based on the type of all the function arguments.

That requires a linear search through a list of all possible combinations of input arguments.

In a single dispatch language like most object oriented languages, you can do a simple dictionary/hash table lookup. Much faster.

With the JIT Julia is able the optimize away most of these super slow lookups at runtime. Hence you get multiple dispatch for all functions but with fantastic performance. Nobody had done that before.

Re: Julia 1.6 Highlights

#157

Post by Buttons840 »

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, the network evaluations and gradient calculations and applications, and PyTorch and Julia performed similar here. So it wasn't that Julia was faster at learning. Instead it was all the in-between, all the "book keeping" in Python ended up being much faster in Julia, enough so that overall it was 2 to 3 times faster.

(I was training on a CPU though. Things may be different if you're using a GPU, I don't know.)

Re: Julia 1.6 Highlights

#158

Post by otde »

BlackFingolfin wrote: post #151
otde wrote: post #87

Earlier quoted context omitted.

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""" >++[ -…

This is really cool! But note that OP uses larger cells (`int` = 32 bit in the C version, `Int` = 64 bit in the Julia version) while GalaxyBrain seems to use 8 bit cells. Not that I expect this to make a major difference (but perhaps a minor one?)

The real issue is that the original brainfuck spec (as given by the Wikipedia entry) explicitly sets the sizes of each cell to a single byte —- which means many of the interpreters used for this benchmark are using incorrect cell sizes!

Re: Julia 1.6 Highlights

#159

Post by neolog »

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

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

Re: Julia 1.6 Highlights

#160

Post by socialdemocrat »

systems wrote: post #80
StefanKarpinski wrote: post #55

Earlier quoted context omitted.

Has been fixed since 1.5.

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.
Post reply on HN