Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Performance GPU Computing in the Julia Programming Language (2017)

devblogs.nvidia.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#51

Post by siproprio »

ddragon wrote: post #7
siproprio wrote: post #5

Earlier quoted context omitted.

In theory Julia is supposed to be fantastic. In practice, things either don't exist, or are poorly implemented: Plotting simple things take 30 seconds. And that's if you don't count the time it takes to `] add Plots`, especially on Windows! And the REPL is broken. And the editor is slow and annoying (Juno or vscode). And documentation ranges from poor (no examples, buggy between platforms, broken links due to version…

Your 1st, 2nd and 4th points seem to be fundamentally the same, which is compile time latency making interactive use slow. That's definitely a problem for a language trying to solve the two language problem of having high interactivity and high performance at the same time, and the compiler team [1] are now focusing on that issue on versions 1.4 and beyond hopefully it will get to the point where it isn't a problem a…

Nope, they are not the same points!

1. It's about compiler latency. Compiling happens when you call the function. That indeed can and should be improved.

But there are other things that contribute to the experience being shitty.

2. Is about adding a package, when adding a package it downloads all the dependencies (which includes cairo, and WinRPM on windows which all have problems of their own).

4. Is about the poor atom experience - I'm not a fan of electron apps myself - and about the slowness of the LSP on vscode, which just does not provide a good experience on vs code and things are often broken, especially on the latest versions.

If you think all these things are "compiler latency" then perhaps you're part of the problem.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#52

Post by ddragon »

siproprio wrote: post #51
ddragon wrote: post #7

Earlier quoted context omitted.

Your 1st, 2nd and 4th points seem to be fundamentally the same, which is compile time latency making interactive use slow. That's definitely a problem for a language trying to solve the two language problem of having high interactivity and high performance at the same time, and the compiler team [1] are now focusing on that issue on versions 1.4 and beyond hopefully it will get to the point where it isn't a problem a…

Nope, they are not the same points! 1. It's about compiler latency. Compiling happens when you call the function. That indeed can and should be improved. But there are other things that contribute to the experience being shitty. 2. Is about adding a package, when adding a package it downloads all the dependencies (which includes cairo, and WinRPM on windows which all have problems of their own). 4. Is about the poor…

Fair enough, you mentioned the speed of adding a package and I assume it was the build time after the download (which is mostly git). I have to confess that I don't consider the speed of the initial build essential since it's a one time thing (correctly and efficiently building and handling dependencies is, which it does very well in my opinion). Also, I think they are testing now a way to deliver binary libraries within the deps which can improve the situation with the external dependencies.

Visual Studio Code is definitely fast enough in my machine (especially with a Revise.jl workflow), which is why I also assumed it was stuff like running part of the code or using the Language Server Protocol, which will hit the same compilation lag. I agree that Atom is slow, and it's one of the reason I don't use it.

Though I'm clearly biased since my experience is entirely in Linux, it's possible that the Windows experience is just worse.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#53

Post by shmerl »

pjmlp wrote: post #47
shmerl wrote: post #18

> The performance possibilities of GPUs can be democratized by providing more high-level tools that are easy to use by a large community of applied mathematicians and machine learning programmers. How exactly CUDA is "democratizing" anything, if it's tied to Nvidia? Vulkan backend would make more sense for that purpose.

It allows us to use any programming language with PTX backend. OpenCL on the other hand is C FTW and now kind of supports C++ if one has luck with the drivers. From that point of view is democratizing GPGPU programming to anyone that doesn't want to deal with either C or C++.

That's not democratizing GPU computing, that's "democratizing" Nvidia lock-in. Totally different thing, so their claim was hypocritical, since they made it sound like a general thing.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#54

Post by siproprio »

ddragon wrote: post #52
siproprio wrote: post #51

Earlier quoted context omitted.

Nope, they are not the same points! 1. It's about compiler latency. Compiling happens when you call the function. That indeed can and should be improved. But there are other things that contribute to the experience being shitty. 2. Is about adding a package, when adding a package it downloads all the dependencies (which includes cairo, and WinRPM on windows which all have problems of their own). 4. Is about the poor…

Fair enough, you mentioned the speed of adding a package and I assume it was the build time after the download (which is mostly git). I have to confess that I don't consider the speed of the initial build essential since it's a one time thing (correctly and efficiently building and handling dependencies is, which it does very well in my opinion). Also, I think they are testing now a way to deliver binary libraries wi…

The VS Code extension took a long time to support newer versions of the language.

What happens in between figuring out how to make basic tooling work and actually getting something done is frustration.

Building is so clearly not a one-time thing if you use the language to explore solutions, and play with things.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#55

Post by llukas »

shmerl wrote: post #19
sytelus wrote: post #8

Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.

Because Nvidia likes lock-in. It totally doesn't have to. Today we have Vulkan for general purpose GPU programming.

OpenCL, hip, Vulkan, what tomorrow? Or alternatively, there were cl* libraries, roc* libraries and hip* libraries for AMD? Which ones are supported?

CUDA doesn't require rewriting code with ${OSS} framework of the year, every year. They need to earn that lock-in with future compatibility guarantees which none of OSS projects has.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#56

Post by shmerl »

llukas wrote: post #55
shmerl wrote: post #19

Earlier quoted context omitted.

Because Nvidia likes lock-in. It totally doesn't have to. Today we have Vulkan for general purpose GPU programming.

OpenCL, hip, Vulkan, what tomorrow? Or alternatively, there were cl* libraries, roc* libraries and hip* libraries for AMD? Which ones are supported? CUDA doesn't require rewriting code with ${OSS} framework of the year, every year. They need to earn that lock-in with future compatibility guarantees which none of OSS projects has.

Whatever it is, as long as it's not tied to one GPU only, it could be promising. Something that's tied to Nvidia or anyone else exclusively is not good, and surely isn't democratizing anything.

> CUDA doesn't require rewriting code with ${OSS} framework of the year, every year.

How so? Change the GPU from Nvidia, and you are forced to rewrite code. That's the whole point of lock-in, it's a tax on developers. CUDA doens't guarantee you anything, if you don't stick with their GPUs.

Vulkan on the the other hand has conformance requirements.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#57

Post by pjmlp »

shmerl wrote: post #53
pjmlp wrote: post #47

Earlier quoted context omitted.

It allows us to use any programming language with PTX backend. OpenCL on the other hand is C FTW and now kind of supports C++ if one has luck with the drivers. From that point of view is democratizing GPGPU programming to anyone that doesn't want to deal with either C or C++.

That's not democratizing GPU computing, that's "democratizing" Nvidia lock-in. Totally different thing, so their claim was hypocritical, since they made it sound like a general thing.

It is easy to sort out, Khronos just needs to accept that a large majority of developers want productive SDKs, not raw specifications based on C, and with luck some C++ as well.

I also don't see you complain that so far the only mature SYCL SDK is available from Codeplay, thus making it a single vendor "standard". At least until Intel (One API) and others actually come one with their SYCL extensions, because naturally nothing that Khronos does can be without extensions and its multiple execution paths.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#58

Post by StefanKarpinski »

siproprio wrote: post #50
StefanKarpinski wrote: post #44

Earlier quoted context omitted.

I’m curious what specifically you would want improved in the REPL.

Does the REPL on Windows have all the features and niceties and quality of life of the REPL on bash or other OSes? If so (which isn't), then we can start suggesting new features, perhaps better text editing capabilities, or introspection, better access to documentation.

The REPL on all platforms is the same. There’s an issue with old buggy versions of cmd.exe, but that’s only on such old versions of Windows that they’re not even supported by Microsoft anymore.
Post reply on HN