iiinova — where your digital self keeps evolving

LaurieWired @lauriewired.bsky.social · 22m

Still, very weird to think about randomness itself as an optimizer!  theory.stanford.edu/~aiken/publi...

LaurieWired @lauriewired.bsky.social · 22m

Now it’s not *completely* random, STOKE is a bit more clever than that; they reject bad looking candidates / branches early to save compute time. Thus, significantly more compute is spent on more promising paths.

120

LaurieWired @lauriewired.bsky.social · 22m

I like to imagine a very unusual (but possible!) processor. Custom hardware that does a randomized search for machine-code optimizations with extremely quick formal verification.  A chip solely designed to make the software on…other chips faster!

160

LaurieWired @lauriewired.bsky.social · 22m

Not a bad optimization, but compilation was about uhh…10,000x slower. I do think it’s (at least theoretically) interesting for hot-path optimization, where you might be willing to spend the compilation budget to save a few nanoseconds.

180

LaurieWired @lauriewired.bsky.social · 22m

LLVM -O0 was 116 instructions. Even GCC -O3 was 27 instructions. The tradeoff of course is, insane computational cost. They gave 40 dual core Opteron a budget of 30 minutes of search for each small function. The OpenSSL optimization took about 17 minutes, resulting in a ~1.6x speedup over GCC.

130

LaurieWired @lauriewired.bsky.social · 22m

Sure, 99+% would be incorrect, but there’s a chance you find something interesting!   This was the idea behind STOKE, some Stanford research that, on occasion, would beat out human-written x86 assembly!   For a little snippet of OpenSSL’s big-number library, STOKE found an 11 instruction solution.

150

LaurieWired @lauriewired.bsky.social · 22m

I love that randomness can, in of itself, be a form of computation.   Superoptimization tries to find the best possible machine-code for a given function by searching. A lot.   But what if you just…randomly changed the assembly of a program...

2172

LaurieWired @lauriewired.bsky.social · 09/10/2026

hear me out, what if we just made caches big AND fast

9763

LaurieWired @lauriewired.bsky.social · 07/10/2026

The best source on this story is probably Christopher Joerg’s original Ph. D thesis, “The Cilk System for Parallel Multithreaded Computing”, which also explains the Sandia collaboration in detail. www.bitsavers.org/pdf/mit/lcs/...

0161

LaurieWired @lauriewired.bsky.social · 07/10/2026

Thanks to the Red/Black switching architecture of Paragon, they could pause the classified nuclear yield workloads periodically to let MIT play their chess game.

1141

LaurieWired @lauriewired.bsky.social · 07/10/2026

The funniest conclusion to this story is that MIT brutally lost to the slowest computer in the championship, Fritz 3. A Pentium 90 with 0.09 gigaflops, compared to MIT's ~182 gigaflops. I guess you can steal work (processing)…but they should have stole *work* (better opening strategies).

1211

LaurieWired @lauriewired.bsky.social · 07/10/2026

Of course, there are extra complex factors you have to consider with distributed memory, but the concept of work stealing is still widely used today across many runtimes (Go, Java, V8, etc).

191

LaurieWired @lauriewired.bsky.social · 07/10/2026

Really clever way of doing things; all of the logic happens on the idle cores, so the scheduling overhead is limited to processors that wouldn’t be doing work anyway.

1112

LaurieWired @lauriewired.bsky.social · 07/10/2026

The algorithm is quite fun, because there’s no concept of a centralized scheduler. You just have “thief” cores (idle) steal older tasks (large subtrees) from busy cores, and the busy core switches to a new problem.

1122

LaurieWired @lauriewired.bsky.social · 07/10/2026

With Paragon’s ~1,824 compute nodes, you don’t want a ton of cores sitting idle just because the engine made a stupid predicted move. Turns out, MIT was co-developing a runtime called Cilk prepared for this problem. When you don’t know how much work there is…just steal it!

171

LaurieWired @lauriewired.bsky.social · 07/10/2026

Chess is a really tricky CS problem because of irregular parallelism. Different tasks, aka move branches, have wildly different compute loads because you can’t easily predict which ones will be pruned immediately.

1111

LaurieWired @lauriewired.bsky.social · 07/10/2026

Stealing work isn’t a bad thing.    In Computer Science, it can even be quite good.   In 1995, MIT wanted to win the 8th World Computer Chess Championship…really badly. Somehow, they convinced Sandia to let them borrow Paragon, the 2nd fastest supercomputer, to run their chess engine.

