Live data from Hacker News

Nvidia adds native Python support to CUDA

thenewstack.io

131–140 of 196 posts

Re: Nvidia adds native Python support to CUDA

#131

Earlier quoted context omitted.

> Packaging and deployment will soon be solved problems I really hope you're right. I love Python as a language, but for any sufficiently large project, those items become an absolute nightmare without something like Docker. And even with, there seems to be multiple ways people solve it. I wish they'd put something in at the language level or bless an 'official' one. Go has spoiled me there.

Honestly, I'm still incredibly shocked at just how bad Python is on this front. I'm plenty familiar with packaging solutions that are painful to work with, but the state of python was shocking when I hopped back in because of the available ML tooling. UV seems to be at least somewhat better, but damn - watching pip literally download 20+ 800MB torch wheels over and over trying to resolve deps only to waste 25GB of ba…

Python was not taken seriously as something you actually shipped to non-devs. The solution was normally "install the correct version of Python on the host system". In the Linux world, this could be handled through Docker, pyenv. For Windows users, this meant installing a several GB distro and hoping it didn't conflict with what was already on the system.

Re: Nvidia adds native Python support to CUDA

#132
post #52

Earlier quoted context omitted.

Would you say Python is a good language to learn as a beginner?

I go back and forth on this. A lot of people make good points. In the end, my final answer is - yes. I say that because I believe it's the easiest programming language to get something working in. And getting something working is what motivates people to keep going. If you sit them down and say 'well before you learn python you need to learn how a computer really works, here's an ASM x86 book', they're gonna probably…

Yeah, Python or Javascript should be first languages for most people.

People like flashy things, and Python and Javascript are just 10x easier to get that working. Console I/O doesn't really cut it anymore.

Later on you can deal with memory allocation, bit-twiddling, 2's complement arithmetic, lower level OS details etc.

Re: Nvidia adds native Python support to CUDA

#133
post #52

Earlier quoted context omitted.

Would you say Python is a good language to learn as a beginner?

Not the person you replied to but I'd say definitely not. It'd be easy to pick up bad habits from python (untyped variables) and try to carry them over to other languages. It's also the king of runtime errors, which will frustrate newbies. I think a compiled language is a better choice for people just getting started. Java is good, IMO, because it is verbose. Eventually the beginner may get tired of the verbosity and…

Huh? Python variables definitely have a type. Its just determined at runtime.

The only untyped language I know, at least modern ones is assembler.

Well and C, if you make everything void*.

Re: Nvidia adds native Python support to CUDA

#135
post #52

Earlier quoted context omitted.

Would you say Python is a good language to learn as a beginner?

Yeah, definitely. It's basically executable pseudocode and it's really simple for a beginner to pick up and hit the ground running for a variety of use cases. Some people will tell you to start with C or C++ to get a better intuition for what's actually happening under the hood in Python, but that's not really necessary for most use cases unless you're doing something niche. Some of the most popular use cases for Pyt…

I was teaching python long ago to very beginners in programming.

Honestly, the language became kinda harsh for newcomers, what we see as developpers is 'it's like pseudocode that runs'.

But a beginner is often left behind the billions of methods in each class. He is not used to documentation, and spend quite a huge amount of time learning by heart stupid things like 'len()' in this case it's '.len()' here it's '.length',etc.. For many meany methods that all have their idiosyncracies.

At least in c/(easy)c++, you need to build yourself most of it, helping the understanding.

I'm not completely against python as a first language, but it need to be teached well, and that could include working with a very minimal set of functions on every objects. Then you can expand and incorporate more and more methods that make life easier.

Re: Nvidia adds native Python support to CUDA

#136

Earlier quoted context omitted.

I described the correct way to time it when using the card as a black-box accelerator.

You can create metrics for whatever you want! Go ahead! But cuda is not a black box math accelerator. You can stupidly treat it as such, but that doesn’t make it that. It’s an entire ecosystem with drivers and contexts and lifecycles. If everything you’re doing is synchronous and/or you don’t mind if your metrics include totally unrelated costs, then time.time() is fine, sure. But if that’s the case, you’ve got bigge…

You're arguing with people who have no idea what they're talking about on a forum that is a circular "increase in acceleration" of a personality trait that gets co-opted into arguing incorrectly about everything - a trait that everyone else knows is defective.

Re: Nvidia adds native Python support to CUDA

#137

python is the winner, turning pseudo code into interesting stuff it's only the beginning, there is no need to create new programming languages anymore

I heard the same thing about Ruby, Go, TypeScript, and Rust. (Even JS at one point when NodeJS was super popular a few years ago). There will be new shiny things, but of course, my choice is Python too.

Python - new (34 years old), shiny thing.

Re: Nvidia adds native Python support to CUDA

#139

Earlier quoted context omitted.

The reason is that the usage is completely different from coroutine based async. With GPUs you want to queue _as many async operations as possible_ and only then synchronize. That is, you would have a program like this (pseudocode): b = foo(a) c = bar(b) d = baz(c) synchronize() With coroutines/async await, something like this b = await foo(a) c = await bar(b) d = await baz(c) would synchronize after every step, bein…

Pretty sure you want it to do it the first way in all cases (not just with GPUs)!

It really depends on if you're dealing with an async stream or a single async result as the input to the next function. If a is an access token needed to access resource b, you cannot access a and b at the same time. You have to serialize your operations.
Post reply on HN