ColonelPhantom

Apple=expensive meme will only die if it stops being true. For example, I can get a Thinkpad T14 Gen 4 with the best processor AMD has to offer, 32 GB RAM and a 512 GB SSD for less than the base M2 Air (€1250 vs €1300), which has a pitiful 8 GB/256 GB RAM.

If that's too expensive, an E14 Gen 5 has a previous-generation processor but can be had in a reasonable configuration (Ryzen 5, 16GB RAM, 512GB SSD) for around €700.

You can knock a fair chunk (€60) off of the price by getting them without Windows as well, which is a nice option when you're gonna install Linux anyway. But the prices I mentioned is before you even do that!

Woah, now that's a name I haven't heard in a long time!

It says that it fits on a CD, but how about the other requirements? e.g. how much RAM is needed, and what kind of instruction set does the CPU need to support? is a 386 enough or do you need 486/586/686 level instructions?

I think the point is that if e.g. v7 removes a certain method, but the replacement is already available in v6, you can simply keep using v6 while updating your code to use the new method. By doing all this work on top of v6, upgrading to v7 becomes as simple as 'flipping the switch', and reverting it if issues do arise also becomes trivial.

But yes, I can definitely imagine cases where trying to apply this method leads to a chicken-and-egg problem.

There's no silver bullet, not even mutation testing. For example, if the code for a certain case is straight up missing, there is nothing to mutate!

I also consider mutation testing to be in a different domain from property based testing, as mutation testing is some kind of metatesting instead. PBT is a 'regular' testing technique. This means that they are in fact complimentary, for example by using PBT to check mutants. (Although mutation testing does seem to assume a sort-of 'fixed' test set, but you can also fix a test set with PBT by e.g. explicitly setting a seed and test count.)

Does anyone use this method in practice? How well does it work?

I can imagine it not working well in some cases, for example when a failure can only be resolved by some new thing (e.g. when a function was replaced by some other function).

There also seems to be an implicit assumption that the tests are 'sufficient', whereas I'd wager that the whole reason a revert is needed is the fact they are, in fact, insufficient. The article even says so:

> Obviously, the Mikado Method cannot work if you don’t have a good and highly reliable automated test suite.

But if you have a good test suite, then there should be no problem shipping the big change in one go!

I imagine the mikado method can still work though, because when shit does hit the fan, you can just downgrade to the previous version while keeping most of the preliminary changes? And that should then reduce the cost of the revert.

That's overly reductionist. Conroe topped out at around 3 GHz, compared to its predecessor Presler achieving 3.6 GHz.

I think Netburst mostly came from a misguided place where Intel thought that clock frequency was in fact the holy grail (and would scale far beyond what actually ended up happening), and that all the IPC issues such as costly mispredicts could be solved by e.g. improving branch prediction.

> some is going back to 7nm and 6nm (shrunk 7nm) I think

You can also see the lasting popularity of 7nm-class nodes in consumer products. For example, RDNA3 uses 5nm for the core parts (GCD), but the peripheral parts (the memory chiplets/MCDs) are built on 6nm, and the monolithic low-end parts (RX 7600) are even fully built on 6nm.

Bulldozer was contemporary with Sandy Bridge, not Skylake. Piledriver competed with Ivy Bridge and Haswell. The next Construction cores (Steamroller and Excavator) were only found in APUs, and not in desktop FX parts. Around the time of Skylake, AMD didn't have a meaningful presence in the desktop space. All they were selling was quad-core APUs based on minor revisions of Bulldozer, and the highly outdated FX-x3xx Piledrivers.

>Do they see it some other way? As exploitation? But you are the one who put the content out there! If you didn't want others to see and use and learn from your content,

The point is that "others" learning from things is fine. The problem starts when it's a machine acting on behalf of a faceless mega-corporation. It's like the tragedy of the commons, except instead of originating from an invisible mass of takers, it mostly comes from a small amount of known actors like Microsoft and Google. No shit that people will rally against those.

> First time I've heard this one. Who doesn't want the tools to improve?

The reasoning is also given: improving machine learning has an environmental cost. It's also used to deskill jobs (which I don't think is a great argument, although it's not implausible for inequality to massively increase due to deployment of ML). The author also says AI is used to muddy public discourse, which is an understandable fear given that text generation can be used to fake e.g. some grassroots movement.

This resonates with my experience using Copilot. It generates lowest-common-denominator code, and displays a stunning unawareness of language and library features. Some understandable due to training cutoff (but still very frustrating), but it also refused to use Pillow functions that seem to have been around for a decade, instead crufting together some shitty pipeline by hand.

