Honestly for the price you'd have to pay to get an equivalent Windows laptop you can buy two Macbook Airs. I think Apple's higher end machines are overpriced but their entry level laptops are a bargain, for what you get. Unless you need Linux (and the resulting bugginess/short battery life), it's really a no-brainer.
(Don't tell my Linux isn't buggy. I use it, but I regularly run into nonsense like this: https://bugs.kde.org/show_bug.cgi?id=512297 that doesn't happen on Windows or Mac. I still haven't figured out why VSCode freezes for half a second every few minutes on Linux.)
Well, it depends what those requests are doing surely? I always thought it was weird to treat "request" as a unit of measurement. Are you requesting a static help page, or a GraphQL search query?
Interesting, but SpiNNAker (ugh) has been around for 6 years now, and presumably they had smaller options than that before. Has it actually produced anything useful.
It seems very premature to say "let's build spiking NN hardware!" (or a million core cluster) before we even know how to write the software.
Spiking NNs need their Alexnet before it makes any sense to make dedicated hardware IMO.
Agreed, although SpiNNaker really isn't much specialized for spiking NNs - it's really just a large ARM-base cluster specialized for fast message passing. The messages could be inter-neuron communications, or anything else, and it has been used for other purposes.
I really don't understand the thinking behind these hardware-based neuromorphic projects... as you say it would make more sense to prove ideas out in software first, especially for experimenting with more biologically accurate models of neurons.
It seems the time to commit to hardware would be if neuromorhic/spiking/asynchronous designs show worthwhile functional benefits, and need custom silicon for efficient implementation.
I don't think it's obvious. A likelier explanation is just that a lot of people are using Claude (especially HN types). Do you have any actual evidence?
You can explain away any obvious astroturfing campaign with "wow, so many people love this product and feel the need to bring it up all the time in unrelated contexts!" if you want to.
If you think two people making the exact same comment about "Claude Max" (not even just Claude, specifically bringing up the $200 subscription) on an unrelated post is organic, I don't know what to tell you.
I think that's less likely than you'd expect because the memory ordering model used by C++ and others essentially requires you to write code that works even without x86's total storage order. If you don't then you can get bugs even on x86, because the compiler will violate the ordering you thought you had in your program, even if the CPU doesn't.
Also most software runs on ARM now and I don't think that has actually happened in practice.
It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example:
x = *a;
if (x) y = *b;
The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail.
It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.
Memory ordering issues require two sides to manifest, since even the most extreme out-of-order architecture presents itself as in-order to a single thread.
Imagine that code was paired with code in another thread that did:
*b = newValue;
barrier();
*a = 1;
We put a barrier here to ensure the stores don't get reordered, since we must write out the new value in b before writing out the flag in a that tells the other code to use it.
Paired with this, my example above will work fine on an architecture with strong ordering, but will potentially get a bad value into y on archs with weak ordering. The reader may fetch the value in b first, getting the value before the reassignment. It may then fetch the value in a and see 1. This will cause it to use the old value loaded from *b, which is semantically incorrect in this case even though it's perfectly correct according to the architecture and the language spec.
Correct code here would need an acquire barrier on the load of a, paired with a release barrier on the store.
I think they're an outlier, but still I was disappointed by Ars's response. They deleted the article and didn't detail what was wrong with it at all. Felt like a cover-up.
BBC News does have to report on itself from time to time. Here's it's "live" feed from November on the Parliamentary Committee investigation into the Trump speech edit incident:
Panorama is technically part of News. The CEO of News resigned over the trump edit as well as the Director General. Though an independent production company (October Films) produced the documentary, they claim BBC News Panorama team had final say over the editing. The BBC doesn't seem to have ever disputed this.
This was a big disappointment. I read the original article and the comment from the source highlighting the error, knew what was wrong with it, and still think it was the wrong move to just delete the article and all the original comments, and replace it with an editorial note.
This is a kind of cover-up. It's impossible to hide the issue but they went to great lengths to soften the optics and remove the damning content from the public record. They obscured the magnitude of the error. It looks like another "person uses AI and gets some details wrong".
What they did so far, the decisions that allowed the issue to occur in the first place (e.g. no editorial review before publishing) and the first reaction to deal with the incident (just destroy the content, article and comments) is everything I need to know about the journalistic principles at ArsTechnica. it's a major loss of trust for me.
reply