I just put Anubis in front of my self-hosted forge this morning because AmazonBot had helped itself to 750 GiB (!) of traffic to my public repos this month!
It’s <= a Radeon 7600 GPU (28 CUs RDNA3 vs 32), so I’m not sure I’d have advertised it as a 4k60 machine. Then again I’m not a marketer so what do I know. 4k60 is a flexible target with FSR I suppose.
What coordinate in the space is furthest from any named color? It looks like there are some relatively large voids in the blue/purple boundary area but it’s hard to say.
I think I’d buy something with Strix Halo or Strix Point if there was official ROCm support. As of 6.4.1 from earlier this month there’s still not, as I understand it. I’d be delighted to be corrected on this matter.
The article goes on to say what the author thinks is bad about this:
> We’re not raising emotionally intelligent kids. We’re raising kids to navigate human unpredictability as if it’s a design flaw. Because when you grow up with a machine that always gets you, messy human behavior feels broken. We’re not preparing kids to handle people.
I don’t think there’s anything wrong with escaping into fantasy in the right time and place, but young kids (and even well-adjusted adults) can have problems self-moderating and letting fantasy substitute for engaging with reality.
I compiled it for Ampere and counted 6834 actual F32 operations in the SASS after optimizations. I only counted FFMA, FADD, FMUL, FMNMX, and MUFU.RSQ after eyeballing the SASS code, so there might even be more. It's possible the FMNMX doesn't actually take a FLOP since you can do f32 max as an integer operation, and perhaps MUFU.RSQ doesn't either, but even if you only count FFMA, FADD, and FMUL there are still 3685 ops.
I basically have an even simpler version of something like this for my own personal use too. I found it pretty easy to write in Go and my area of expertise is decidedly not web frontend/backend. I’d recommend it as a fun little project if you’re looking for something to do.
For mine, I paste in a video or playlist URL and it downloads the video and creates a lower resolution transcoded version suitable for streaming to my phone. It also extracts an audio-only version in case that’s more appropriate.
My reading of OP is that it’s less about whether zopfli is technically the best way to achieve a 5% reduction in package size, and more about how that relatively simple proposal interacted with the NPM committee. Do you think something like this would fare better or differently for some reason?
Yeah, we really just try to come up with very loose bounds since the analysis is hard. Even so, it does occasionally stop us from getting things way way wrong.
I have worked on a performance-portable math library. We implement BLAS, sparse matrix operations, a variety of solvers, some ODE stuff, and various utilities for a variety of serial and parallel execution modes on x86, ARM, and the three major GPU vendors.
The simplest and highest-impact tests are all the edge cases - if an input matrix/vector/scalar is 0/1/-1/NaN, that usually tells you a lot about what the outputs should be.
It can be difficult to determine sensible numerical limit for error in the algorithms. The simplest example is a dot product - summing floats is not associative, so doing it in parallel is not bitwise the same as serial. For dot in particular it's relatively easy to come up with an error bound, but for anything more complicated it takes a particular expertise that is not always available. This has been a work in progress, and sometimes (usually) we just picked a magic tolerance out of thin air that seems to work.
Solvers are tested using analytical solutions and by inverting them, e.g. if we're solving Ax = y, for x, then Ax should come out "close" to the original y (see error tolerance discussion above).
One of the most surprising things to me is that the suite has identified many bugs in vendor math libraries (OpenBLAS, MKL, cuSparse, rocSparse, etc.) - a major component of what we do is wrap up these vendor libraries in a common interface so our users don't have to do any work when they switch supercomputers, so in practice we test them all pretty thoroughly as well. Maybe I can let OpenBLAS off the hook due to the wide variety of systems they support, but I expected the other vendors would do a better job since they're better-resourced.
For this reason we find regression tests to be useful as well.
Your impression is correct. Peer review would never catch this. Peer review basically assumes the counter party is operating in good faith, and as a result a thorough peer review basically is the following:
* is the treatment of existing work semi-thorough (even experts don’t know everything) and fair?
* are the claims novel w.r.t the existing work? If not, provide a reference to someone who has already done it.
* can you understand the experiments?
* do the experiments and their results lead to the conclusions claimed as novel?
* does the writing inhibit understanding of the technical content?
No peer review I have ever seen or done would catch anything but the most egregious bug of this nature.
One of my colleague's Ph.D. thesis was on how to achieve high-performance CPU implementations for bulk-synchronous programming models ("GPU programming")