diff --git a/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/2025-08-20-AgileJebrim-another-one-here-https-github-com-cloudcores.md b/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/2025-08-20-AgileJebrim-another-one-here-https-github-com-cloudcores.md
new file mode 100644
index 0000000..d4a7cdb
--- /dev/null
+++ b/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/2025-08-20-AgileJebrim-another-one-here-https-github-com-cloudcores.md
@@ -0,0 +1,39 @@
+---
+title: "@FUZxxl @JamesAnder73326 Another one here:"
+type: archive
+source: twitter
+source_url: "https://x.com/AgileJebrim/status/1958211618241904678"
+author: "Jebrim"
+handle: AgileJebrim
+post_id: "1958211618241904678"
+date: 2025-08-20
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - FUZxxl
+description: "@FUZxxl @JamesAnder73326 Another one here:"
+in_reply_to: ""
+parent_post_id: "1958211444987789763"
+---
+
+## Source
+
+- URL: https://x.com/AgileJebrim/status/1958211618241904678
+- Author: Jebrim (@AgileJebrim)
+- Posted: 2025-08-20 16:56:46
+
+## Branch
+
+**1/** **@AgileJebrim** ^1958211618241904678
+
+**@FUZxxl** **@JamesAnder73326**
+
+Another one here:
+
+https://github.com/cloudcores/CuAssembler
+
+## Related
+
+- Spine: [[archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for]]
diff --git a/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/index.md b/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/index.md
new file mode 100644
index 0000000..c3b6bd8
--- /dev/null
+++ b/archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/index.md
@@ -0,0 +1,104 @@
+---
+title: "Is there an introduction to GPU programming for the seasoned assembly programmer?  All tutorials I can find start with a dozen layers of abstraction and never really seem to get down to the metal."
+type: archive
+source: twitter
+source_url: "https://x.com/FUZxxl/status/1957729589326709116"
+author: "Robert Clausecker"
+handle: FUZxxl
+post_id: "1957729589326709116"
+date: 2025-08-19
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - FUZxxl
+description: "Is there an introduction to GPU programming for the seasoned assembly programmer?  All tutorials I can find start with a dozen layers of abstraction and never really seem to get down to the metal."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/FUZxxl/status/1957729589326709116
+- Author: Robert Clausecker (@FUZxxl)
+- Posted: 2025-08-19 09:01:21
+
+## Thread
+
+**1/** **@FUZxxl** ^1957729589326709116
+
+Is there an introduction to GPU programming for the seasoned assembly programmer?  All tutorials I can find start with a dozen layers of abstraction and never really seem to get down to the metal.
+
+**2/** **@FUZxxl** ^1957733225297580231
+
+Ideally I'd want to program the GPU in assembly, but I have been repeatedly told that this is not how you do things on GPUs and that you shall go through the abstraction layer for it is blessed yadda yadda
+
+**3/** **@AgileJebrim** ^1957762928129495481
+
+Unlike CPUs that have maintained a stable ISA for decades, GPU ISAs are in constant flux (and are not publicly documented in the case of NVIDIA and Apple). They vary significantly between vendors and even generations of hardware from the same vendor. This means you essentially have to work at the IR level for portability purposes.
+
+These are a few choices: PTX (CUDA), SPIR-V (Vulkan), DXIL (Direct3D), HIP (ROCm), and NIR (Mesa3D).
+
+If you really want to write GPU assembly for one very specific card, bypassing even the IR, then AMD is the probably the easiest available to do so with. They publicly publish their ISA and open source drivers exist to read from and modify.
+
+The easiest way in my head to do something like this in user space would be to identify the code in one of these drivers that generates the pipeline caches when compiling Vulkan SPIR-V shaders. Extract that out as an offline application and then you ought to be able to embed GPU ISA-specific code directly into a pipeline cache binary that can then be loaded directly into Vulkan on another machine with identical hardware and drivers.
+
+Probably not worth it in practice though due to how limiting that is and how quickly it’ll become obsolete. Even a driver update can break that. I’ve personally just embraced working with SPIR-V instead. It’s very portable, is popular, and has a long life ahead of it that is matched only by NVIDIA’s PTX.
+
+SPIR-V is better for real-time graphics and compute workloads. PTX is generally used in offline HPC workloads. There is also an extension available to use PTX from within Vulkan but there’s some lack of tooling support due to how niche that is. I don’t know of any project actually using it.
+
+Another thing to note about SPIR-V vs PTX is that the former is stored as a 32-bit word bytecode, whereas the latter is straight up ASCII. It does, however, provide some lower level access to NVIDIA-specific cache controls, guard predicates, and other features that may not be available to SPIR-V.
+
+Let me know any other questions you might have.
+
+**4/** **@JamesAnder73326** ^1957911572795244920
+
+**@AgileJebrim** **@FUZxxl**
+
+can you respond to this @FUZxxl instead of sperging out at other people cause this is what you wanted to know right?
+
+**5/** **@AgileJebrim** ^1957915096060928106
+
+**@JamesAnder73326** **@FUZxxl**
+
+He might like the Vulkan + PTX combo with compute shaders. It’ll him get the closest to the hardware that he’s looking for if he’s got an NVIDIA GPU. More importantly, it’s something that shouldn’t take an enormous amount of time trying to get set up.
+
+https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_cuda_kernel_launch.html
+
+**6/** **@JamesAnder73326** ^1958200864377606476
+
+**@AgileJebrim** **@FUZxxl**
+
+ngl man I feel bad you wrote out all this stuff for a retard that's ragebaiting without even having Twitter blue
+
+**7/** **@FUZxxl** ^1958201341521629544
+
+**@JamesAnder73326** **@AgileJebrim**
+
+If you feel I'm ragebaiting you, that says more about than anything.  I just want to program my GPU in assembly, how hard can it be?
+
+**8/** **@AgileJebrim** ^1958204246265856288
+
+**@FUZxxl** **@JamesAnder73326**
+
+Reverse engineer (or find an open source tool to generate) a pipeline cache binary for a specific piece of hardware/driver, create an assembler for that, and submit it to Vulkan. That’s my final answer. That’s as low level as you can go.
+
+**9/** **@FUZxxl** ^1958204515288551711
+
+**@AgileJebrim** **@JamesAnder73326**
+
+People have done that before, with great success.  However, the resources remain scattered about and sparse.  Hence my question asking for a good tutorial.
+
+**10/** **@AgileJebrim** ^1958211355170963716
+
+Within Mesa3D, you have RADV, AMDVLK, and NVK as open source options. The first two for AMD, the latter for NVIDIA. They take SPIR-V and output GPU ISA and pipeline cache binaries. They’re not designed to work as custom assemblers and you’d have some work to try to extract the code within to create an assembler for a specific GPU ISA.
+
+**11/** **@AgileJebrim** ^1958211444987789763
+
+**@FUZxxl** **@JamesAnder73326**
+
+In the CUDA world, there do appear to be some open source tools available:
+
+https://github.com/daadaada/turingas
+
+Branches: [[archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for/2025-08-20-AgileJebrim-another-one-here-https-github-com-cloudcores]]
diff --git a/archive/threads/FUZxxl/index.md b/archive/threads/FUZxxl/index.md
new file mode 100644
index 0000000..1674e22
--- /dev/null
+++ b/archive/threads/FUZxxl/index.md
@@ -0,0 +1,12 @@
+---
+title: FUZxxl
+type: note
+draft: false
+description: Archived threads by FUZxxl.
+tags:
+  - archive
+  - twitter
+  - FUZxxl
+---
+
+- [[archive/threads/FUZxxl/2025-08-19-is-there-an-introduction-to-gpu-programming-for]]
diff --git a/archive/threads/OSdev_/2026-08-25-how-does-aslr-interact-with-pe-relocations-during/index.md b/archive/threads/OSdev_/2026-08-25-how-does-aslr-interact-with-pe-relocations-during/index.md
new file mode 100644
index 0000000..5f0616a
--- /dev/null
+++ b/archive/threads/OSdev_/2026-08-25-how-does-aslr-interact-with-pe-relocations-during/index.md
@@ -0,0 +1,44 @@
+---
+title: "How does ASLR interact with PE relocations during Windows process startup? Suppose a DLL was linked with a preferred base address, but ASLR causes it to be mapped somewhere else."
+type: archive
+source: twitter
+source_url: "https://x.com/OSdev_/status/2092211719628050708"
+author: "OS Dev"
+handle: OSdev_
+post_id: "2092211719628050708"
+date: 2026-08-25
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - OSdev_
+description: "How does ASLR interact with PE relocations during Windows process startup? Suppose a DLL was linked with a preferred base address, but ASLR causes it to be mapped somewhere else."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/OSdev_/status/2092211719628050708
+- Author: OS Dev (@OSdev_)
+- Posted: 2026-08-25 11:25:20
+
+## Thread
+
+**1/** **@OSdev_** ^2092211719628050708
+
+How does ASLR interact with PE relocations during Windows process startup? Suppose a DLL was linked with a preferred base address, but ASLR causes it to be mapped somewhere else. What exactly must the Windows loader change, and why? Also, what happens if the image has no relocation information?
+
+**2/** **@HostOfMeta** ^2092224460384333945
+
+I just realized this works like address fixups in loading certain data formats. But here instead of an engine knowing the file format and relying on content being baked for 32-bit or 64-bit, it uses the .reloc section to know every site in the binary where the base address gets used and inserts an offset, the delta between the original base address and the one being randomized.
+
+When the .reloc is present, every use of the base address has a baked-in +0 offset in the binary, ready to be patched up. That leaves every relative addressing intact in the loaded binary. Only minimal work needed, the process just runs through a list of binary offsets and writes the base address delta there naively.
+
+Without a .reloc, it works like loading an opaque blob of data: we can only guess, which is unsafe, load it as-is, or fail the load entirely. Similar to intermediate tools processing baked assets without touching their data. Or HTTP proxies leaving everything they don't know how to read as passthrough.
+
+**3/** **@OSdev_** ^2092266048473166261
+
+**@HostOfMeta**
+
+Yep, that's basically right. ".reloc" gives the loader an explicit map of base-dependent sites to patch with the ASLR delta, while relative addressing stays intact. Without that metadata, the loader cannot safely know what should be treated as an address and modified.
diff --git a/archive/threads/OSdev_/index.md b/archive/threads/OSdev_/index.md
new file mode 100644
index 0000000..e9a7cd6
--- /dev/null
+++ b/archive/threads/OSdev_/index.md
@@ -0,0 +1,12 @@
+---
+title: OSdev_
+type: note
+draft: false
+description: Archived threads by OSdev_.
+tags:
+  - archive
+  - twitter
+  - OSdev_
+---
+
+- [[archive/threads/OSdev_/2026-08-25-how-does-aslr-interact-with-pe-relocations-during]]
diff --git a/archive/threads/_Felipe/2026-08-26-before-mastering-simd-you-have-to-master-loop/index.md b/archive/threads/_Felipe/2026-08-26-before-mastering-simd-you-have-to-master-loop/index.md
new file mode 100644
index 0000000..06b85b8
--- /dev/null
+++ b/archive/threads/_Felipe/2026-08-26-before-mastering-simd-you-have-to-master-loop/index.md
@@ -0,0 +1,102 @@
+---
+title: "Before mastering SIMD you have to master loop unswitching"
+type: archive
+source: twitter
+source_url: "https://x.com/_Felipe/status/2092653743779069989"
+author: "Felipe O. Carvalho"
+handle: _Felipe
+post_id: "2092653743779069989"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - _Felipe
+description: "Before mastering SIMD you have to master loop unswitching"
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/_Felipe/status/2092653743779069989
+- Author: Felipe O. Carvalho (@_Felipe)
+- Posted: 2026-08-26 16:41:46
+
+## Thread
+
+**1/** **@_Felipe** ^2092653743779069989
+
+Before mastering SIMD you have to master loop unswitching
+
+![](https://pbs.twimg.com/media/HQqZfHiWAAAJmBs?format=jpg&name=orig)
+
+**2/** **@nicbarkeragain** ^2092725850181607870
+
+**@_Felipe**
+
+The responses here saying the compiler does it for you are all assuming it’s a simple boolean in the conditional. If it’s remotely complex (function call etc) the compiler won’t touch it as it might produce different results each iteration.
+
+**3/** **@Lucrecious_** ^2093132360388886820
+
+Yes - it's better to unswitch loops, but looking at the metrics for this, it doesn't seem like it makes *that* much of a difference until you get into an absurd amount of iterations.
+
+Still learning about this type of stuff, so I'm sorry if I'm off-base here or if I'm misunderstanding the purpose of the post. 
+
+Here's the code I used:
+https://pastecode.io/s/27hpiw45
+(I'm open to this not being a great benchmarking technique, but if there are better ways to do this, would love to learn!)
+
+I tried with different Ns, the highest being 1 billion iterations. In all cases, the overall processing time was pretty short; ~1 second.
+
+For N = 1 billion I got:
+Inner Loop Conditional: ~1600ms
+Outer Loop Conditional: ~1400ms
+
+That's like a ~10% performance win which, admittedly, is very good, but only 200ms faster total on a billion iterations.
+
+With smaller Ns, the performance gained varied. At its best, outer conditional was 20% faster, but that was only ~20ms faster compared to the inner conditional.
+
+These functions are also doing very little work - I feel like the conditional check could easily be overshadowed by the actual work being done in the branches, no?
+
+OP doesn't specify what f and g are - they could be doing anything. Like, in a real program, wouldn't f and g be doing more work? 
+
+I tried it by generating random numbers inside f and g and the difference between the outer and inner conditional was even smaller. We're talking <1% difference.
+
+If you're doing a function call instead of a variable check for the flag, things would be different, but I think that's a different issue entirely. I thought OPs snippet was getting at unnecessary branching in a loop rather than unnecessary function calls in a loop.
+
+If this is for optimizing for SIMD, this seems sort of obvious to anyone that knows anything about it? Not sure why it needs to "mastered".
+
+Yes, one is better than the other, but in OP's example, it's very easy to pull the conditional outside the loop. In real code, it might not be so trivial to do; and without benchmarking your specific case, can we really say this is worth doing in a rule-of-thumb type of way? 
+
+I'm genuinely curious in what scenarios we should care about this. It seems like it only matters in really trivial and obvious cases, like filling giant arrays or doing very simple high-iteration calculations. As soon as f or g is doing any significant amount of work, the conditional check seems inconsequential to the overall performance.
+
+Where's my knowledge gap on this? Genuinely curious, because I see a lot of "you should do this instead of that" on here but without any metrics or real examples...
+
+**4/** **@nicbarkeragain** ^2093150794032046345
+
+Great that you're digging into it and questioning, that's super important 🙂
+As with everything performance related, there's the lottery involved and it's very hard to microbench something trivial like this. Rather than only observing the test run time (which could be affected by a huge number of things) it's important to actually look at the compiler output - if both of your cases are being vectorised then the compiler is being smart and there's significantly less to gain from doing this manually, but that's not guaranteed.
+Re: the post, I've personally found that it's almost impossible to get both meaningful and educational code samples into a single screenshot when it comes to performance, because in order to make it clear and easy to understand it needs to be simple, but the compiler works really well on trivial cases, and falls apart in unpredictable ways on more complex ones.
+You're pretty much exactly on the right track in that the cost of the branch by definition won't be significant, because it needs to be invariant to be even possible to hoist out of the loop in the first place, but if it's invariant that means it's 100% predictable and will cost almost nothing. So my general assumption here was that "flag" was just a stand-in for "some expression inside a conditional", and at a higher level it's just advice to start to develop the pattern recognition for loop invariant reads (hoisting invariants also results in code that is easier to reason about IMO)
+From a more realistic performance perspective:
+- It's hard to know from just eyeballing whether a compiler is going to be able to successfully vectorise a loop body, you really need to be looking at the actual compiler output of your specific case while making tweaks until it looks how you expect
+- If the data read by the rest of the loop body after the branch is enough to nuke your entire L1, the branch condition lookup is going to be (another) cache miss, and I really couldn't tell you for certain how that's going to interact with the branch prediction latency at high throughput. Maybe it would be hidden, maybe an l1 miss would still cause some stall. YMMV 🙂
+
+> If this is for optimizing for SIMD, this seems sort of obvious to anyone that knows anything about it?
+
+My read on this was to try to be a bit generous with the interpretation - removing loop invariant branches actually is an important step to getting the compiler to auto vectorise, and when I first learned it, it wasn't super obvious to me before someone more senior pointed it out 🙂
+
+**5/** **@Lucrecious_** ^2093228771155329294
+
+I appreciate the response!
+
+You're right - the more I look into it, the more nuanced it becomes. Not so simple to measure.
+
+Funnily enough, this post inspired me to experiment with performance optimization today (trying to learn).
+
+I was trying to read 10GBs of data into memory as fast as possible, and, although my NVMe's theoretical read is 5GB/s, trying to get anywhere near the ballpark of 2 seconds to load does not seem trivial at all. Small adjustments, like read buffer size, can have quite significant effects on performance (like 20s to 13s type of stuff).
+
+I mention that because despite me thinking I had a pretty good idea of what was going on behind the scenes, I was met with a lot of unexpected results. It put into question my benchmarks for this - are they even timing the right thing? Is there code in there that I think is inconsequential but actually isn't? Does the timing even mean anything?
+
+All very interesting...
diff --git a/archive/threads/_Felipe/index.md b/archive/threads/_Felipe/index.md
new file mode 100644
index 0000000..6242927
--- /dev/null
+++ b/archive/threads/_Felipe/index.md
@@ -0,0 +1,12 @@
+---
+title: _Felipe
+type: note
+draft: false
+description: Archived threads by _Felipe.
+tags:
+  - archive
+  - twitter
+  - _Felipe
+---
+
+- [[archive/threads/_Felipe/2026-08-26-before-mastering-simd-you-have-to-master-loop]]
diff --git a/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/2024-03-13-Samueltates-ive-definitely-overindulged-in-oops-delights-to.md b/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/2024-03-13-Samueltates-ive-definitely-overindulged-in-oops-delights-to.md
new file mode 100644
index 0000000..acf7213
--- /dev/null
+++ b/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/2024-03-13-Samueltates-ive-definitely-overindulged-in-oops-delights-to.md
@@ -0,0 +1,37 @@
+---
+title: "@_rygo6 I’ve definitely overindulged in OOPs delights, to my own chagrin when tracing, and you’re right that the hierarchy is there whether it’s linear in visualising."
+type: archive
+source: twitter
+source_url: "https://x.com/Samueltates/status/1767856750135542063"
+author: "Samuel Tate Goudie"
+handle: Samueltates
+post_id: "1767856750135542063"
+date: 2024-03-13
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - _rygo6
+description: "@_rygo6 I’ve definitely overindulged in OOPs delights, to my own chagrin when tracing, and you’re right that the hierarchy is there whether it’s linear in visualising."
+in_reply_to: ""
+parent_post_id: "1767783595899515341"
+---
+
+## Source
+
+- URL: https://x.com/Samueltates/status/1767856750135542063
+- Author: Samuel Tate Goudie (@Samueltates)
+- Posted: 2024-03-13 10:14:29
+
+## Branch
+
+**1/** **@Samueltates** ^1767856750135542063
+
+**@_rygo6**
+
+I’ve definitely overindulged in OOPs delights, to my own chagrin when tracing, and you’re right that the hierarchy is there whether it’s linear in visualising. Perhaps it emerged as systems began to serve literally seperate apps, services, modularised to package and distro?
+
+## Related
+
+- Spine: [[archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about]]
diff --git a/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/index.md b/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/index.md
new file mode 100644
index 0000000..d6e5277
--- /dev/null
+++ b/archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/index.md
@@ -0,0 +1,46 @@
+---
+title: "One of the things I probably loathe most about the mentality of OOP that got pushed on the industry is that you need a different file for every object."
+type: archive
+source: twitter
+source_url: "https://x.com/_rygo6/status/1767783595899515341"
+author: "rygo6"
+handle: _rygo6
+post_id: "1767783595899515341"
+date: 2024-03-13
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - _rygo6
+description: "One of the things I probably loathe most about the mentality of OOP that got pushed on the industry is that you need a different file for every object."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/_rygo6/status/1767783595899515341
+- Author: rygo6 (@_rygo6)
+- Posted: 2024-03-13 05:23:47
+
+## Thread
+
+**1/** **@_rygo6** ^1767783595899515341
+
+One of the things I probably loathe most about the mentality of OOP that got pushed on the industry is that you need a different file for every object.
+
+OOP insinuates a view about the structure of code which is false, that being, code is composed of separate "objects" that send messages to each other. This conjures the image of a bunch of small organisms floating around an open space in a completely unstructured way sending messages to each other. 
+
+When the truth is, code tends to be hierarchal. It has a root entry point, which call methods, which call other methods, forming a tree structure. Code is not a wide-open space of objects sending things everywhere. You can design a system to appear as such and abstract away the underlying hierarchal nature, but then you lose what is actually a good quality. The hierarchal tree structure enables a straighter forward structuring and tracking of lifetimes. In one parent method allocate everything you need, making their lifetimes dependent on the scope of that method. Then that method calls another, which could even go to a runtime loop, but upon exiting that parent method scope, it automatically can release everything in that branch of the hierarchal tree. If you make everything dependent on the scope of methods as they descend this hierarchy, you do end up with fully automatic memory management, never even needing to call 'free' or 'delete'. 
+
+Keeping everything in a single file helps to reinforce this hierarchal structure, as any variable or method which some code relies on must be declared above it in the file. The downward flow of the file is forced to reflect the downward flow of the hierarchy of the program. 
+
+This combined with lifetime and memory management all bound to method scopes creates such a simple and straightforward representation of what exactly is going on in a program. All dependencies must be declared higher up the file, and cleared higher up the file somehow, then as you scroll down everything below is dependent on everything above. Having to click through a dozen files tracing method calls to figure out what some object is dependent on is not an improvement over that. I would rather just scroll up. 
+
+But you lose all of that when every granular chunk of logic, or "object" is put in a different file, when you try to abstract away the fact it is a hierarchy. Then you have to deal with more complex schemes of tracking memory use, and freeing memory. And for what? Because big files were bad? Because somehow an open space of "objects" flying about willy-nilly sending messages is a simpler mental model than a hierarchal tree structure? (It's not) 
+
+I'm wondering was there some more objective reason in the 90's for this? Like were older source control schemes bad at merging large files or something? It seems like a major mistaken path the industry veered down. Or was it just because management wanted to maximally "Parallelize" development thinking it's better if people worked in many different files? Also, a terrible path the industry seemed to go down.
+
+The top of a file should be an entry point into one significant chunk of functionality. Then everything below dependent on everything above. From there use structs, classes, instances, whatever, but leverage the fact it is hierarchal, don't abstract it away.
+
+Branches: [[archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about/2024-03-13-Samueltates-ive-definitely-overindulged-in-oops-delights-to]]
diff --git a/archive/threads/_rygo6/index.md b/archive/threads/_rygo6/index.md
new file mode 100644
index 0000000..191f7ce
--- /dev/null
+++ b/archive/threads/_rygo6/index.md
@@ -0,0 +1,12 @@
+---
+title: _rygo6
+type: note
+draft: false
+description: Archived threads by _rygo6.
+tags:
+  - archive
+  - twitter
+  - _rygo6
+---
+
+- [[archive/threads/_rygo6/2024-03-13-one-of-the-things-i-probably-loathe-most-about]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-EgorBo-in-our-case-its-also-often-just-blocked-by-the.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-EgorBo-in-our-case-its-also-often-just-blocked-by-the.md
new file mode 100644
index 0000000..1d88781
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-EgorBo-in-our-case-its-also-often-just-blocked-by-the.md
@@ -0,0 +1,37 @@
+---
+title: "@fiigii In our case, it's also often just blocked by the memory model requirements."
+type: archive
+source: twitter
+source_url: "https://x.com/EgorBo/status/2092617152461173205"
+author: "EgorBo"
+handle: EgorBo
+post_id: "2092617152461173205"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii In our case, it's also often just blocked by the memory model requirements."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/EgorBo/status/2092617152461173205
+- Author: EgorBo (@EgorBo)
+- Posted: 2026-08-26 14:16:22
+
+## Branch
+
+**1/** **@EgorBo** ^2092617152461173205
+
+**@fiigii**
+
+In our case, it's also often just blocked by the memory model requirements. Why can't you perform these two stores via SLP? Well, because the alignment is unknown in this case and the memory model requires atomic assignments.
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-FUZxxl-e-graphs-seem-to-be-one-way-to-address-this.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-FUZxxl-e-graphs-seem-to-be-one-way-to-address-this.md
new file mode 100644
index 0000000..9da8593
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-FUZxxl-e-graphs-seem-to-be-one-way-to-address-this.md
@@ -0,0 +1,43 @@
+---
+title: "@fiigii E-graphs seem to be one way to address this, allowing the compiler to explore different optimisation choices and then distilling the best outcome out of them."
+type: archive
+source: twitter
+source_url: "https://x.com/FUZxxl/status/2092546936691695734"
+author: "Robert Clausecker"
+handle: FUZxxl
+post_id: "2092546936691695734"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii E-graphs seem to be one way to address this, allowing the compiler to explore different optimisation choices and then distilling the best outcome out of them."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/FUZxxl/status/2092546936691695734
+- Author: Robert Clausecker (@FUZxxl)
+- Posted: 2026-08-26 09:37:22
+
+## Branch
+
+**1/** **@FUZxxl** ^2092546936691695734
+
+**@fiigii**
+
+E-graphs seem to be one way to address this, allowing the compiler to explore different optimisation choices and then distilling the best outcome out of them.  I suspect compile times will suffer though.
+
+**2/** **@fiigii** ^2092621030913425662
+
+**@FUZxxl**
+
+No, it is not about optimization algorithms
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-__dwr__-more-language-tier-facilities-to-drive-it-stuff.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-__dwr__-more-language-tier-facilities-to-drive-it-stuff.md
new file mode 100644
index 0000000..3b47d98
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-__dwr__-more-language-tier-facilities-to-drive-it-stuff.md
@@ -0,0 +1,37 @@
+---
+title: "@fiigii more language-tier facilities to drive it? stuff like [[likely]] and etc."
+type: archive
+source: twitter
+source_url: "https://x.com/__dwr__/status/2092576255568753057"
+author: "David Rogers"
+handle: __dwr__
+post_id: "2092576255568753057"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii more language-tier facilities to drive it? stuff like [[likely]] and etc."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/__dwr__/status/2092576255568753057
+- Author: David Rogers (@__dwr__)
+- Posted: 2026-08-26 11:33:52
+
+## Branch
+
+**1/** **@__dwr__** ^2092576255568753057
+
+**@fiigii**
+
+more language-tier facilities to drive it? stuff like [[likely]] and etc.
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-amoswap-dont-worry-it-exists-they-call-it-pgo-we-had-it.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-amoswap-dont-worry-it-exists-they-call-it-pgo-we-had-it.md
new file mode 100644
index 0000000..3375868
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-amoswap-dont-worry-it-exists-they-call-it-pgo-we-had-it.md
@@ -0,0 +1,43 @@
+---
+title: "@fiigii Don't worry it exists, they call it PGO, we had it in Visual C++ 2005."
+type: archive
+source: twitter
+source_url: "https://x.com/amoswap/status/2092620897521725881"
+author: "amoswap"
+handle: amoswap
+post_id: "2092620897521725881"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii Don't worry it exists, they call it PGO, we had it in Visual C++ 2005."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/amoswap/status/2092620897521725881
+- Author: amoswap (@amoswap)
+- Posted: 2026-08-26 14:31:15
+
+## Branch
+
+**1/** **@amoswap** ^2092620897521725881
+
+**@fiigii**
+
+Don't worry it exists, they call it PGO, we had it in Visual C++ 2005. Waiting on you GPU guys to stop playing around with OpenGL lightning modes and reinvent that one.
+
+**2/** **@fiigii** ^2092674576492990967
+
+**@amoswap**
+
+PGO is just another set of heuristic inputs.
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-btopoweroftwo-llvm-is-flexible-you-can-have-custom-passess-and.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-btopoweroftwo-llvm-is-flexible-you-can-have-custom-passess-and.md
new file mode 100644
index 0000000..03b9284
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-btopoweroftwo-llvm-is-flexible-you-can-have-custom-passess-and.md
@@ -0,0 +1,37 @@
+---
+title: "@fiigii llvm is flexible, you can have custom passess, and it has, I don't know, 2000 knobs, what you can tweak the \"heuristics\" with as you wish, good luck"
+type: archive
+source: twitter
+source_url: "https://x.com/btopoweroftwo/status/2092531536868364654"
+author: "Bálint Bertalan"
+handle: btopoweroftwo
+post_id: "2092531536868364654"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii llvm is flexible, you can have custom passess, and it has, I don't know, 2000 knobs, what you can tweak the \"heuristics\" with as you wish, good luck"
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/btopoweroftwo/status/2092531536868364654
+- Author: Bálint Bertalan (@btopoweroftwo)
+- Posted: 2026-08-26 08:36:10
+
+## Branch
+
+**1/** **@btopoweroftwo** ^2092531536868364654
+
+**@fiigii**
+
+llvm is flexible, you can have custom passess, and it has, I don't know, 2000 knobs, what you can tweak the "heuristics" with as you wish, good luck
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-keshen754041-very-true.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-keshen754041-very-true.md
new file mode 100644
index 0000000..8fec136
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-keshen754041-very-true.md
@@ -0,0 +1,37 @@
+---
+title: "@fiigii very true!"
+type: archive
+source: twitter
+source_url: "https://x.com/keshen754041/status/2092692666354123123"
+author: "keshen"
+handle: keshen754041
+post_id: "2092692666354123123"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii very true!"
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/keshen754041/status/2092692666354123123
+- Author: keshen (@keshen754041)
+- Posted: 2026-08-26 19:16:26
+
+## Branch
+
+**1/** **@keshen754041** ^2092692666354123123
+
+**@fiigii**
+
+very true!
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-pelavarre-this-needs-to-change-we-must-lift-the-rule-that.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-pelavarre-this-needs-to-change-we-must-lift-the-rule-that.md
new file mode 100644
index 0000000..f18df9f
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-pelavarre-this-needs-to-change-we-must-lift-the-rule-that.md
@@ -0,0 +1,43 @@
+---
+title: "@fiigii > This needs to change."
+type: archive
+source: twitter
+source_url: "https://x.com/pelavarre/status/2092558865133105655"
+author: "Pat LaVarre at Twítter"
+handle: pelavarre
+post_id: "2092558865133105655"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii > This needs to change."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/pelavarre/status/2092558865133105655
+- Author: Pat LaVarre at Twítter (@pelavarre)
+- Posted: 2026-08-26 10:24:45
+
+## Branch
+
+**1/** **@pelavarre** ^2092558865133105655
+
+**@fiigii**
+
+> This needs to change.
+
+We must lift the rule that says the compiler starts from scratch as often as you edit the source.
+
+We must make a space to show what the machine code has become where I can say I need the other.
+
+We’d solve Thompson’s Trusting Trust, too.
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-theblazehen-why-should-i-care-about-the-performance-of.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-theblazehen-why-should-i-care-about-the-performance-of.md
new file mode 100644
index 0000000..c6f2eb7
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-theblazehen-why-should-i-care-about-the-performance-of.md
@@ -0,0 +1,35 @@
+---
+title: "\"Why should I care about the performance of everyone else’s programs?\" Because then they will be forced to do likewise."
+type: archive
+source: twitter
+source_url: "https://x.com/theblazehen/status/2092581236707324181"
+author: "theblazehen"
+handle: theblazehen
+post_id: "2092581236707324181"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "\"Why should I care about the performance of everyone else’s programs?\" Because then they will be forced to do likewise."
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/theblazehen/status/2092581236707324181
+- Author: theblazehen (@theblazehen)
+- Posted: 2026-08-26 11:53:39
+
+## Branch
+
+**1/** **@theblazehen** ^2092581236707324181
+
+"Why should I care about the performance of everyone else’s programs?" Because then they will be forced to do likewise. All the gains you get from the compiler not being optimized generally rather to specific usecases in all other areas of your program will make up for the losses in one specific area where it's slower. You can always fork the compiler if it's important enough
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-thedevbirb-i-think-inline-assembly-should-be-the-right.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-thedevbirb-i-think-inline-assembly-should-be-the-right.md
new file mode 100644
index 0000000..3bb1c53
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-thedevbirb-i-think-inline-assembly-should-be-the-right.md
@@ -0,0 +1,37 @@
+---
+title: "@fiigii I think inline assembly should be the right answer, but compilers don’t have a really great support of it, apart from Odin right now"
+type: archive
+source: twitter
+source_url: "https://x.com/thedevbirb/status/2092628678190494173"
+author: "thedevbirb"
+handle: thedevbirb
+post_id: "2092628678190494173"
+date: 2026-08-26
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "@fiigii I think inline assembly should be the right answer, but compilers don’t have a really great support of it, apart from Odin right now"
+in_reply_to: ""
+parent_post_id: "2092398653797490972"
+---
+
+## Source
+
+- URL: https://x.com/thedevbirb/status/2092628678190494173
+- Author: thedevbirb (@thedevbirb)
+- Posted: 2026-08-26 15:02:10
+
+## Branch
+
+**1/** **@thedevbirb** ^2092628678190494173
+
+**@fiigii**
+
+I think inline assembly should be the right answer, but compilers don’t have a really great support of it, apart from Odin right now
+
+## Related
+
+- Spine: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/index.md b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/index.md
new file mode 100644
index 0000000..f1ea4e5
--- /dev/null
+++ b/archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/index.md
@@ -0,0 +1,46 @@
+---
+title: "If you’ve done serious compiler optimization work on a product with a sufficiently large user base, you’ve almost certainly seen bug reports like this:"
+type: archive
+source: twitter
+source_url: "https://x.com/fiigii/status/2092398653797490972"
+author: "Fei Peng"
+handle: fiigii
+post_id: "2092398653797490972"
+date: 2026-08-25
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - fiigii
+description: "If you’ve done serious compiler optimization work on a product with a sufficiently large user base, you’ve almost certainly seen bug reports like this:"
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/fiigii/status/2092398653797490972
+- Author: Fei Peng (@fiigii)
+- Posted: 2026-08-25 23:48:08
+
+## Thread
+
+**1/** **@fiigii** ^2092398653797490972
+
+If you’ve done serious compiler optimization work on a product with a sufficiently large user base, you’ve almost certainly seen bug reports like this:
+
+“Why does this code compile into this assembly? There’s an obvious optimization opportunity here. Loop unrolling, LICM, etc. Why didn’t the compiler do it? If it did, my program would be faster. Please change the compiler so my program runs faster.”
+
+Very often, the answer is:
+
+“This isn’t really a compiler bug. It’s a heuristic. The transformation you’re asking for may indeed improve your program, but it could hurt performance in other cases or for other users. A compiler may have thousands or millions of users, and it has to preserve performance across an enormous variety of workloads. We can’t change an optimization policy just to make one program faster."
+
+This answer is 200% correct. I’ve lost count of how many times I’ve given some version of it myself.
+
+And yet, every time I say it, it’s one of the moments when I hate my job the most.
+
+As a user, why should I care about the compiler’s internal heuristics? Why should I care about the performance of everyone else’s programs? Why should I have to pay for something I don’t need?
+
+This needs to change.
+
+Branches: [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-btopoweroftwo-llvm-is-flexible-you-can-have-custom-passess-and]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-FUZxxl-e-graphs-seem-to-be-one-way-to-address-this]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-pelavarre-this-needs-to-change-we-must-lift-the-rule-that]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-__dwr__-more-language-tier-facilities-to-drive-it-stuff]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-theblazehen-why-should-i-care-about-the-performance-of]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-EgorBo-in-our-case-its-also-often-just-blocked-by-the]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-amoswap-dont-worry-it-exists-they-call-it-pgo-we-had-it]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-thedevbirb-i-think-inline-assembly-should-be-the-right]], [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work/2026-08-26-keshen754041-very-true]]
diff --git a/archive/threads/fiigii/index.md b/archive/threads/fiigii/index.md
new file mode 100644
index 0000000..1512e9c
--- /dev/null
+++ b/archive/threads/fiigii/index.md
@@ -0,0 +1,12 @@
+---
+title: fiigii
+type: note
+draft: false
+description: Archived threads by fiigii.
+tags:
+  - archive
+  - twitter
+  - fiigii
+---
+
+- [[archive/threads/fiigii/2026-08-25-if-youve-done-serious-compiler-optimization-work]]
diff --git a/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-hastuc_dibtux-fwiw-youre-speed-running-shader-dev-in-modern-aaa.md b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-hastuc_dibtux-fwiw-youre-speed-running-shader-dev-in-modern-aaa.md
new file mode 100644
index 0000000..7fec3d8
--- /dev/null
+++ b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-hastuc_dibtux-fwiw-youre-speed-running-shader-dev-in-modern-aaa.md
@@ -0,0 +1,59 @@
+---
+title: "@flowerornament FWIW you’re speed running shader dev in modern AAA, they do a hacky emulation of a rate lattice type idea bc GI and fog etc need to be amortised over several frames."
+type: archive
+source: twitter
+source_url: "https://x.com/hastuc_dibtux/status/2034587177233908079"
+author: "Dr. Oskar Sarkon"
+handle: hastuc_dibtux
+post_id: "2034587177233908079"
+date: 2026-03-19
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - flowerornament
+description: "@flowerornament FWIW you’re speed running shader dev in modern AAA, they do a hacky emulation of a rate lattice type idea bc GI and fog etc need to be amortised over several frames."
+in_reply_to: ""
+parent_post_id: "2034584048606273988"
+---
+
+## Source
+
+- URL: https://x.com/hastuc_dibtux/status/2034587177233908079
+- Author: Dr. Oskar Sarkon (@hastuc_dibtux)
+- Posted: 2026-03-19 11:05:58
+
+## Branch
+
+**1/** **@hastuc_dibtux** ^2034587177233908079
+
+**@flowerornament**
+
+FWIW you’re speed running shader dev in modern AAA, they do a hacky emulation of a rate lattice type idea bc GI and fog etc need to be amortised over several frames. Should definitely look at demo scene stuff also if you haven’t
+
+**2/** **@flowerornament** ^2034591920706781196
+
+That's correct pattern matching, but the innovation here is not that I'm inventing new concepts—the design only aims to *formalize* many known techniques. Moving between audio programming, control, and neural networks is just a parameterization, with computations dispatched to whatever hardware runs them best.
+
+It remains to be seen whether this thing can subsume graphics too (despite all the overlap), but for now it doesn't because scatter has unbounded cost, and that's just a different aesthetic.
+
+**3/** **@hastuc_dibtux** ^2034599017405972632
+
+**@flowerornament**
+
+Can you elaborate on the scatter thing wrt video
+
+**4/** **@flowerornament** ^2034780263855923467
+
+Graphics has a gather / scatter concept. Rasterization (scatter) writes into unknown / unbounded memory space, so you can't guarantee performance characteristics by construction in advance. This is somewhat fine on GPUs, but at the end of the day you need to just build and test to see if it works (that's how the whole industry works today ... why there are C++ gray beards running everything). Murail's whole concept is that downstream performance characteristics are *known* in the type system, so you can guarantee something will run in real-time at compile time. This makes it safe / easy for a novice to write performant code.
+
+There is a middle ground possible, but not a priority for me right now.
+
+**5/** **@flowerornament** ^2034780576029512153
+
+> Graphics has a gather/scatter split. Texture sampling is gather — read from computed addresses — and GPUs do it natively. Rasterization is scatter — one triangle writes to many pixels, fanout is data-dependent and unbounded. That scatter path requires dedicated fixed-function hardware (rasterizers, ROPs) that doesn’t exist in the compute/tensor pipeline (currently).
+
+## Related
+
+- Spine: [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail]]
diff --git a/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-renart973-you-may-want-to-reach-pedro-domingos-in-case-you.md b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-renart973-you-may-want-to-reach-pedro-domingos-in-case-you.md
new file mode 100644
index 0000000..35a49cb
--- /dev/null
+++ b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-renart973-you-may-want-to-reach-pedro-domingos-in-case-you.md
@@ -0,0 +1,49 @@
+---
+title: "@flowerornament You may want to reach Pedro Domingos."
+type: archive
+source: twitter
+source_url: "https://x.com/renart973/status/2034637505819967722"
+author: "renart"
+handle: renart973
+post_id: "2034637505819967722"
+date: 2026-03-19
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - flowerornament
+description: "@flowerornament You may want to reach Pedro Domingos."
+in_reply_to: ""
+parent_post_id: "2034584048606273988"
+---
+
+## Source
+
+- URL: https://x.com/renart973/status/2034637505819967722
+- Author: renart (@renart973)
+- Posted: 2026-03-19 14:25:57
+
+## Branch
+
+**1/** **@renart973** ^2034637505819967722
+
+**@flowerornament**
+
+You may want to reach Pedro Domingos. In case you haven't read this one, you'll probably resonate with his current work. https://arxiv.org/html/2510.12269v1
+
+**2/** **@flowerornament** ^2034926001189528023
+
+**@renart973**
+
+Fantastic, thank you! I hadn't come across this somehow. At first glance, it seems like we've had some similar core insights, but otherwise the models are as different as can be. That said, there are some ideas in here I want to borrow. May reach out.
+
+**3/** **@flowerornament** ^2034926562945245364
+
+**@renart973**
+
+One day I too aspire to be a hobo sailor dropping links to obscure PL theory on X—cheers 👌
+
+## Related
+
+- Spine: [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail]]
diff --git a/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-04-05-eshear-the-more-i-read-about-murail-the-more-i-would.md b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-04-05-eshear-the-more-i-read-about-murail-the-more-i-would.md
new file mode 100644
index 0000000..6186ba9
--- /dev/null
+++ b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-04-05-eshear-the-more-i-read-about-murail-the-more-i-would.md
@@ -0,0 +1,37 @@
+---
+title: "@flowerornament The more I read about Murail the more I would love to be able to compare notes...I've been working on something based on operad diagrams that seems to be almost exactly dual to your design...ping me!"
+type: archive
+source: twitter
+source_url: "https://x.com/eshear/status/2040626723814089183"
+author: "Emmett Shear"
+handle: eshear
+post_id: "2040626723814089183"
+date: 2026-04-05
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - flowerornament
+description: "@flowerornament The more I read about Murail the more I would love to be able to compare notes...I've been working on something based on operad diagrams that seems to be almost exactly dual to your design...ping me!"
+in_reply_to: ""
+parent_post_id: "2034584048606273988"
+---
+
+## Source
+
+- URL: https://x.com/eshear/status/2040626723814089183
+- Author: Emmett Shear (@eshear)
+- Posted: 2026-04-05 03:04:58
+
+## Branch
+
+**1/** **@eshear** ^2040626723814089183
+
+**@flowerornament**
+
+The more I read about Murail the more I would love to be able to compare notes...I've been working on something based on operad diagrams that seems to be almost exactly dual to your design...ping me!
+
+## Related
+
+- Spine: [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail]]
diff --git a/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/index.md b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/index.md
new file mode 100644
index 0000000..4aaa3ce
--- /dev/null
+++ b/archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/index.md
@@ -0,0 +1,104 @@
+---
+title: "I'm currently thinking through the Murail \"programming language\"—and it's a weird one."
+type: archive
+source: twitter
+source_url: "https://x.com/flowerornament/status/2034584048606273988"
+author: "Flower"
+handle: flowerornament
+post_id: "2034584048606273988"
+date: 2026-03-19
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - flowerornament
+description: "I'm currently thinking through the Murail \"programming language\"—and it's a weird one."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/flowerornament/status/2034584048606273988
+- Author: Flower (@flowerornament)
+- Posted: 2026-03-19 10:53:32
+
+## Thread
+
+**1/** **@flowerornament** ^2034584048606273988
+
+I'm currently thinking through the Murail "programming language"—and it's a weird one.
+
+"Named sparse recurrence" is what it calls itself. Let's unpack that:
+
+Named
+A Murail program is simply a set of named equations.
+
+Programs are a lot like writing math, which its intended users are familiar with:
+
+osc.phase = self@1 + freq / sr
+osc.out = sin(osc.phase * 2 * pi)
+
+This is a program for a sinusoidal oscillator. It defines two nodes in a graph.
+
+Compared to a normal programming language, this is a bit like defining a function, but Murail is neither imperative nor functional, so functions are never explicitly "called."
+
+A named equation is instantly running as soon as it's written. There's no "on" or "off". In this way, it's a bit like a circuit. If you wanted to turn a function off, you'd have to write a switch after it.
+
+This may seem very limited and unfamiliar, but it's a lot like the most popular programming language in the world: spreadsheets.
+
+It's also very much like Max/MSP, and you can think of Murail as something like Max/MSP, but more general. Instead of "signals" and "control," nodes are connected by streams of matrices, which can flow at any rate. If the rate is fast—like, audio rate—they get automatically prioritized and run fast like optimized C code.
+
+On top of this simple scheme, we layer some concepts for abstraction. This is what I'm working on now. There are "templates" you can use to group equations, simple pattern matching, constructions for branching, a "do" keyword for pseudo-imperative stuff, and more.
+
+But this is all syntax sugar over named equations.
+
+Sparse
+Murail programs are, basically, graphs. You write equations, but those equations are automatically connected together. The thing that tells the compiler which things to connect to which other things is mediated by the names.
+
+So, the above oscillator example actually turns into something like:
+
+[osc.phase] -> [osc.out]
+
+But the crazy part is that this compiles to a matrix operation. In "BSM" form, something like:
+
+[y]      [2π  2π] [ω]
+[φ] = [  1     1  ] [φ] + sin(y)
+
+So, "sparse" refers to the fact that what we're really defining is a huge set of matrices related by a sparse matrix, which defines the connections between them.
+
+Recurrence
+This matrix is evaluated "in time." In a normal programming language, you don't think about time specifically—or if you do, it's a choice. Normally, you just want everything to execute as fast as possible.
+
+In Murail, everything is executed together at a specific rate. If you're doing audio, then it's something like 48khz.
+
+But the graph aka matrix is executed over a "rate lattice," which means different parts of the graph are executed at divisions of the fastest rate.
+
+On top of this, "now" is variable. You can alway write `self@1`, which refers to the current value, but one step in the past.
+
+In this sense, Murail is a "strongly timed" language. You cannot do anything without explicitly or implicitly defining how often it happens per second.
+
+Design
+The hard part of a language like this is getting it to also do things people are used to doing in a programming language.
+
+I'm not actually sure if Murail is Turing complete—but what's more important is that it's decidedly *not* lambda calculus.
+
+As such, it's been an interesting exercise to find out how exactly to provide the right set of features such that you can fluently write DSP code that looks like math, but also do more "sequential" things like write a sequencer, or an HTTP server, or load a file.
+
+It turns out you can do a lot more of this than I thought at first, and quite elegantly. The primitives are just different.
+
+In fact, they're not *that* weird. They're just more like what you find in a language like APL (or J, or K).
+
+branch, fold, scan, select, match
+
+If you're used to Max/MSP, you'll be familiar with this type of stuff. Strangely named operations that split, combine, interleave, and shape streams of data.
+
+The concept of "externals" from Max/MSP is also essential here for certain things. In Urbit or PLAN, they're called "jets."
+
+Ultimately, you can't get around the fact that the rest of your computer isn't inside the graph itself. As such, the runtime needs to provide certain special functions that do things like read files or take input from the external world and inject them into equations.
+
+We'll have to wait for the PLAN computer for a world where your OS is just one uniform substrate interacting with itself. But, even there, you need some systems code at the edge.
+
+That's probably enough for one post. Perhaps more to come.
+
+Branches: [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-hastuc_dibtux-fwiw-youre-speed-running-shader-dev-in-modern-aaa]], [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-03-19-renart973-you-may-want-to-reach-pedro-domingos-in-case-you]], [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail/2026-04-05-eshear-the-more-i-read-about-murail-the-more-i-would]]
diff --git a/archive/threads/flowerornament/index.md b/archive/threads/flowerornament/index.md
new file mode 100644
index 0000000..b8616fe
--- /dev/null
+++ b/archive/threads/flowerornament/index.md
@@ -0,0 +1,12 @@
+---
+title: flowerornament
+type: note
+draft: false
+description: Archived threads by flowerornament.
+tags:
+  - archive
+  - twitter
+  - flowerornament
+---
+
+- [[archive/threads/flowerornament/2026-03-19-im-currently-thinking-through-the-murail]]
diff --git a/archive/threads/frankdejonge/2026-08-22-state-machines-are-what-crud-minded-developers/index.md b/archive/threads/frankdejonge/2026-08-22-state-machines-are-what-crud-minded-developers/index.md
new file mode 100644
index 0000000..bee3c3d
--- /dev/null
+++ b/archive/threads/frankdejonge/2026-08-22-state-machines-are-what-crud-minded-developers/index.md
@@ -0,0 +1,150 @@
+---
+title: "State machines are what CRUD-minded developers create when trying to model processes."
+type: archive
+source: twitter
+source_url: "https://x.com/frankdejonge/status/2091060039448461736"
+author: "Frank de Jonge"
+handle: frankdejonge
+post_id: "2091060039448461736"
+date: 2026-08-22
+archived: 2026-08-29
+draft: false
+tags:
+  - archive
+  - twitter
+  - frankdejonge
+description: "State machines are what CRUD-minded developers create when trying to model processes."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/frankdejonge/status/2091060039448461736
+- Author: Frank de Jonge (@frankdejonge)
+- Posted: 2026-08-22 07:08:58
+
+## Thread
+
+**1/** **@frankdejonge** ^2091060039448461736
+
+State machines are what CRUD-minded developers create when trying to model processes.
+
+**2/** **@_joshd** ^2091282447233347801
+
+**@frankdejonge**
+
+Event sourcing and state machines aren't mutually exclusive though. You can totally use a state machine to represent how you roll a sequence of events into the current state, and IME you'll have fewer bugs if you reason explicitly about those states and transitions
+
+**3/** **@frankdejonge** ^2091411590281068981
+
+**@_joshd**
+
+In event sourcing, you cannot deny what happened in the past, you have to deal with it. In a state machine those would be rejected as transitions. So they’re not mutually exclusive until that happens.
+
+**4/** **@_joshd** ^2091413430888780150
+
+**@frankdejonge**
+
+If you're doing CQRS you can't deny that a command was sent but you certainly can deny that your system executes the command as sent. Notably if the command would put an entity in a disallowed state. You can't retroactively disallow a transition in ES, but you also can't in CRUD.
+
+**5/** **@frankdejonge** ^2091512632414982551
+
+**@_joshd**
+
+I'm not sure what your point is. What your describing is correct, but has very little to do with comparing event sourcing to state machines imo. If something happened in ES you can pretend it didn't, which just means you're not modelling what happened. You can still guard rules.
+
+**6/** **@_joshd** ^2091558477143650424
+
+**@frankdejonge**
+
+I'm saying that avoiding defining your allowed states and transitions will not help you and bugs, it'll just make it harder to detect them
+
+**7/** **@frankdejonge** ^2091584635079672045
+
+**@_joshd**
+
+Allowed states mean nothing when it is enforced upon reconstitution. It’s denying history that already happened.
+
+**8/** **@_joshd** ^2091605404472254700
+
+**@frankdejonge**
+
+I don't know what you're imagining my proposal is. You have to be able to represent every state transition that has ever happened. You don't have to continue to allow that transition in the future. Explicit enumeration of state transitions is better than implicit.
+
+**9/** **@frankdejonge** ^2091606504029683942
+
+**@_joshd**
+
+What kind of industry or problem domain do you work in/on? Might help me understand your responses better
+
+**10/** **@_joshd** ^2091634264966308037
+
+**@frankdejonge**
+
+Two sided service marketplace. And so, simplifying a bit, the example I'm thinking of is that services have states like scheduled / in-progress / completed, where the transition "complete" only makes sense for in-progress services. What example are you picturing?
+
+**11/** **@frankdejonge** ^2091761233179414804
+
+**@_joshd**
+
+What happens when multiple things need to happen before you can be in progress or scheduled? Like each side needs to agree to terms and they need confirm once the other side has specified their proposal?
+
+**12/** **@_joshd** ^2091764442833010794
+
+**@frankdejonge**
+
+Then a single state machine likely isn't the right modeling tool. You could force your architecture there but you shouldn't. State machine is for when you've got one entity which can be in one of a small set of mutually exclusive states. You'll know if your problem matches.
+
+**13/** **@frankdejonge** ^2091765099874648556
+
+**@_joshd**
+
+In my experience, people often cannot say, unless it’s rooted in undeniable hard facts that cannot change. Any business process can change or become more complex in one area or another.
+
+**14/** **@frankdejonge** ^2091765804819767481
+
+**@_joshd**
+
+And by the conditions you’re attaching, you could only use it in relatively simple cases, which in a sense makes the point of it being a lesser option. Things often start out simple and then grow in utility and complexity over time. So how can you tell when it stays simple?
+
+**15/** **@_joshd** ^2091768683811271118
+
+**@frankdejonge**
+
+Yes. My opinion is that you should use the least expressive domain model you can get away with. You *could* express any business process using three tables [entity, relationship, event] (or even just [entity] or just [event]) but you shouldn't.
+
+**16/** **@_joshd** ^2091769529915572604
+
+**@frankdejonge**
+
+Or perhaps I should say "least flexible" rather than "least expressive". It's generally pretty easy to replace a state machine with more bespoke logic, and if you need to do that you just accept that your code is slightly harder to reason about. Bespoke->state machine is hard.
+
+**17/** **@frankdejonge** ^2091783448956452931
+
+**@_joshd**
+
+I think this is where we differ in stance perhaps. I tend to optimise for change yet defer as much YAGNI-stuff as possible. The optimising for change means I can defer things to later without being hit by it. Which means most things stay as simple as possible, yet some are not.
+
+**18/** **@_joshd** ^2091792273797464085
+
+**@frankdejonge**
+
+Yeah, makes sense. Where the best point between future-proofing and YAGNI is for you will depend on the relative costs of complexity and of making changes. I work on a small team which ships daily, so changes are a worthwhile price to be able to hold the whole system in our heads
+
+**19/** **@_joshd** ^2091792694238687397
+
+**@frankdejonge**
+
+If a schema change will require looping in 10 stakeholders and allotting time in the quarterly roadmap, then perhaps a bit of extra complexity in the form of a permissive schema is worth it to avoid that friction.
+
+**20/** **@frankdejonge** ^2091794124567351484
+
+**@_joshd**
+
+I work in a compliance startup, ~5 teams, and for us it's mostly about not designing trap-door decisions. Anything that is reversible can be done with taking more risk, anything that is not, we scrutinise. We use ES to make many things a non-trapdoor decision.
+
+**21/** **@_joshd** ^2091928950092214699
+
+**@frankdejonge**
+
+Makes sense. We're mostly not that hardcore on ES, though anything that touches money or legal documents or such we make sure the source of truth is append-only, which is sort of like ES if you squint.
diff --git a/archive/threads/frankdejonge/index.md b/archive/threads/frankdejonge/index.md
new file mode 100644
index 0000000..30fdd0e
--- /dev/null
+++ b/archive/threads/frankdejonge/index.md
@@ -0,0 +1,12 @@
+---
+title: frankdejonge
+type: note
+draft: false
+description: Archived threads by frankdejonge.
+tags:
+  - archive
+  - twitter
+  - frankdejonge
+---
+
+- [[archive/threads/frankdejonge/2026-08-22-state-machines-are-what-crud-minded-developers]]
diff --git a/archive/threads/index.md b/archive/threads/index.md
index b014afb..0591910 100644
--- a/archive/threads/index.md
+++ b/archive/threads/index.md
@@ -13,6 +13,8 @@ How to read a folder: [[notes/How threads are organized]].
 
 Example of the note shape (single spine, no branches): [[archive/threads/How to archive a thread]]
 
+- [[archive/threads/_Felipe]]
+- [[archive/threads/_rygo6]]
 - [[archive/threads/AgileJebrim]]
 - [[archive/threads/alexdotjs]]
 - [[archive/threads/anisomorphism]]
@@ -30,7 +32,11 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/EricLengyel]]
 - [[archive/threads/eshear]]
 - [[archive/threads/FFmpeg]]
+- [[archive/threads/fiigii]]
+- [[archive/threads/flowerornament]]
+- [[archive/threads/frankdejonge]]
 - [[archive/threads/FreyaHolmer]]
+- [[archive/threads/FUZxxl]]
 - [[archive/threads/hamish_todd]]
 - [[archive/threads/hasen_95dx]]
 - [[archive/threads/HostOfMeta]]
@@ -62,6 +68,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/noinconsistency]]
 - [[archive/threads/NOTimothyLottes]]
 - [[archive/threads/ocornut]]
+- [[archive/threads/OSdev_]]
 - [[archive/threads/pickover]]
 - [[archive/threads/pikuma]]
 - [[archive/threads/RandyPGaul]]