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…
Nvidia adds native Python support to CUDA
131–140 of 196 posts
Re: Nvidia adds native Python support to CUDA
#132Earlier 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…
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
#133Earlier 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…
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
#134We should find a new word since GPU is is from back when it was used for graphics.
Greater Processing Unit
Giant Processing Unit
Re: Nvidia adds native Python support to CUDA
#135Earlier 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…
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
#136Earlier 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…
Re: Nvidia adds native Python support to CUDA
#137python 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.
Re: Nvidia adds native Python support to CUDA
#138Re: Nvidia adds native Python support to CUDA
#139Earlier 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)!
Re: Nvidia adds native Python support to CUDA
#140We should find a new word since GPU is is from back when it was used for graphics.