LaurieWired's Avatar

LaurieWired

@lauriewired.bsky.social

researcher @google; serial complexity unpacker ex @ msft & aerospace

5,421 Followers  |  1 Following  |  973 Posts  |  Joined: 20.11.2024
Posts Following

Posts by LaurieWired (@lauriewired.bsky.social)

hmm, interesting, but it does seem like a bit of funny marketing ha.

L0 seems to be a renamed, more efficient L1

02.03.2026 18:55 — 👍 0    🔁 0    💬 0    📌 0
Post image

The logic was essentially, hey system fonts are pretty good now…why not just default to what’s native?



Apple get’s apple fonts. Windows get’s windows fonts.



There’s a great blogpost from Mark Otto, GitHub’s director of design about the switch:

markdotto.com/blog/github-...

02.03.2026 18:45 — 👍 24    🔁 0    💬 1    📌 0
Post image

Hence, the early web was very…Times New Roman-y.



Github was arguably one of the first major players to go *against* the custom font / FOUT hell of the mid 2010s.



In mid 2017, they essentially re-adopted the 90s method of using direct system fonts!

02.03.2026 18:45 — 👍 21    🔁 0    💬 2    📌 0
Post image Post image

FOUTs were essentially unheard of in the 90s. 

The entire world basically defaulted to web-safe fonts.


In the rare instance someone got fancy with something non-standard, the browser would just fallback to a default.


This didn’t really change until 2010!

02.03.2026 18:45 — 👍 14    🔁 0    💬 1    📌 0
Post image

First, ignore JavaScript for a second.


Even with plain HTML+CSS, it’s quite common to get FOUTs these days.


FOUT = Flash of Unstyled Text.

AKA temporarily load a system-native font, then when the custom font finally rolls in, "snap" to the new font.

02.03.2026 18:45 — 👍 13    🔁 0    💬 1    📌 0
Video thumbnail

Websites today load wildly differently than in the 90s.

Arguably, worse.

The HTML spec was designed to be read sequentially, so text used to stream in, then display instantaneously. Basically, read -> paint.

A lot of today’s modern weirdness comes from…fonts.

02.03.2026 18:45 — 👍 50    🔁 1    💬 3    📌 0

From AMD, more on the performance side:

“Improving the Utilization of Micro-operation Caches in x86 Processors”



The other is more security angle + some interesting timing attacks:

“UC-Check: Characterizing Micro-operation Caches in x86 Processors and Implications in Security and Performance”

27.02.2026 19:42 — 👍 25    🔁 1    💬 2    📌 0
Post image

The smaller pieces are thus able to fit entirely in the uOP cache, avoiding thrashing the decoder constantly.

There are quite a few papers on the subject, but these two give a really nice overview:

27.02.2026 19:42 — 👍 21    🔁 0    💬 1    📌 0
Post image

99% of programmers shouldn’t care; but those who squeeze the absolute maximum last bit of performance out of x86 pay attention.


Loop Fission is an interesting technique, where you spit up a complex loop into multiple smaller sequential ones.

27.02.2026 19:42 — 👍 20    🔁 0    💬 2    📌 0
Post image

x86 “looks” CISC, but all of the engine is RISC underneath.

You don’t *want* to wake up the decoder if you don’t have to. It wastes about ~6 cycles + extra power.

Usually, the compiler aligns everything for you...as long as your loop is small enough.

27.02.2026 19:42 — 👍 19    🔁 0    💬 1    📌 0
Post image

There is one problem though.



You can’t see it.



Well, not directly at least. You’ll never find uOPs in the binary.



But! You can see the “shape” of it with performance tools…and there are subtle tells in the binary as well (hint, some nops).

27.02.2026 19:42 — 👍 21    🔁 0    💬 3    📌 0
Post image Post image

Most programmers are taught that L1 is the “top level” cache on x86.


It’s not quite true anymore!


Intel calls it the Decoded Stream Buffer (DSB), AMD the OpCache.

Only enough room for ~4,000 micro-ops, but there are interesting ways to take advantage of it.

27.02.2026 19:42 — 👍 149    🔁 18    💬 4    📌 1

hahaha

25.02.2026 22:13 — 👍 1    🔁 0    💬 0    📌 0
Preview
Random number generators: good ones are hard to find | Communications of the ACM Practical and theoretical issues are presented concerning the design, implementation, and use of a good, minimal standard random number generator that will port to virtually all systems.

(side note: most rand() implementations moved on to other LCGs, or mersenne twisters and such…but it’s arguable that 16807 is still quite ubiquitous!)

Original Paper if you’d like to read:
dl.acm.org/doi/10.1145/...

25.02.2026 22:13 — 👍 31    🔁 0    💬 2    📌 0
Post image

It’s kind of funny that so few listened. FreeBSD was still using 16807 in rand() all the way until 2021!



So if you ever see that constant in disassembled code…now you know :)

