simondanisch

>The purpose of multiple dispatch is extensibility, but the purpose of pattern matching is destructuring.

Agreed! ;) Just wanted to point out, that I was able to use multiple dispatch elegantly in the unroll example, where you are using pattern matching.

>pattern matching compiles down to those low level operations

So I guess that means Julia could indeed satisfy you, if we gave those low level operations some more syntactic sugar? Have you seen: http://kmsquire.github.io/Match.jl/latest/ ?

>Let me just say that it is really difficult to know ahead of time how a particular language feature would affect your programming life

True story. I'll try to be more observant when writing code and see, if I could actually solve things more elegantly with better pattern matching.

Btw, I'm writing on an article about GPU programming in Julia - do you have feature you'd like to have explained, or a killer feature you believe we can't do and that would impress you if we did?

>You can in fact get loop unrolling with just standard functions in Spiral.

We can do this too actually - and spirals approach sounds very similar to what you'd do in julia :)

https://gist.github.com/SimonDanisch/812e01d7183681ed414932c...

As a matter of fact, it's what the compiler devs keep recomending. As a developper I must say, that it's pretty relaxing to take a meta programming shortcut from time to time ;) In general, we plan to offer a tool box that employs these kind of patterns for loop unrolling, tiling etc, to make it easier to write GPU code without meta programming and perform certain optimizations/scheduling patterns based on a more trait like system.

> Also reflection should be done using pattern matching

I feel like what Julia does is just more low level right now - And you get pretty far with just multiple dispatch! If we needed more than that, we could put the effort into extending the language into that direction. But I think your use cases must get be pretty advanced untill you need something more complex. Can you recommend a nice article that shows off beautiful pattern matching for reflection? I see how it sounds nice, but I can't really imagine right now how it would improve my life.

Concerning inlining, I do think we actually force codegen to always inline when compiling for the GPU. I don't remember a 100% anymore, but there might have been some problems with that. But it's definitely the goal, to have a flexible compiler that you can fine tune to specific domains like GPU programming. And if we don't get it as part of the compiler, we can definitely do things like that with https://github.com/jrevels/Cassette.jl/

Appart from that, I'm pretty happy that our GPU compilation infrastructure isn't making Julia less useful as a general purpose language ;)

>Is it fully integrated or is it a wrapper style memory management?

It's wrapper style. We're playing around with different kind of hacks to make it less worse, but those are hacks you could do in any GC language. The good news is, that the Julia compiler devs take GPU computing seriously and promised to work on a full integration that is aware of the GPU hardware.

>GPU programming without macros looks like then take a peek at this:

I'm not sure if you missed my examples, or if there is some other missunderstanding going on ;)

GPU code in Julia works 100% without macros, but you are free to use them, so people do ;) Also, you can pretty much write the gpu kernels like pseydo code, not sure how much simpler it can get.

With your linked spiral code, I can't even really tell where the algorithm starts and where the setup code ends - which of course might easily be attributed to my unfamiliarity with Spiral ;)

I wrote an article some time ago about generic programming with Julia's gpu infrastructure:

https://techburst.io/writing-extendable-and-hardware-agnosti...

If you can make concrete examples of how things can be simpler than this, I'd be delighted to hear them :)

Cuda only (for no reason actually) and with lots of macros, here is another article about gpu programing in Julia: https://mikeinnes.github.io/2017/08/24/cudanative.html

Do you have any benchmarks for the softmax kernel? If that kernel has optimal performance, it would be quite interesting. If it's sup par, it looks much longer than a simple version.

On Julia 0.7, the broadcast kernel will look much more like this (and actually the version used in CuArrays/CLArrays currently also doesn't use those macros):

https://github.com/jrevels/MixedModeBroadcastAD.jl/blob/mast...

let I = @cuda_index(shape)

    @inbounds dest[I] = bc[I]

end

There are several things to point out here:

1) The macro @cuda_index doesn't really need to be a macro, but like this it's the shortest way to check the index and return when out of range (in CUDA/OpenCL you often need to schedule a loop with more iterations than you need).

2) the `dest[I] = bc[I]` does all the unzipping of arguments and dispatch to the correct fast getindex for a certain layout of dest/bc via the type system + tuples of the arguments (not using C-style varargs). This simple function makes it possible to get all the advantages of julia's lazy fused broadcasting to work.

Feel free to checkout this great blog article to see what's possible with the new lazy broadcasting:

https://julialang.org/blog/2018/05/extensible-broadcast-fusi...

You can also look directly at the broadcasting code in Julia Base, which is already a bit bloated to deal with lots of edge cases, but is still pretty readable in parts:

https://github.com/JuliaLang/julia/blob/master/base/broadcas...

The problem is still with apple forcing them to invest resources, without any reason, but to advance their vendor lock in. And if you're a developper of a small high performance 3d graphics and gpu computing library like me, its just a giant middle finger from apple and I will either need to drop opengl/opencl or apple - there is no way that i can afford to offer both, especially since i'd need to buy apple hardware to test things.

I wouldn't say so. Cython is quite literally C for python, basically making all your python code look like C with most disadvantages, while not always reaching C performance.

Julia in comparison is a fully featured language, with a lot to offer - you can write highly generic + fast code in a very high-level way. E.g. have a look at https://medium.com/@Jernfrost/defining-custom-units-in-julia... You can see, that Julia can be more elegant than python while being a lot faster.

>type that explicitly recides on GPU

Yes, that's what we do! More domain specific types will come, for e.g. views, lazy arrays and sparse arrays.

> or does it manage the device state?

It aims to manage most of the device state! Some more complex gpu interactions will need to drop back to manual management, though - but the hope is to turn more and more into a high level API when needed!

First of all, Julia is a proper multi purpose programming language! I consider that to be important, since I want to learn one language and then do most of my very different projects in it.

I haven't used Futhark or Halide, but I know they do some quite interesting compiler optimization.

We plan to use Julia's meta programming and code generation capabilities to enable similar optimizations. Hopefully, we can publish some new insights soon!

From a look at Halides and Futharks examples, I'd say that it will be more pleasant to write generic Julia GPU kernels and Julia enables a more interactive workflow.

Yeah and there is already an improvement to that: https://github.com/JuliaLang/julia/pull/12541. Well, anyways, I think you can easily find a lot of unsatisfactory constructs in any language, especially in young ones ;) If they outweigh the advantages is debatable. So far I've been finding satisfactory workarounds for the most daring issues, so for me the conclusion is indeed very positive.

deployment + load times: obviously things aren't perfect, Julia is at version 0.4, after all ;) There are a lot of low hanging fruits for compile time and deployment, so I'm sure that the situation will look a lot different in a year or two.

I'm not sure why Julia itself should make it difficult to "do the right thing" when exceptions occur...

Real-time 3D rendering is a big area. Will we have virtual reality with ultra low latency in the next year? Definitely not! Can we have 3D CAD/scientific visualizations which hardly stutters? Definitely! Our library is already very smooth and we didn't even start optimizing yet. That's something that seems to be almost impossible in e.g Python (without just calling C for everything).

So while most of these arguments are currently spot on, I do think that there is nothing fundamentally wrong with Julia. And while the maturity is not there yet, you can already be very productive with Julia and build for the future.

Can you explain why you couldn't write a 3D renderer or complex gui in Julia? As someone who does exactly that it's a bit hard to follow your reasoning...