2435

LaurieWired @lauriewired.bsky.social · 05/10/2026

When something starts to get cheap…helps to imagine what would happen when it’s free!

4171

LaurieWired @lauriewired.bsky.social · 05/10/2026

I’m not saying AI is exactly the same problem. But it’s a good idea to look at parallels in history where rapid elimination of constraints changed an industry, and how that industry handled it 5, 10, even 50 years later!

2180

LaurieWired @lauriewired.bsky.social · 05/10/2026

It’s a hunch, but I’d bet that filmmakers closer to the 1970s “ratio explosion” directors handled the later 2000s digital shift *much* better. They’d certainly be ahead of the curve predicting it, and (hopefully) were less surprised when the digital ratios did hit.

1110

LaurieWired @lauriewired.bsky.social · 05/10/2026

Hollywood solved it by throwing massively more resources on the editing side, and editing became a “constantly talking with the director about vision/direction” job, instead of a “hide in the back office and do your work” job.

1130

LaurieWired @lauriewired.bsky.social · 05/10/2026

I’d say, we’re currently in the “1970s Hollywood” of AI. It can be easy (and cheap!) to produce things (code, tools, etc), but YOU have to be the ruthless editor. It’s the “miles of film” problem all over again.

1193

LaurieWired @lauriewired.bsky.social · 05/10/2026

Suddenly…*EVERYONE* starts shooting 100:1. Entire new forms of content get created, like Reality TV, where ratios can hit 500:1! Massive shift of human labor to the editing side.

1110

LaurieWired @lauriewired.bsky.social · 05/10/2026

Until they weren’t.  You can probably guess what happened in the early 2000s. Digital cameras reduced the cost of individual footage to a complete non-constraint. Effectively free, don’t even cut on set, just keep the camera rolling.

1100

LaurieWired @lauriewired.bsky.social · 05/10/2026

Don’t get me wrong. Insane shooting ratios were still *kinda* a niche in the 70s. Traditional directors stuck with only slightly inflated shooting ratios (15:1, 30:1); it was the experimental pioneers (Coppola, Scorsese, etc) that hit the big 100:1 numbers. The huge ratios were still crazy.

1100

LaurieWired @lauriewired.bsky.social · 05/10/2026

A ton of the footage was…trash, of course. But as each individual camera because *less* important, it opened up directors to take on significantly higher risks.

1110

LaurieWired @lauriewired.bsky.social · 05/10/2026

Of course, it also *radically* changed the workflow. Editing use to be the quiet, thankless job in the studio years (30s-50s). Suddenly, they became the most important people on the totem pole! How do you find the masterpiece hiding in the (literal miles) of film?

1120

LaurieWired @lauriewired.bsky.social · 05/10/2026

In the 70s, there was a rapid elimination of production constraints. Film cost and camera portability made the studio rules…obsolete. Why not take multiple angles, roll simultaneously? Have 3, 5, even 10 cameras rolling at once. Shooting ratios *exploded*, 50:1, even 100:1 (Apocalypse Now)!

1100

LaurieWired @lauriewired.bsky.social · 05/10/2026

If you want to know who survives AI, look at what happened to Hollywood in the 1970s.   Movie Studios used to enforce tight “shooting ratios”; usually 5:1, maybe 10:1 TOPS. As in, for every 5 feet of film shot, at least 1 foot had to end up in the final cut (35mm was expensive!)

3527

LaurieWired @lauriewired.bsky.social · 03/10/2026

hmm, in general I'd say the game modding community is pretty interesting when it comes to VR. IMO: non-vr game modded to vr >>> vr-native game! (this goes for any headset)

210

LaurieWired @lauriewired.bsky.social · 03/10/2026

Shame that the space kind of fizzled out…but here’s to hoping there’s a resurgence soon.  There’s got to be other technologies that had an extreme “wow future” moment that never panned out. What would your “oculus” moment be in the 90s, 80s, 70s?

6200

LaurieWired @lauriewired.bsky.social · 03/10/2026

The strongest “I’m living in the future” moment was the First Contact demo on the Oculus CV1 in ~2016 and I’ve been chasing it ever since.   Yeah yeah we’ve got AI and self driving cars and stuff now, but it doesn’t hit the same.

9492

LaurieWired @lauriewired.bsky.social · 02/10/2026