25.02.2026 22:13 — 👍 41    🔁 0    💬 2    📌 0
Video thumbnail

That fits nicely in 32-bit hardware. Only a few instructions.



Apple put it in CarbonLib, FreeBSD also used it; for a few decades it was kind of everywhere.



A few years later they discovered that 48271 was a little better.

Specifically, a bit more even on spectral tests up to 6 dimensions.

25.02.2026 22:13 — 👍 24    🔁 0    💬 2    📌 0
Post image

They weren’t really trying to make a perfect algorithm; it was more about being “reasonably good and efficient”.

Called the minimal standard, it’s a quick little multiplication routine, just one line:

x = seed × 16807 mod 2^31 - 1

25.02.2026 22:13 — 👍 25    🔁 0    💬 1    📌 0
Post image Post image

Today it feels trivial, but for decades random number generation was REALLY bad. Mostly IBM's fault.


Two researchers, Park + Miller got so sick of bad RNGs, they released a paper to the ACM in 1988 titled:


"Random Number Generators: Good Ones Are Hard to Find."

25.02.2026 22:13 — 👍 29    🔁 0    💬 1    📌 0
Post image Post image

16807 is a very special number in Computer Science.



You can find it in the Playstation 5 (freebsd 11), almost every Mac Classic game, and even the C++11 standard!


Give it the right prime number, you can produce an evenly distributed sequence for over 2 BILLION values.

25.02.2026 22:13 — 👍 104    🔁 14    💬 2    📌 0
Post image Post image

The original title of the paper if you want to search:


“Implications of the Turing completeness of reaction-diffusion models, informed by GPGPU simulations on an XBox 360: Cardiac arrhythmias, re-entry and the
Halting problem”

23.02.2026 19:27 — 👍 28    🔁 2    💬 0    📌 0
Post image

Boom. Thousands of simulated cardiac cells running at high speed on a single box.



A fun benefit, you get visualizations for “free” by tacking on a little render code to the end of the sim.



It’s certainly an entertaining read, even if the utility is questionable.

23.02.2026 19:27 — 👍 17    🔁 0    💬 1    📌 0
Post image

So why the Xbox 360?



Mostly, computational bang for the buck…I also speculate they were trying to be funny. Consoles were somewhat lopsided in that era, you genuinely got a ton of compute if you knew how to use it.

The author writes some C++ for the simulation, ports some of it to HLSL shaders.

23.02.2026 19:27 — 👍 15    🔁 0    💬 2    📌 0
Post image

Now that you’ve proven cardiac tissue is Turing complete, uh oh, it’s vulnerable to the Halting problem.

Thus, there is no general algorithm that can look at the state of cardiac tissue and decide if it will ever stop.

Arrhythmias are fundamentally uncomputable!

23.02.2026 19:27 — 👍 16    🔁 3    💬 1    📌 1
Post image Post image

The author figured out you can build a NOR gate from heart cells.


NOR is a universal gate, so you can build all the other gates out of NORs.


Thus, arbitrary logic circuits, plus time…boom you have a computer.

But wait! Computers have interesting properties:

23.02.2026 19:27 — 👍 12    🔁 0    💬 2    📌 0
Post image Post image

The human heart is a Turing Machine.

Researchers figured it out with an Xbox 360.


I realize how fake that sounds...but it’s real research published in Elsevier's Computational Biology and Chemistry journal in 2009.

Hearts are electrically excitable media.

23.02.2026 19:27 — 👍 77    🔁 8    💬 5    📌 2
Post image

god i wish there was an easier way

21.02.2026 08:21 — 👍 133    🔁 3    💬 13    📌 0

what do you mean by detector? like the actual image sensor?

I'm unfamiliar with the astrophotography world so I'm not sure how big they really get.

The physically largest image sensors I've seen are medium format...but I'm sure they go larger for other applications

19.02.2026 20:11 — 👍 2    🔁 0    💬 1    📌 0

Probably the most comprehensive paper I’ve seen on the overall subject of sensor noise is from MDPI, “The Geometry of Noise in Color and Spectral Image Sensors”



Check it out here:

www.mdpi.com/1424-8220/20...

19.02.2026 19:27 — 👍 19    🔁 0    💬 1    📌 0
Video thumbnail

Mark Shelley, an astrophotography enthusiast, has amazingly detailed reverse engineering writeups on his blog about various sensor issues.



Please check it out, it’s super cool:
www.markshelley.co.uk

19.02.2026 19:27 — 👍 27    🔁 0    💬 1    📌 0
Post image

When you prefer a “Canon color”, what you are technically valuing is whatever compromises were made in the processing pipeline.



I’ve just *barely* scratched the surface; haven’t even touched on codecs.

Fascinating how much diversity is still there to be pushed using…extremely similar “engines”.

19.02.2026 19:27 — 👍 19    🔁 1    💬 1    📌 0