I find this kind of dismissal extremely tiring. It's very lazy to wave away criticism of a tool as a skill issue.

On the tin the claims are both true: LLMs do not replace search (it does not link me to any resources), at best it augments it (with services like Phind or Bing combining the two).

Also, search is made worse by SEO spam, which can be churned out more easily with AI, leading to crap like the following: https://web.archive.org/web/20230103091313/https://www.slowi... (which has been edited to be less nonsensical, but remains hilariously out of place). That's not to say that SEO spam wouldn't exist without AI, but this level of carelessness ("a 32 bit wine bottle is a bottle of wine that has been created with 32 bits of data") seems to be new.

Are there any practical and somewhat popular stack-based/concatenative languages? 'Popular' here doesn't need to mean that popular, something on a similar usage level to some Lisp dialects, or functional languages like Haskell.

I read the linked article, and found it rather confusing. For example, what does "In order to write a lot of small definitions you have to have a stack" mean? e.g. in Haskell lots of functions are very small compositions of existing functions, like "foo = filter bar . map baz". But it's definitely not stack based!

I'm also confused about the "local variables are harmful" mentality. Why? They may not suit concatenative languages, but I find naming things serves as effective 'documentation'. Or is the point that these should be put in separate functions? But that also sounds wrong, because then you greatly complicate the control flow and spread everything to many places. Furthermore, isn't something like that A register 'just' a local variable (or worse: a mutable global variable)?

I find the dismissal of things like files and encryption disturbing. Many programs need some form of persistence. How is that useless? Why does 'needed data' not need to be encrypted?!?

It's worth mentioning that Pijul is largely based on the same theoretical model of Darcs, which actually predates Git. But Pijul definitely makes it a lot more workable, e.g. by solving the exponential (iirc) complexity merge that Darcs has.

Most race conditions are prevented by Rust thanks to its "alias XOR mutable" paradigm that prevents having multiple mutable references and enforces the presence of locking or atomics. Not all, but the words "fearless concurrency" aren't meaningless either.

> But Weak can be needed in case you have self-referential structures, right?

Well, technically, no, you can just use Arc and leak memory all over the place :^) but that's not very useful either. Most self-referential structures need some kind of "owning" thing too though. For example, a graph could use Weak for the edges, but in order to keep vertices alive you need e.g. a Vec<Arc<Node>>. Then, if upgrading fails, you know that your edge leads to a deleted vertex (and as such should be considered nothing, hence Option).

> Sure, Rust will give him far fewer ways to screw up. But if he can't be asked to at least not use malloc/free in C++, he probably won't be too careful about unwrap() either?

There's one big advantage of messing up with unwrap vs malloc/free: unwrap 'only' crashes your program (and can even be caught in some scenarios), whereas use-after-free can do literally anything. Unwrap is also much easier to debug because you usually get a clear stack-trace, and the program semantics have been well-defined at all points.

> My point here is mainly that a good programming language won't make good programmers out of bad ones.

Very true! But I think the point of Rust advocates tends to be more along the lines of "a bad programming language makes a bad programmer out of a decent one". It is very easy to misuse C++, so mistakes are made with it way more often. 'Dangerous' constructs do exist in Rust, but are generally far less pervasive, making it easier for the programmer to understand what they are doing.

Saying Rust has no benefits over C++ because you can mess up in both is like saying that anti-lock brakes are useless because you can still understeer by pressing the accelerator too hard (sorry for the car analogy, I had to). Preventing entire classes of mistakes is valuable, even if other classes are still possible. (If it's worth the cost is of course another question. My personal opinion is yes, although that's especially for memory safety and a bit less for race safety.)

Sure, that does seem to be a race condition that can crash. I'm not sure how valuable this example is though, because it's not very intricate at all: a Weak reference can be invalidated (duh!)

The fix is trivial: just use an Arc instead of a Weak. In addition, `upgrade().unwrap()` should be a sizable red flag (like any unwrap, really) since fallibility is kind of the entire thing of Weak.

Seems like it currently supports only CUDA and ROCm. Are there plans to support any other GPU vendors, such as Intel?

