Notices by David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)

@aral

Peter Thiel is sad to learn that 'being the worst' is not actually a protected category under anyone's discrimination legislation.

@edri Visa-free access is valuable only for places people want to visit. The EU could negotiate much more strongly by placing travel advisories on the USA (entirely reasonable for a place where people are shot by government employees with no due process and no consequences). Most travel insurance is invalid if there was a travel advisory in place when you left. And you really don’t want to visit the USA without travel insurance because a brief trip to the doctor without it can bankrupt you.

US tourism is already taking a big hit because people who read the news are avoiding it. Put more pressure on.

RE: https://mastodon.world/@somecanuckchick/116969880858246357

Note to people in government:

If you are trying to create economic growth, maybe don't ask for advice from companies that have made a large percentage of their workforce redundant in the last year or who have negative cash flow. Just a thought.

USB-C cables are so expensive because each one includes a cryptographically secure entropy source to ensure that it does breaks at an unpredictable time while in use.

Orbital AI datacentres come with latency issues. If they're in LEO, they will have moderately low latency to a moving point on Earth, but for a fixed client the latency will increase as more relays are needed to account for curvature, so the jitter is high. If you put them in geostationary orbit, the latency is fixed, but large.

The solution to this is to put not just the AI datacentres, but also the AI bros in orbit. If you put an AI bro and a small radio in LEO, in the same orbital trajectory as an AI datacenter, they will have very low latency - indeed, significantly lower latency than ground-based routing if both they and the datacentre are on the ground.

Importantly, AI bros have a lot less mass than datacentres. As such, they are much cheaper to launch. As a pilot programme, to assess feasibility, I recommend launching a test constellation of AI bros into LEO. Note that, unlike datacentres, AI bros are made out of non-toxic (at least, in the chemical sense) substances. The environmental impact of uncontrolled atmospheric reentry is significantly lower, making the risk from the failure of a pilot deployment significantly lower.

RE: https://infosec.exchange/@catsalad/116944318046104194

It’s fascinating seeing notifications for boosts here, where something you wrote a year or two ago will suddenly be found by someone, who boosts it, and then a little flurry of other people do.

It really makes you realise how much recency bias there is in most other systems, including most web forum software. Sometimes that’s useful (I don’t want obsolete solutions to be highlighted in preference to the ones that actually work), but it also makes writing there seem ephemeral. Here, a conversation can start up after two years of silence when someone comes up with something new to contribute. And that’s incredible.

One of the most interesting things I learned at Microsoft: demand for cloud is not driven by performance. The most popular SKUs are cheap older-generation things because we’ve already reached the point where computers are fast enough for a lot of massive use cases. When they roll our faster SKUs, very few people move.

Companies keep producing faster and faster server CPUs, but what the cloud providers really want is more reliable ones. When a CPU dies, that node is offlined. VMs on it are redeployed elsewhere, which customers notice (and which will impact SLAs). The node then sits there until someone goes and collects it. Fetching it and collecting usable components is expensive (but worth it, because a node with 1TiB of RAM is worth pulling the RAM from). Having a failed node now means that you have unbalanced network capacity (that rack has more capacity than it needs), but you can’t easily reduce power by turning off a fraction of a network.

Faster chips are useful only because they can often, instead, provide the same performance for lower power (and lower power, in addition to being cheaper, often also improves reliability).

I found that fascinating because it explains why they’re so excited by any use case that looks like it will trigger a spike in demand. It also means that there’s a lot of scope for disrupting the cloud market from the low end. I think companies like UniKraft will have a big impact here: being able to scale down is the killer app for the cloud, because renting 1% of a server is often enough, and if you pay 2% of the price of a server each year to do it then you’re still paying less than if you bought a server. A lot of cloud workloads are incredibly inefficient. The big providers have no incentive to make it easy for people to buy 10% as much compute as they currently need, but if you do that then you can undercut them by a huge amount, even if your profit margins are much higher.

One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.

Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.

The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.

Going back further, I was one of those people when I started contributing.

Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.

Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.

It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.

But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.

@ryanc

Crypto means cryptozoology.

@regehr

There are two different questions here:

• Is AArch64 a better ISA for modern microarchitectures than x86-64?
• Does the architecture limit the performance of an implementation?

The latter is trivially true. We have a load of examples of dead ends. Stack machines make extracting instruction-level parallelism really hard so lost completely to register machines.

