ggreg84

Chips and Cheese GPU analysis are pretty detailed, but they need to be taken with a huge grain of salt because the results only really apply to OpenCL and nobody buying NVIDIA or AMD GPUs for Compute runs OpenCL on them; its either CUDA or HIP, which differ widely in parts of their compilation stack.

After reading the entire analysis, I'm left wondering, what observations in this analysis - if any - actually apply to CUDA?

Asynchronous clean-up is a solved problem in C++ senders & receivers.

I wonder what's so different about rust that they can't solve it in the same way.

> My biggest concern with Rust is the sloppiness around the distinction between a "compiler bug" and a "hole in the type system."

That bug is marked as I-unsound, which means that it introduces a hole in the type system.

And so are all other similar bugs, i.e., your concern seems to be unfounded, since you can actually click on the I-unsound label, and view all current bugs of this kind (and past closed ones as well!).

LUMI as an "AI customer" has a:

- low-budget: tax payer supercomputer for tax payer phd students

- high-risk tolerance: tolerate AI cluster arriving 5 years late (Intel and Aurora), lack of AI SW stack, etc.

- High FP64 FLOPs constraint: nobody doing AI cares about FP64

Private companies whose survival depend on very expensive engineers (10x EU phd student salary) quickly generating value from AI in a very competitive market are completely different kind of "AI customers".

> OpenCL based machine learning libraries, no?

Have you used OpenCL and CUDA C++ ?

CUDA C++ is single-source easy to use, has good tools, has a lots of libraries you can build your new library on top (empowered by generic libraries, it can use all pre-existing C++ libraries), ...

OpenCL... is not single-source, not easy to use, does not have good tools, does not have good libraries that you can reuse (does not have generics), ...

AI is like a F1 race, you can either go race with a F1 car (CUDA C++), or don't go at all. Trying to go with the horsecar OpenCL is, is a waste of time and money. Every other AI startup is going to loop you a million times.

> Nvidia deliberately undermined that at every turn, and pushed a proprietary solution, hard.

Undermined who at what? Nobody was interested in OpenCL succeeding: not Intel, not AMD, not Apple. All these companies pushed and continue to push for their own proprietary incompatible ecosystems to try to create a platform like NVIDIA has with CUDA. Intel pushes for OneAPI which is Intel only, AMD pushes for their CUDA clone, and Apple pushes for Metal.

Its easy to create a new standard. You and me can get together, write something on a napkin, call it a standard, and we are done. We could go around telling people that it's going to be "The Future", like it happened with OpenCL, but that doesn't mean anyone will actually ship something that's usable. It is particularly easy to create a Khronos "standard", of which there are 200, and of which _none_ standardizes standard practice: create the standard first, try to see if it solves the problem later. Claiming that you are entitled to NVIDIA implementing them all, is... well... just that... pure entitlement.

From all vendors, ironically, it actually seems that the only vendor working on a portable way to program GPUs is NVIDIA itself, since they have sent a bunch of people regularly to the ISO Fortran and ISO C++ standard committees to extend these languages to allow portable code to run on GPUs without changes. In contrast to OpenCL, ISO Fortran and ISO C++ are actual international standards.

I think Fortran supports this since 2018 standard, and C++ since 2017. Ironically, NVIDIA is the only vendor that actually ships this and has for years. The NVIDIA fortran and c++ compilers can run these languages on their GPUs. Intel and AMD will talk about how "portable and cross-vendor" OneAPI and ROCm are, yet their Fortran and C++ implementations still, 5 years later, can't actually use their GPUs. The reason is simple, AMD and Intel don't care / believe / want a portable programming model for GPUs. They want their own closed platform. Unfortunately, since they are at a disadvantage, they need their closed platforms to be able to run on NVIDIA GPUs because otherwise nobody would use them, but that doesn't mean that their platforms are portable or open, and they don't care about code using their platform being able to run well on NVIDIA GPUs since that would be counter productive. So in practice, people still need to use CUDA C++ to target NVIDIA GPUs.

Anyways, OpenCL didn't failed "because of NVIDIA". It failed because it is a bad standard, it was a bad standard when it was created (it was significantly worse than the standard practice back then, hence why nobody wanted to use it in practice), and it turns out no vendor is actually interested in it, so it is a worthless standard.

Indeed, wow.

Which is (EDIT: NOT) the most widely sold console ever.

I just use inotifywait for that. What does entr do differently?

This will run a binary when any file on the directory tree changes:

    #!/usr/bin/env sh
    set -e
    while true; do
        inotifywait -e modify,create,delete,move -r $1 $2
    done

and then just call it: run_on_modify path/to/dir path/to/bin

If someone thinks this is magic or wizardy, instead of teaching them that fire exists (entr), teach them how to make fire first (inotify, linux inodes, etc.). Knowing what kind of events inodes support and how to do something when they happen is pretty powerful.

If you then want to use "entr" or similar instead of just calling inotifywait yourself, that's fair game. But TBH I have a hard time justifying a C or Rust program that's not going to be available / installed everywhere when a 3 LOC POSIX shell script can solve the same problem (and many many more).

> Is this a serious comment? Alwrapper doesn't use emulation. An API wrapper simply translates calls to the appropriate API. B

QEMU simply translates calls from one hardware API to another hardware API, so it isn't an emulator either right?

Since you can't really buy apple cpus or gpus and put them in a PC, for benchmarking... today at least one can't compare apple's hardware against intel hardware.

What one can compare, is the performance of the "Apple platform" and the "PC platform" at similar price points, power budgets, features. This is more meaningful for most people, which mostly care about how fast can the computer do X (whether it uses the CPU, GPU, or some other chip, most people don't care).

Buy professional appliances, for restaurants.

For some reason, they are often better along many axes: cheaper, easier to clean, more customizable, more powerful, more flexible, etc.

I really like the professional induction stoves, with actual physical dials, no touch crap.

And the best part, there is a huge used market for professional appliances in really good shape, for even lower price.

> Isn't there a single GPU benchmark that actually does the same work so that comparisons can actually be made?

Apple does not support OpenGL or Vulkan, only Metal, and most app devs have better things to do than rewriting code for the Mac.

The recommended way of gaming on a mac is to use emulation by emulating whatever the game is used with a metal wrapper.

IMO the claim that these benchmarks aren't fair is naive. I don't care about how good the hardware is, but about what performance I get. If I get poor performance because the software, drivers, etc. are poor, I want to know that.

If you can re-compile all your source code, then ABI stability is not that important.

In the real world,

- people use operating systems to get work done,

- such work is often done with proprietary software that people buy, and that lot of people get paid to develop

- breaking such software is not acceptable, because it means that suddenly dozens of thousand of people can't work

- telling all those people to "stop working" until their software is fixed is not acceptable either.

People use Linux for work in the real world, and that's why Linux tries very hard not to break ABIs.

Microsoft has had a stable ABI for 30 years, and people still run software compiled 30 years ago on the latest Windows version today.

What this tells you about OpenBSD users, is another story.

+1. Asking the right questions.

What went wrong is that people learned how much NVIDIA pays, figured out they were significantly underpayed, Arm is not a very profitable business so couldn't compete, and the moment it started looking like the NVIDIA deal was not going to fly, top talent started jumping ship.