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

111–120 of 224 posts

Re: Julia 1.6 Highlights

#111

Post by eigenspace »

siproprio wrote: post #105
MisterBiggs wrote: post #61

Earlier quoted context omitted.

No idea if this is really a fair comparison but just to get a brief idea of current speeds: julia> @time let using Plots plot([sin, cos]) end 11.267558 seconds (17.98 M allocations: 1.114 GiB, 4.83% gc time) Versus Matlab which probably takes about 15 seconds just to open the editor but plotting is very fast. >> tic fplot( @(x) [sin(x) cos(x)]) toc Elapsed time is 0.374394 seconds. Julia is just about as fast as Matl…

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

Re: Julia 1.6 Highlights

#112

Post by triztian »

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…

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

Re: Julia 1.6 Highlights

#113

Post by eigenspace »

triztian wrote: post #109
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.

Thank you for your reply! PackageCompiler looks like the right way. Do you happen have any links to the static binary procedure? Or links to the current state of efforts for this?

https://github.com/tshort/StaticCompiler.jl/pull/46

Re: Julia 1.6 Highlights

#114

Post by iib »

pjmlp wrote: post #78
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!

I advise you to check Common Lisp CLOS and Dylan.

Wikipedia has a nice table [1] on the Multiple Dispatch page, that describes one studies' findings about the use of multiple dispatch in languages supporting it, in practice.

Although CLOS and others do support it, Julia seems to take the cake by most metrics, highlighting that it is a core paradigm of the language, more so than in the others.

Re: Julia 1.6 Highlights

#115

Post by akdor1154 »

snicker7 wrote: post #6

On the package ecosystem side, 1.6 is required for JET.jl [0]. Despite being a dynamic language, the Julia compiler does a lot of static analysis (or "abstract interpretation" in Julia lingo). JET.jl exposes some of this to the user, opening a path for additional static analysis tools (or maybe even custom compilers). [0]: https://github.com/aviatesk/JET.jl

Good gracious, thanks for this. If JET goes anywhere, then that+other goodies in 1.6 mean I will likely switch back from Python+mypy.

Re: Julia 1.6 Highlights

#117

Post by celrod »

ChrisRackauckas wrote: post #98
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…

That's a major oversimplification. GC is good for ease of use and safety of a high level language. GC is never as performant as not requiring heap allocations at all. Julia has a GC, but also provides a lot of tools to avoid needing the GC in high performance computations. This combination gives ease of use and performance. Java sacrifices some performance for having this "one paradigm" of all objects, and then heavi…

To tie Octavian.jl into this memory allocation discussion:

Octavian uses stack-allocated temporaries when "packing" left matrix ("A" in "A*B"). These temporaries can have tens of thousands of elements, so that's a non-trivial stack allocation (the memory is mutable to boot). No heap allocations or GC activity needed (just a GC.@preserve to mark its lifetime). If I understand correctly, this isn't something that'd be possible in Java?

To be fair, you can also just use preallocated global memory for your temporaries, since the maximum amount of memory needed is known ahead of time.

Re: Julia 1.6 Highlights

#118

Post by odipar »

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

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 them with some pointers in between, and you are still cache friendly.

Also, you can do a lot on the application level to reduce garbage, and most Java programmers don't care for that exactly because of JVM.

Re: Julia 1.6 Highlights

#119

Post by siproprio »

StefanKarpinski wrote: post #116
siproprio wrote: post #107

On 1.6, I tried "] add Plots" and julia got stuck.

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"

Re: Julia 1.6 Highlights

#120

Post by eigenspace »

triztian wrote: post #112
eigenspace wrote: post #85

Earlier quoted context omitted.

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…

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.

Post reply on HN