boricj

Looking at the specs: 32 KiB of L1, 256 KiB of L2, in-order and partial dual-issue.

That's the least forgiving kind of chip when it comes to performance: fast enough to outpace main memory by two orders of magnitude, yet the slightest speed bump (branch misprediction, cache miss) stalls it without any ability to reorder around it.

I work with another team at work that uses lots of message passing, C++ virtual methods in deeply nested class hierarchies, large DOMs and off-the-shelf C++ STL containers... on a STM32MP1, which has an in-order Cortex-A7 and a pittance of cache.

On the other hand, in my team I wrote my custom C++ STL containers that allocate inline, SAX-style processing libraries and an object pool with links that use index+generations like 2000s video games... on a STM32H5 with less than a megabyte of RAM.

Mechanical sympathy feels like a lost art to people I demonstrate it to... and I had to demonstrate to the first team with benchmark numbers that I would not be the bottleneck between us by orders of magnitudes.

That sounds like Emacs. Wouldn't know though, given that I dislike vim too.

I would prefer ms-edit or nano if I have to edit text files from the terminal.

I've built a niche Ghidra extension that managed to form a userbase. Haven't put much effort into publicizing it, it just kinda snowballed on its own through word-of-mouth. In fact, I keep stumbling into Discord forums where I then learn that I had users there that I've never heard about before.

Word-of-mouth happens when someone who has a need finds your project, uses it and likes it so much they talk about it to other potential users. It's effectively a chain reaction and the way to leverage it is to make something people want to use.

Just because coding agents can multiply our productivity doesn't mean that we should reduce ourselves to shoddy engineering, on the contrary.

In fact, I see this as an opportunity to build anew and better. When you're no longer constrained by legacy baggage and constraints, you can collapse layers and introduce new ones that better fit what you're creating.

I'm doing that in the project I'm working on at work. Being able to redefine how serialization/deserialization fundamentally works and interacts with domain objects is giving us unbelievable expressiveness, not by the amount of code written (in fact, it's heavily factorized across layers that were historically separate), but by exploring new designs paradigms.

Don't just read these books. Write some new ones.

> In a normal world, this would be treason by an illegal immigrant to the US.

Not a lawyer, but wouldn't an illegal immigrant owe no allegiance to breach and therefore couldn't commit treason?

Not a cryptographer, but I wonder if some sort of basic statistical fingerprinting of the private key being checked at every step of its manipulation during the ceremony would have caught this epic operational failure.

Say, like a multi-scale hierarchical half popcount vector (first/second half, first quarter+third quarter/second quarter+fourth quarter down to odd/even bits), where fumbling one private key for another or xkcd-ing 4 as a private key would be detected, but still reveal no information on a truly random series of bits and be understandable by non-technical people in the room.

One chamber is enough to play Russian roulette... once. However, the probability to get to play a second time is rather slim.

If a product never got a firmware update during its support window, was it ever supported to begin with?

> I've always been amazed why the 2CV is seen as a styling icon.

You could ask the same about the Opinel No. 8 knife. Same thing since 1890s, one minor update every 50 years or so. It's still sold by the bucketload today for about €10.

It's just French, the same way a Lada is just Russian, a Mini Cooper is British or a Fiat 500 is Italian. It's part of post-WW2 cars that were cheap to buy, cheap to operate, cheap to fix and with production numbers in the millions.

Meh, it's not ideal but it's not that bad either.

I'm working on an embedded system with a MCU and I've benchmarked JSON serialization at over 500 KiB/s (through a HTTP GET request) using my own library. Deserialization is slower, but that's partly because I have super-linear algorithms downstream of the parsing.

CBOR is much nicer and faster to work with (smaller documents, definite length strings directly consumable) and I do support it in my library, but I derive most of my performance gains by ditching DOM-style APIs and using stream processing instead. Allocating nodes and chasing pointers all over the heap sucks for performance, especially for large documents, regardless of the format (and that's assuming it even fits within available RAM).

> Yet the C code can’t pick what registers to use, so the poor agent is probably shuffling the code around randomly for hours or days until it matches.

Humans too do that for matching decompilation. Or at least I imagine so, given that I personally refuse to do that.

People have different goals and will use different techniques to achieve them. The video game reverse-engineering/decompilation community isn't a hive-mind, I went ahead and created ghidra-delinker-extension because I had my own ideas on how to do that.

That reminds me of some of the tricks I've used while tinkering with a voxel space rendering tech demo on the PlayStation.

The quirks of that console for this is that the CPU takes a 6 cycle stall on any read from main RAM (it's not even stall-on-use) and doesn't have a data cache. That would make it a very poor fit for this, so I had to improvise a bunch of tricks to reclaim performance:

- Made all of my hot loop fit within one function, so that it fits entirely in the 4 KiB direct-mapped instruction cache (so less than 1024 instructions)

- Wrote a C++ template that can trampoline a function call into the 2 KiB scratchpad

- Used the rest of the scratchpad for a CLUT table because it doesn't stall on read

- Used the GTE to transform the N set of coordinates while the CPU stalls fetching the N+1 set of heightmap data

- Figured ways to abuse the GTE into transforming more points per instructions than it theoretically can, taking advantage of simplified formulas compared to real 3D projection

- Write the rectangle primitives straight to the GPU registers instead of going through a display list

It's such an abuse of the PlayStation that PCSX-Redux and DuckStation disagree on its performance by up to a factor of two. I should finish it someday and see how it runs on real hardware...

It's not just about treasure bonds. The mood is shifting in Europe that, maybe, putting all the eggs in the USA basket is perhaps not that great of an idea.

It's the vindication of Gaullism half a century after De Gaulle's death, the concept of strategic autonomy is getting traction in the rest of Europe. It's not that we can't be friends, but that we shouldn't let our future be gambled in the hands of Wisconsin voters every two years.