Complex microcode makes out-of-order execution hard because you have to be able to serialise machine state on interrupt and decoded microops may have a bunch of state that isn't architectural. This one is quite interesting because it's a very sharp step change. Building a microcode engine that works is quite easy: serialise the pipeline, disable interrupts, run a bunch of microops, reenable interrupts. Building one that is efficient and allows multiple microcoded instructions to run in parallel is really hard, but if you do it then the complexity is amortised across a potentially large number of instructions. x86 chips took the first approach until fairly recently because there was a lot of lower-hanging fruit and microcoded instructions were rare. Having one instruction that requires complex microcode is absolutely the worst case.

Different ISAs favour different implementation choices. AArch32's choice to make the program counter architectural was great on simple pipelines, for example. It made PC-relative addressing trivial (just use PC as the base of any load or add) and made short relative jumps just an add to the PC. This became more annoying for more complex pipelines because you can't tell whether an instruction is a jump until you've done full decode (on most other RISCy ISAs, you can tell from the major opcode), which impacts where you do branch prediction. Similarly, all of the predication in AArch32 is great for avoiding using the branch predictor in common cases with simple pipelines, but you need that state anyway on big out-of-order machines. Thumb-2's if-then-else instruction provided a denser way of packing predication that scales nicely up to dual-issue in-order cores, but really hurts if you want to decode multiple instructions in parallel.

The question of AArch64 vs x86-64 is much more interesting.

Register rename is the biggest single consumer of power and the bottleneck on a lot of very high-end implementations. Complex addressing modes really help reduce this overhead, but so do memory-register operations where you avoid needing to keep a rename register live for a value that's used only once.

At MS, we did a lot of work on dataflow architectures to try to avoid this. This was largely driven by two observations:

• Around 2/3 of values are used exactly once.
• Around 2/3 of values (not the same 2/3, but an overlapping set) of values are used only within the same basic block where they are created.

The theory was that, by encoding this directly in the ISA (input operands were implicit, output operands were the distance in executed instruction stream to the instruction that consumed the result) you'd be able to significantly reduce rename register pressure. Unfortunately, it turned out that speculative execution required you to do something that looked a lot like register rename for these values.

AArch64 intentionally tries to provide a useful common set of fused operations. x86-64 does it largely by accident, but there isn't a clear winner here.

The one big win that we found has not really made it into any instruction set, which continues to surprise me. A cheap way of marking a register as dead can massively improve performance. I've seen a 2x speedup on x86 from putting an xor rax, rax at the end of a tight loop because the pipeline was stalling having to keep all of the old rax values around in rename registers, even though no possible successor blocks used them. If I were designing a new ISA, for high-performance systems I'd be tempted to do one of the following:

• Have a short instruction with a bitmap of dead registers that compilers could insert at end of the basic block for the back arc in a loop to mark multiple registers as dead.
• Put an extra bit in each source operand to mark it as a kill.

The latter hurts density, but would probably be a bigger win because it would let you rewrite a load of operations from allocating rename registers to using forwarding in the front end.

The other bottleneck is parallel decode. A64 ditched the variable-length instruction set that T32 introduced because it makes orthogonal decoding trivial. Fetch 16 bytes, decode four instructions. Apple's implementations make a lot of use of this and also have a nice sideways forwarding path that allows values produced in one instruction to be directly forwarded to a consumer in the same bundle without going via register rename (if the value isn't clobbered, they still need to allocate a rename register).

x86-64 is staggeringly bad here. As Stephen Dolan quipped, x86 chips don't have an instruction decoder, they have an instruction parser. Instructions can be very long, or as short as a single byte. Mostly this doesn't matter on modern x86-64 chips because 90% of dynamic execution is in loops and modern x86-64 chips do at least some caching of decoded things (at the very least, caching the locations of instruction boundaries, often caching of decoded micro-ops) in loops.

