mschuetz

I'd assume most of what it does is a due to losing weight and reduced metabolism due to lower caloric intake.

Seems trivial to me for infinite loops. Nothing special to specify here, they're already specced by the definition of loops.

I don't see the issue. Just let wrong code do wrong things But let it do the expected wrong thing, rather than changing the code to something unexpected.

That's unfortunate. Cuda has shown that, when done right, defaults and a convenience layer can make for a well received API without sacrificing performance.

> The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually,

Yes, I also prefer doing it that way, but in Cuda with the driver API. Allows you to handle kernels like shaders, including editing and hot-reloading at runtime.

The reason I'm sticking with CUDA is because it's by far the most convenient API to use, without nonsense like 50-liners to alloc memory or the need to manage descriptors, bindings, queue families, etc.

Just looked it up, and I find it rather bland. It's not bad, but not great either, and the immediate surroundings are barren and boring.

Gif is still there because it's still often the only option for frictionless video embedding. Embedded videos usually come with a video player that hardly ever quite works out well, often not starting automatically, not looping, or showing video player UI elementa that shouldnt be shown.

It could easily be a competitor to Cuda, if it just made things easier. Like, why does it take 50 lines of code to allocate memory in vulkan, and just one single line in cuda? Vulkan should just provide a single-line gpuMalloc convenience function. And not just for allocation, for all the other nonsense as well.

I wouldnt consider Vulkan any better in that regard. It's pretty damn terrible, UX-wise.

The problem with the open standards is that their dev UX is absolutely horrible. You can't neglect usability, and then be surprised that there are no users.

I'm generally suspicious of the effectiveness of ads. It always amuses me when Ibbuy something, and then I start getting ads for the thing I already bought.

I've had great experienced with it. It's almost certainly not as full-featered as premiere pro, but it runs buttery smooth and robust, while Premiere Pro kept crashing frequently and was a bit tedious to use for simple tasks.

I know people who would get it for local LLMs for use in their company.

Not at all. I specifically bought a MacBook Air M4, first Mac product in my life, for its fantastic performance in a passively cooled notebook. I have zero loyalty to Apple and usually use Windows. If someone else starts beating them perf wise, I'll happily switch again.

> and deal with consistent downtime,

Wildly exaggerated. I use github almost daily and can't remember when the last downtime was.

What do you mean "why"? Setting up and tinkering with systems is work I loathe to do, obviously. I want to code, not host coding repositories. I did it in the past because I had to, and now I don't have to do it because github does it for me. It's great.

But I don't want to have to do this kind of work, you're only listing disadvantages from my viewpoint.

Well, yeah, I am. It's not something I want to have to care about. I want to code, not host code repos.

Except anything I'd self host would be down much more often. I've hardly ever actually experienced down time issues with github when I needed it.

I wouldnt recommend anyone going to Vulkan, though. It's pretty much the worst graphics API out there, and WebGPU is mimicking Vulkan styles that even Vulkan is currently outphasing, like render passes and static pipelines.

WebGPU is newer, but lacks modern functionality because it was made to support ancient smartphones. That's great if you want to support ancient smartphones, but not if you want to utilize modern desktop GPUs.

Of course it is a skill issue, I'm not afraid of admitting I'm not smart enough for Vulkan. That so many people have skill issues is the reason why Cuda trumps and will continue to trump Vulkan despite being vendor-locked. If you want people to actually use Vulkan, you need to remove barriers to skill-issued people like me. Poor third party wrappers like VMA that barely address one out of hundreds of issues aren't going to accomplish that, you need to resolve barriers in the core API. With a design like Cuda where there is always a default easy path, and a complex but optional path.

It absolutely isn't. After having spent 5 days not getting anything done in Vulkan, and being able to implement that same thing in a single day in Cuda (no prior experience in either API), I decided to never ever use Vulkan. It's a hopelessly overengineered API that is in dire need of a successor.

I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-line malloc without the need for third-party libs; default queues so I don't need to query and select queues; implicit sync by default and explicit sync by choice; NV-style bindless (i.e. no descriptors, just a handle); and so much more.

On the contrary, it's great. Cuda is the single sane compute API and system, so I'll use it even if it means being vendor-locked. If my CUDA programs start running elsewhere without much intervention, that'd be amazing

They really don't, no. Vulkan: 50 lines to allocate device memory. Cuda: One single line. What kind of extensive documentation stack do you want for functionality that is trivial in Cuda? And that exact issue continues through every little step of the way to your first usable application. I know there is VMA, it is a very poor solution to a problem that shouldn't even exist, and it only poorly addresses one of 100 parts of the API where Cuda is vastly simpler than Vulkan. Cuda also doesnt force you to use queue families but you can optionally use streams. No ridiculous descriptor management and binding in cuda, just passing pointers and handles via launch arguments. No overengineered explicit syncing mechanis in cuda, everything is nicely implicitly synced until you explicitly opt in to parallel streams. etc.

A couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda.

Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.

> Ease of programming and a giant leap in performance is one of the key reasons for the CUDA platform’s widespread adoption

This, so much. Other platforms continue to ignore developer UX, but it's one of the main things that get's new users onboard and keeps old users around.

> unimportant implementation detail that should be assessed on performance alone rather than usability

I disagree. Usability is important, or you end up with garbage like Vulkan. I'd rather have 99% of the performance for 100% usability, than 100% of the performance for 5% of the usability.

Unfortunately when it comes to graphics APIs, the choices are between bad and worse, which is why I switched to doing real time rendering in CUDA. Easier to write a fast software rasterizer in cuda, than to draw a single triangle in Vulkan

Having participated in many studies, I lost much faith in studies. You could study the same thing, and get opposite results depending on how you build the study, which people participate (friends and colleagues will be reluctant to speak against your results), and the bias with which you set everything up. Also, many tasks require learning the tools, and some tools will start to be more productive with expertise than others.

That's exactly the one I'm really satisfied with.