Here's the original 2009 talk that first defined the term "weird machine", give it a look! sergey.cs.dartmouth.edu/hc/rss-hacke...

sergey.cs.dartmouth.edu

0292

LaurieWired @lauriewired.bsky.social · 02/10/2026

Now, can you make a kernel that truly has zero weird machines relative to a formal specification? ….yes, but it wouldn’t look like Linux. It’d look more like sel4, VxWorks, or (shudder) INTEGRITY-178.

2310

LaurieWired @lauriewired.bsky.social · 02/10/2026

Even if you have a million superhuman AI coders and fuzzers thrown at the Linux kernel, you quickly hit halting-problem-esque uncomputable states. The concept of patching every possible bug until none remain isn’t possible, because we can’t often correctly define what a “bug” even is.

1242

LaurieWired @lauriewired.bsky.social · 02/10/2026

Finite code can *easily* have infinite Unintended Behavior (not undefined behavior btw…that’s a very different thing). Weird machines don’t even have to be Turing complete to be, really, really powerful!

1240

LaurieWired @lauriewired.bsky.social · 02/10/2026

It gets a bit philosophical, but there’s the concept of “weird machines”.   A weird machine is an accidental computer located inside of another computer program. Many few exploits (e.g. anything ROP) falls into this category, where the attacker’s ISA consists of fragments of the original software.

1201

LaurieWired @lauriewired.bsky.social · 02/10/2026

The boom in Linux CVEs lately should get you thinking.   Surely, given a finite codebase, there are also a finite number of bugs / unintended behavior, thus, a finite amount of vulnerabilities. Theoretically, a “solvable” problem. Right?   Well…not at all actually.

3887

LaurieWired @lauriewired.bsky.social · 01/10/2026

Oh, and if you’re curious, here’s the link to my TailSlayer project, which I’ve also made a video on:  github.com/LaurieWired/tailslayer

0100

LaurieWired @lauriewired.bsky.social · 01/10/2026

Here’s the link to the paper btw, fun to think about in the big 26, nearly 30 years later!   www.cs.utexas.edu/ftp/dburger/...

1130

LaurieWired @lauriewired.bsky.social · 01/10/2026

What I find interesting is in the present, most redundant processing is in a lockstep / safety sense (aerospace, etc), not a performance / latency sensitive sense.    Weirdly, the technique isn’t that far off from the data racing I did in my TailSlayer project to reduce RAM refresh latency stalls.

1120

LaurieWired @lauriewired.bsky.social · 01/10/2026

...one-way broadcasts, and the other cores get the result without making a conventional remote request.    Today, you’d call it…an odd form of near-data processing.

2140

LaurieWired @lauriewired.bsky.social · 01/10/2026

You deliberately waste (tons) of CPU cycles, on an otherwise unaware application, where the CPU that “wins” is whichever one happens to be closer to the memory that’s needed. Instead of designing a better prefetcher, you race all the threads against each other, the winner (local memory owner)...

1140

LaurieWired @lauriewired.bsky.social · 01/10/2026

You trade excess threads for reduction of data movement. But *unlike* multithreading the way we think today, you’d have redundant, sequential programs running multiple times.   At the time, DataScalar was making the (risky!) bet that future processors would have arithmetic become virtually free.

1140

LaurieWired @lauriewired.bsky.social · 01/10/2026

I stand by that some of the best ideas in Computer Science can be found from failed research of the late 90s.    DataScalar is no longer around, but they would have made a killing today.    They created an architecture which was, to put it simply, a memory centric execution model.

1722

LaurieWired @lauriewired.bsky.social · 29/09/2026

Not just limited to C++ either; this concept is easily extended to many other (including runtime!) languages.  Full Talk:  www.youtube.com/watch?v=Scwv...

youtube.com

The Address is Not The Place: Object Residency in C++26 - Laurie Kirk - CppCon 2026

YouTube video by CppCon

1211

LaurieWired @lauriewired.bsky.social · 29/09/2026

Hope this talk gets more people thinking about the concept of object “wherency”, and especially what that mental model could look like in various languages. I wrote my demonstrator as a C++26 native implementation; curious to see what others will come up with.

170

LaurieWired @lauriewired.bsky.social · 29/09/2026

My CppCon Keynote, “The Address is Not The Place” is now up on YouTube! It’s not often that we get new tiers added to the memory hierarchy of computing, but it sure is fun! You can certainly get ahead of the curve by thinking about the programmatic challenges (and possibilities) this will cause.

1746