And this is where it gets really interesting. The extra decode steps and the extra caches add area, but they also save instruction cache by providing a dense instruction encoding (x86-64 isn't perfect there, it's not that close to a Huffman encoding over common instruction sequences, but it's a moderately good approximation). Is that a good tradeoff? It almost certainly varies between processes (the relative power and area costs of SRAM vs logic vary a surprising amount).

The thing that I find really surprising is the memory model. Arm's weak memory model is supposed to make high-performance implementations easier by enabling more reorderings in the core, whereas x86's TSO is far more constrained. Apple's processors have a mode that (as I understand it) decodes loads and stores into something with the same semantics as the load-acquire / store-release instructions but with the normal addressing modes. It doesn't seem to hurt performance (it's only used by Rosetta 2, so it's hard to do an exact comparison, but x86-64 emulation is ludicrously fast on these machines, so it isn't hurting that much. I'd love to see some benchmarks enabling it by default on everything).

Doing any kind of apples-to-apples comparison is really hard because things in the architecture force implementation choices. You would not implement an x86-64 and an AArch64 core in exactly the same way. There was a paper at ISCA in 2015 that I absolutely hated (not least because it was used to justify a load of bad design decisions in RISC-V) that claimed it did this, but when you looked at their methodology they'd simulated cores that were not at all how you would implement the ISAs that they were discussing.

RE: https://mastodon.acm.org/@ACM/116929782094395296

My short (submitted) feedback on this:

I have stopped reviewing for all ACM publications because of the overwhelming number of plausible-looking papers generated by LLMs where I cannot trust that the results are actually related to having run an experiment. LLMs are destroying the integrity of science conducted by ACM members. The ACM should in no way be encouraging this behaviour.

All of my ACM publications (and I am the author of one of the eight most-downloaded papers in the ACM digital library) are released with a license that requires attribution. LLMs are incapable of guaranteeing attribution with their output. As a result, I regard any training of LLMs on my papers as copyright infringement.

The Free Software movement never escaped from its origins: the early ‘80s MIT AI Lab. Two things were true in this environment:

• Back when most computers had tens of KiBs of RAM and 1 MiB was a huge amount, programs were simple. Very few programs were so complex that one person could not completely understand them.
• The AI Lab was full of some of the most talented programmers in the world.

This meant that the only obstacles for these people being able to fix bugs and add features to any program were access to the source code and the legal rights to modify it. Once you have those, any program was understandable by that group and they could modify it however they wished.

For the next 40 years, the FSF focused on these two things. The world around them changed. These two prerequisites were never enough for most people (what do 90% of computer users do if you give them even a modest 10,000 line C codebase and tell them they can change it however they like?) and now they aren’t enough even for competent programmers.

When Linus says ‘fork it’ to folks who don’t want LLM-extruded code in their kernel, he knows full well that it is almost impossible to fork a 40 MLoC C (and Rust now) codebase that averages more than one CVE per day and have something useful.

The Free Software movement is struggling now because it obsessed over licenses, which was never a path that would succeed, and ignored the hard problems:

• How do you design environments that enable end users to modify their software?
• How do you engineer software so that it is cheap and easy for a random user to maintain a fork that meets their specific needs?
• How do you foster communities where people want to share improvements, so forks don’t proliferate even when it’s easy?
• How do you create an environment where everyone sees the benefits of user-modifiable code to such a degree that trying to sell anything that doesn’t come with these rights is commercially impossible?

Instead of tackling any of these problems, they created more complex and restrictive GPL variants. And well-paid lawyers found loopholes in them that allowed corporations to keep doing what they wanted (and even pick licenses like AGPLv3 to control ecosystems, because they give the copyright owners so many more rights than everyone else that it’s hard for anyone else to compete). They said ‘don’t worry about the complexity of the licenses, you only need to understand the legal details if you’re creating and distributing derived works’ while completely forgetting that making it possible for anyone to create and distribute modified versions of the programs was the entire point of the Free Software movement.

@pikhq

This is why I channel Oscar Wilde:

I hate it when other people agree with me. I always feel I must be wrong.

@JugglingWithEggs

I don’t actually. I want people who can set objectives and find the right experts who can propose policies and evaluate their impact. Who know the difference between a lobbyist and a domain expert.

Oxford PPE graduates are the absolute worst for the treasury because they have no idea about economics but they think they do and so override experts.

I am absolutely shocked to hear that Linus Torvalds has been behaving in the way that he’s been behaving since I first started paying attention to Linux in the late ‘90s.

It’s almost two years since I wrote about setting up CHERIoT so I wasn’t a BFDL, but is somehow seems topical again, for some reason.

#CHERIoT

@whitequark

svgbob looks nice, but depends on a newer version of cargo / rustc than ships in Ubuntu 24.04 (and, of course, it isn't in the Ubuntu packages, because 'work with distributions to get your stuff packaged' is not something the Rust ecosystem likes to do).

EDIT: Wow, the Rust situation on Ubuntu is so much worse than I thought. Ubuntu ships with old Rust that can't compile new things. You can install rustup via a curl | bash thing, but it is an interactive install (not suitable for a container), or via a snap (does not work in a container). Moving on, next option must not require Rust (or must work with early 2024 Rust).

Reminder: in 2025, the UN estimates that spending $93 B / year would be sufficient to end world hunger by 2030. This is roughly a third of the amount of money that companies have set on fire driving the AI bubble.

If anyone is wondering how well ‘AI’ in hiring is going:

My partner just tried putting her CV through some ATS checkers that use LLMs. Her name can be turned into a male name by deleting one letter. Doing so caused her score to jump 10 points.

Anyone using these tools for hiring is going to have some massive discrimination lawsuits in their future.

I have reached the stage of the heatwave where I plug in the air fryer outside so I don’t make the house hotter by cooking.