The example also seems a little bit high on 'magic'. Chapel is told to execute on GPU, yet it somehow decides "this loop is order-dependent so it should run on the CPU anyway"? It's not a bad approach necessarily, but I don't think you can get any such implicit serialization when directly programming CUDA C++ or similar. (I think Futhark, another language for high-level parallel computing, also doesn't suffer from this kind of thing, thanks to being purely functional.)

chipStar (formerly CHIP-SPV) might also be worth checking out: https://github.com/CHIP-SPV/chipStar

It compiles CUDA/HIP C++ to SPIR-V that can run on top of OpenCL or Level Zero. (It does require OpenCL's compute flavored SPIR-V, instead of graphics flavored SPIR-V as seen in OpenGL or Vulkan. I also think it requires some OpenCL extensions that are currently exclusive to Intel NEO, but should on paper be coming to Mesa's rusticl implementation too.

You do manage the state of your database. When you do an UPDATE, you explicitly change the state.

The statefulness of an index, however, is merely an implementation detail. A database without indices would be in the same state, and behave the same (except much slower). This means that the state is not important for the semantics of the datastore, unlike with a regular database.

> it was just moved one step further down the layer

And therefore, crucially, you don't need to manage it yourself anymore. The only thing you need to do is tell the system what to index (which is code, not state/data).

Wait, cublas is slower?? Shouldn't it be faster because it's tuned for the specific hardware?

I know that llama.cpp has custom kernels for quantized matrices, which are fast because using cublas would require an extra memory roundtrip (read -> dequantize -> write; read -> gemm -> write, vs. read -> dequant -> gemm -> write). But if you're using FP16 the dequantization step shouldn't be necessary. So how is it faster?

My HD 7850 machine on Windows is currently on some legacy-branch "22.6.1" driver, over a year old. Even my RX 580 is on another legacy branch now, with most updates only being for RDNA cards.

AMD's dropping of Polaris and Vega also applies to Linux, where the AMDVLK first-party driver stopped supporting them. ROCm also does not work anymore.

Of course, nobody uses AMDVLK so it's not a huge loss (RADV is generally a lot better), but the loss of ROCm does suck.

Yeah, just like the R600 driver supports HD 2000 through HD 6000 hardware ('Terascale'), basically any Radeon HD except HD 7000. And radeonsi originally meant "Southern Islands" aka HD 7000 (and parts of the Rx 200/Rx 300 lineup) but it works on all GCN and RDNA cards.

> And there are no open source drivers for compute.

Well, technically ROCm is open source (although it comes across more as a "dump source code releases every now and then" to me.)

Also, the link is from the Mesa project, which is working on an OpenCL frontend to the driver called rusticl. It's not yet stable or enabled by default, but if you get a build of it, you can try setting the environment variable `RUSTICL_ENABLE=radeonsi` and it should sort-of work (on any Radeon HD 7000 or Radeon R7/R9/RX GPU!)

iirc the rusticl developers are even hoping/planning to get HIP (via chipStar) and SYCL (via Intel's compiler) working on top of rusticl.

Is it that the people who keep going find ways to enjoy it, or that the people who find ways to enjoy it keep going? Your comment seems to imply a certain causality that I do not find immediately convincing.

Bandwidth has been restricted on this URL. Archives are available at:

https://web.archive.org/web/20240103035219/https://wozniak.c...

https://archive.is/20240103045612/https://wozniak.ca/blog/20...

Well, it mentions comparison against multiple other algorithms. So if those 55% are divided between a bunch of other algorithms, being the best in 45% could mean it's the best more often than any other algorithm.

Isn't prepending the efficient operation? Appending would require mutation or copying, prepending only requires a single new cons cell.

Appending to a linked list is fine if you can mutate and keep a pointer to the tail, but then again, extending mutable arrays is also amortized O(1) assuming a reasonable allocation scheme.

> RDNA3 does have WMMA which should at least get the foot in the door for things like AI/ML(-weighted TAAU) upscaling.

Do keep in mind that RDNA3 WMMA is very slow, running at the same theoretical TFLOPS as shader (which are doubled from RDNA2 due to very limited dual issue support that can be used in WMMA). Nvidia tensor cores and Intel XMX can run closer to 4:1 or 8:1 or so compared to vector workloads.

> It just feels obviously wrong to do wave-8 right of the gate

That's because Alchemist isn't a a true first generation product, it's a scaled-up version of Intel's (relatively mature at this point) integrated graphics product. This means that Alchemist has suffered large growing pains (Gen12 was not really designed to be used in products bigger than maybe 128 EUs, A770 is 512 EUs). It also has some form of separation anxiety, seeing its need for ReBAR. I also recall very early in Alchemist's life (pre-release) some driver optimization that had a huge benefit, which was just the wrong memory region being used, as all memory is the same on an iGPU but not a dGPU.