#PEP 817 - Wheel Variants: Beyond Platfor...
lean tendon
The PEP has a really nice motivation section, I love that you start with how numpy could start serving wheels with modern CPU features compiled in. I think one of the reasons all these GPU implementations have at least a 10x speedup over CPU code is because they currently basically force people through an installation nightmare, but at the end of it you e.g. have a CUDA-13 ecosystem which across the board is well optimized.
So this PEP fixes both sides: the compatibility-minded CPU world can ship speedy wheels for CPUs from this decade, and the speed-focused GPU world can become more user friendly.
rigid pawn
in my personal experience, the contrast is even more stark: the CPU extensions give you some speedup (or a big one, for the pillow case), while without the right CUDA version, your code doesn't even run
there's many ML prediction tools that could run on CPU, but are effectively only usable on a GPU
it's a huge pain to set up all the ML stuff with CUDA, it's probably the single biggest pain we hear from users
lean tendon
I’m one of the software engineers working in a ML lab, so boy do I know!
For a lot of stuff however, the discrepancy is not as high, and as said, for those use cases I suspect that CPUs will be much more competitive when actually leveraging modern features.
Regarding the PEP: What I don’t get is how there’s just one variant label. What if a package needs both cuda 13 and x64_v3 features?
rigid pawn
the label is an alias that the package author can freely set, and then there's a variants.json that says what the label means, e.g. CUDA 13 and x86_64_v3
we decided against putting everything in the filename to avoid running into OS filename limits (the windows one specifically) and because the filename is already long
lean tendon
I see! So that means that the user can has full selection power, nice. They just have to learn which variants exist for a package.
sterile quail
My biggest concern with this pep, which isn't a new concern in general, is that we are eating up more characters for file names, and most file systems max out at 255. this is just a suspicion, not data driven, but we have some packages that have really long names already
Actually an easy enough query to make in the big query dataset... I'll give that a shot later if I am awake
sterile quail
An easy enough query:
SELECT `filename`, LENGTH(filename)
FROM `bigquery-public-data.pypi.distribution_metadata`
ORDER BY LENGTH(filename) DESC LIMIT 1000;
Produces this CSV so you don't have to. It includes filenames of things that have also been removed, since BQ "knows all" and doesn't get updated when things are deleted.
Some of the top results have also been reported as causing issues with mirrors, as reported years ago in https://github.com/pypi/warehouse/issues/12483 - in the version string - but other results in the set like aerospike example appear to have been built with tooling priro to compressed tag sets