From 8b0963c67f48c1c7f02edbaf8427d8e2980707f8 Mon Sep 17 00:00:00 2001 From: Ed_ Date: Tue, 6 Oct 2026 06:51:37 -0400 Subject: [PATCH] more --- .../index.md | 74 +++++++ archive/threads/DemetriSpanos/index.md | 12 ++ .../index.md | 71 +++++++ .../index.md | 72 +++++++ ...at-they-say-actual-fp32-compute-meaning.md | 72 +++++++ .../index.md | 90 ++++++++ archive/threads/NOTimothyLottes/index.md | 3 + .../index.md | 90 ++++++++ .../index.md | 198 ++++++++++++++++++ archive/threads/bonzajplc/index.md | 2 + archive/threads/index.md | 1 + 11 files changed, 685 insertions(+) create mode 100644 archive/threads/DemetriSpanos/2026-09-29-just-adding-that-decompilation-has-verifiable/index.md create mode 100644 archive/threads/DemetriSpanos/index.md create mode 100644 archive/threads/NOTimothyLottes/2026-09-15-evening-project-building-a-spiritual-successor/index.md create mode 100644 archive/threads/NOTimothyLottes/2026-09-24-exploring-minimum-size-compilers-on-x86-64/index.md create mode 100644 archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/2026-10-04-SebAaltonen-funny-that-they-say-actual-fp32-compute-meaning.md create mode 100644 archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/index.md create mode 100644 archive/threads/bonzajplc/2026-07-19-if-a-game-development-studio-claims-that-it-uses/index.md create mode 100644 archive/threads/bonzajplc/2026-09-17-me-and-my-plasticdemo-team-escaping-a-wave-of/index.md diff --git a/archive/threads/DemetriSpanos/2026-09-29-just-adding-that-decompilation-has-verifiable/index.md b/archive/threads/DemetriSpanos/2026-09-29-just-adding-that-decompilation-has-verifiable/index.md new file mode 100644 index 0000000..5ebe84f --- /dev/null +++ b/archive/threads/DemetriSpanos/2026-09-29-just-adding-that-decompilation-has-verifiable/index.md @@ -0,0 +1,74 @@ +--- +title: "Just adding that decompilation has \"verifiable rewards\": clang compiles source, AI tries to reverse, ASTs are compared, AI gets training signal." +type: archive +source: twitter +source_url: "https://x.com/DemetriSpanos/status/2104962978030203120" +author: "Demetri Spanos" +handle: DemetriSpanos +post_id: "2104962978030203120" +date: 2026-09-29 +archived: 2026-10-06 +draft: false +tags: + - archive + - twitter + - DemetriSpanos +description: "Just adding that decompilation has \"verifiable rewards\": clang compiles source, AI tries to reverse, ASTs are compared, AI gets training signal." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/DemetriSpanos/status/2104962978030203120 +- Author: Demetri Spanos (@DemetriSpanos) +- Posted: 2026-09-29 15:54:16 + +## Thread + +**1/** **@DemetriSpanos** ^2104962978030203120 + +Just adding that decompilation has "verifiable rewards": clang compiles source, AI tries to reverse, ASTs are compared, AI gets training signal. + +It's substantially like Go/Chess/Lean, meaning ~free procedural training data: one AI creates and compiles code, another decompiles. + +**2/** **@archo5dev** ^2105024366534853044 + +**@DemetriSpanos** + +there are many ways to format the source code that would all produce the same assembly + +identifying the algorithms and applying the corresponding variable names can't be verified automatically + +that's if we're talking binary to human-level source, not merely any compiling source + +**3/** **@DemetriSpanos** ^2105029309584818465 + +**@archo5dev** + +It's true you can't fully recover formatting. + +But you can likely recover AST (from training with clang), plausible names, and plausible comments (already seen in e.g. Cursor-style autocompletion). + +Readable source that compiles the same way is all you need for AI decompilation. + +**4/** **@archo5dev** ^2105035264527610094 + +**@DemetriSpanos** + +even non-LLM decompilers (e.g. dnSpy) can produce good ASTs + +but the point of that conversation was about LLM companies taking people's work + +so taken together, it would mean using a LLM to decompile a binary and then feeding the "source" into a new LLM + +**5/** **@DemetriSpanos** ^2105036711604445420 + +**@archo5dev** + +I think we agree? An AI company could easily train on binaries, through decompilation (even with current conventional decompilers, or with better LLM decompilers), in order to get new source code to train future LLMs, thus absorbing previously semi-hidden information. + +**6/** **@archo5dev** ^2105038580800487662 + +**@DemetriSpanos** + +they certainly could try, I'm just not sure how useful that would be for them, and (relatedly) how much human work would need to be involved in cleaning up the decompiled code - especially for algorithms that haven't appeared anywhere else before diff --git a/archive/threads/DemetriSpanos/index.md b/archive/threads/DemetriSpanos/index.md new file mode 100644 index 0000000..97ed54a --- /dev/null +++ b/archive/threads/DemetriSpanos/index.md @@ -0,0 +1,12 @@ +--- +title: DemetriSpanos +type: note +draft: false +description: Archived threads by DemetriSpanos. +tags: + - archive + - twitter + - DemetriSpanos +--- + +- [[archive/threads/DemetriSpanos/2026-09-29-just-adding-that-decompilation-has-verifiable]] diff --git a/archive/threads/NOTimothyLottes/2026-09-15-evening-project-building-a-spiritual-successor/index.md b/archive/threads/NOTimothyLottes/2026-09-15-evening-project-building-a-spiritual-successor/index.md new file mode 100644 index 0000000..19a1fad --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-09-15-evening-project-building-a-spiritual-successor/index.md @@ -0,0 +1,71 @@ +--- +title: "Evening project - building a spiritual successor language to what could pass as a replacement for C64 boot BASIC boot but on a x86-64 machine ..." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2099688997194711371" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2099688997194711371" +date: 2026-09-15 +archived: 2026-09-15 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Evening project - building a spiritual successor language to what could pass as a replacement for C64 boot BASIC boot but on a x86-64 machine ..." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2099688997194711371 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-09-15 02:37:21 + +## Thread + +**1/** **@NOTimothyLottes** ^2099688997194711371 + +Evening project - building a spiritual successor language to what could pass as a replacement for C64 boot BASIC boot but on a x86-64 machine ... + +**2/** **@NOTimothyLottes** ^2099690063755870582 + +Constraints +(1.) Must directly interpret from ascii txt +(2.) Must be tiny, core language fits in a few hundred bytes [fraction of I$] +(3.) Sticking with similar double character max string size for 'variable' name +(4.) But swapping BASIC for something FORTH like instead + +**3/** **@NOTimothyLottes** ^2099690978298786054 + +I'm using 128-bytes for ascii reordering (so 0-F is 0-F, etc). Doing a byte[128] sized lookup for the interpreter which gets converted to a jump table for 7-bit characters. So each character is a branch, and likely some get predicted (like when using hex literals). + +**4/** **@NOTimothyLottes** ^2099691470043103730 + +Yet this language is actually a serious effort, something trivial to understand, and powerful enough to use for system level scripting (doing syscalls) and function as a macro assembler for CPU+GPU code. Also something fast enough to be effectively free for iteration-time + +**5/** **@NOTimothyLottes** ^2099692261399248990 + +I've got a crazy useful system for comments, +ThisPartIsIgnored_gg +The _ clears the string (prefix comment) +The 'gg' is the physical index to the dictionary entry +So it's possible to comment all the abbreviations + +**6/** **@NOTimothyLottes** ^2099693204312404281 + +Tooling is just writing it out in binary form. +I use https://defuse.ca/online-x86-assembler.htm#disassembly to grab disassembly bytes to write into a hex stream. And https://ref.x86asm.net/coder64.html for x86-64 opcode reference. + +**7/** **@NOTimothyLottes** ^2099693914085016007 + +Probably going to merge this into my prior effort for a Linux self modifying binary, as it's language. Then just need to build out the in-binary editor for a complete working dev platform for Linux x86-64 that fits in a few KiB. + +**8/** **@NOTimothyLottes** ^2099694772260675908 + +The x86-64 self modifying binary shell with not the smallest ELF header is currently clocked in at 290 bytes. So yeah not joking, a full hardcore Linux dev env in a few KiB (language, editor, debugger). + +**9/** **@NOTimothyLottes** ^2099695168253284559 + +The irony being this would be portable, no library support, everything in raw system calls. So will need to roll over my prior user-space AMD compute GPU driver as well. diff --git a/archive/threads/NOTimothyLottes/2026-09-24-exploring-minimum-size-compilers-on-x86-64/index.md b/archive/threads/NOTimothyLottes/2026-09-24-exploring-minimum-size-compilers-on-x86-64/index.md new file mode 100644 index 0000000..8e67d6e --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-09-24-exploring-minimum-size-compilers-on-x86-64/index.md @@ -0,0 +1,72 @@ +--- +title: "Exploring minimum size compilers on x86-64, specifically branch-free logic (one predicted jnz to loop per input token)." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2103076419379339498" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2103076419379339498" +date: 2026-09-24 +archived: 2026-10-06 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Exploring minimum size compilers on x86-64, specifically branch-free logic (one predicted jnz to loop per input token)." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2103076419379339498 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-09-24 10:57:46 + +## Thread + +**1/** **@NOTimothyLottes** ^2103076419379339498 + +Exploring minimum size compilers on x86-64, specifically branch-free logic (one predicted jnz to loop per input token). A minimum forth-like language can be built with a 17-instruction/token loop. Source uses {2-bit tag, 14-bit dictionary index}. + +**2/** **@NOTimothyLottes** ^2103078363422146662 + +So the instructions of the compiler itself fits on one x86-64 cacheline, less than 64 bytes total. + +**3/** **@NOTimothyLottes** ^2103079055113195747 + +From a data perspective, it's 16384 entry dictionary that contains direct 32-bit chunks of pre-compiled instructions that can be spiced together. + +**4/** **@NOTimothyLottes** ^2103079963658469860 + +2-bit tag/token, +00 : write value from dictionary 'V' +01 : write V-nextInstructionPointer (for call/jmp) +02 : ignore (for comments) +03 : write instructionPointer into dictionary (for define) + +So like a direct mapped tiny color-forth + +**5/** **@NOTimothyLottes** ^2103081099068899412 + +Haven't timed code generation speed, but it's probably peaks around 1/2 GB/sec of code gen on a 2 GHz x86-64. Meaning fast enough to support recompiling the whole program each frame if you wanted to. + +**6/** **@NOTimothyLottes** ^2103082320853094619 + +Designing the language around making something forth-like to be the macro assembler for GPU binary generation, but also fast enough to be the entire x86-64 code as well. Meaning can do x86-64 assembly too for important raw loops. + +**7/** **@NOTimothyLottes** ^2103083570550223191 + +Apparently AMD's Zen line doesn't have sub-register stalls like Intel, so one can take advantage. Also used the 2-for-1 {SAR ax,15} trick, which produces a full 0/~0 mask along with putting the last shifted out bit 14 in CF. Quite useful for branch-free logic (like cmovCC ops). + +**8/** **@NOTimothyLottes** ^2103084229420597601 + +x86-64 is actually really poor ISA for branch-free logic for many reasons, like cmovCC doesn't have an IMM operand form so you burn registers for immediate constants, and not having a separate destination register means extra MOVs to duplicate, with some exceptions like LEA. + +**9/** **@NOTimothyLottes** ^2103084603682562173 + +Anyway this whole system was another exploration of a minimal x86-64 based setup. Last I was trying a text interpretered one (with branches), and I think this new one is substantially better. + +**10/** **@NOTimothyLottes** ^2103085001730658640 + +There is also a lot of nice things about working in Linux and having the easy ability to guarantee code/data in the lower 32-bit address space. This is for no-library execution (meaning only kernel interfaces, including for the GPU). diff --git a/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/2026-10-04-SebAaltonen-funny-that-they-say-actual-fp32-compute-meaning.md b/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/2026-10-04-SebAaltonen-funny-that-they-say-actual-fp32-compute-meaning.md new file mode 100644 index 0000000..3cdd6a9 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/2026-10-04-SebAaltonen-funny-that-they-say-actual-fp32-compute-meaning.md @@ -0,0 +1,72 @@ +--- +title: "@NOTimothyLottes Funny that they say \"actual fp32 compute\"." +type: archive +source: twitter +source_url: "https://x.com/SebAaltonen/status/2106630618859639291" +author: "Sebastian Aaltonen" +handle: SebAaltonen +post_id: "2106630618859639291" +date: 2026-10-04 +archived: 2026-10-06 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes Funny that they say \"actual fp32 compute\"." +in_reply_to: "" +parent_post_id: "2106566586819609002" +--- + +## Source + +- URL: https://x.com/SebAaltonen/status/2106630618859639291 +- Author: Sebastian Aaltonen (@SebAaltonen) +- Posted: 2026-10-04 06:20:53 + +## Branch + +**1/** **@SebAaltonen** ^2106630618859639291 + +**@NOTimothyLottes** + +Funny that they say "actual fp32 compute". Meaning without the second ALU pipe, like it would be useless. Double ALU rate isn't useless, even if it requires pairing and even if it only makes games 20% faster on average. And they use the single ALU pipe math in their ALU/BW chart. + +**2/** **@SebAaltonen** ^2106631423306195057 + +**@NOTimothyLottes** + +The reason we don't see higher gain from the second ALU pipe is that there's so many shaders that are bound by samplers or memory. ALU/BW rate is already going down 42%, even with double ALU pipes, and that's the problem right there. Lots of BW bound shaders. + +**3/** **@LeviathanGamer2** ^2106649813001314342 + +**@SebAaltonen** **@NOTimothyLottes** + +Here is also the Dual-issue supporting instructions on RDNA3 onwards, which is quite limited: + +![](https://pbs.twimg.com/media/HTxS1y8XMAEB2aD?format=jpg&name=orig) + +**4/** **@LeviathanGamer2** ^2106650148780536074 + +**@SebAaltonen** **@NOTimothyLottes** + +Here is CDNA5. So far driver side this is identical for RDNA5. They have a new encoding VOPD3 as well as expanded VOPD: + +![](https://pbs.twimg.com/media/HTxTJGOWwAAC94j?format=jpg&name=orig) +![](https://pbs.twimg.com/media/HTxTJXEWcAEObSn?format=jpg&name=orig) + +**5/** **@SebAaltonen** ^2106736298186944626 + +**@LeviathanGamer2** **@NOTimothyLottes** + +Yeah. AMD chose manual dual-issue. Leans 100% on ILP. While Nvidia chose 100% TLP. Second pipeline runs different wave. Feels like history repeating (VLIW vs SIMT back in the day). + +**6/** **@SebAaltonen** ^2106736928951304342 + +**@LeviathanGamer2** **@NOTimothyLottes** + +But Nvidia’s approach to double FP ALU pipes didn’t provide more than 30% average gains in games either. Most game shaders are not heavily ALU bound. Or there’s not enough parallelism, especially below 4K resolution. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation]] diff --git a/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/index.md b/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/index.md new file mode 100644 index 0000000..02349f8 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/index.md @@ -0,0 +1,90 @@ +--- +title: "Thread: Serious talk on SteamDeck 2 speculation starting with numbers based on the nice summary here https://www.youtube.com/watch?v=QSg5pjkcg9E - TLDR, actually this is exciting if true." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2106566586819609002" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2106566586819609002" +date: 2026-10-04 +archived: 2026-10-06 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Thread: Serious talk on SteamDeck 2 speculation starting with numbers based on the nice summary here https://www.youtube.com/watch?v=QSg5pjkcg9E - TLDR, actually this is exciting if true." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2106566586819609002 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-10-04 02:06:27 + +## Thread + +**1/** **@NOTimothyLottes** ^2106566586819609002 + +Thread: Serious talk on SteamDeck 2 speculation starting with numbers based on the nice summary here https://www.youtube.com/watch?v=QSg5pjkcg9E - TLDR, actually this is exciting if true. + +![](https://pbs.twimg.com/media/HTwFo0YXAAAyit8?format=jpg&name=orig) + +Branches: [[archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation/2026-10-04-SebAaltonen-funny-that-they-say-actual-fp32-compute-meaning]] + +**2/** **@NOTimothyLottes** ^2106568550907552156 + +Lets talk 2 configurations based on Moore's Law is Dead (MLID) and The Phawx speculation numbers, + +Estimated SteamDeck 2/ +RDNA3.5 3.2 GHz * 12 CU = 38.4 + +MLID estimate of another handheld +RDNA5 1.2-1.65 GHz * 16 CU = 19.2-26.4 + +Given that estimated comparison, I'd go Deck2 + +**3/** **@NOTimothyLottes** ^2106569141523980382 + +SteamDeck has historically had rather amazing power slosh ability - if they keep this with the Deck2 and focus on higher peak clocks, it will be easy to get the CPUs to idle and actually leverage what the GPU can do! + +**4/** **@NOTimothyLottes** ^2106569394864148635 + +As for ALU:BANDWIDTH, I'll be ALU-bound, so it's ok to be thin in the bandwidth department IMO. + +**5/** **@NOTimothyLottes** ^2106570564768862394 + +As for RDNA 3.5 vs RDNA 5 - no plublic RDNA 5 ISA guide yet. RDNA 3.5 already has the one interesting thing of scalar FP32 ops. MLID says 40-50% more "raster" for RDNA 5 vs 3.5, but I doubt it. 3.5 already has dual issue FP32. Where you going to find 50% more IPC? + +**6/** **@NOTimothyLottes** ^2106571626569711985 + +Can easily push near 100% VALU issue on prior RDNA architectures before dual FP32 issue. With dual FP32 issue (3.5 has), get some amount above that of effective IPC. The next logical evolution is polishing some of the dual corner cases, but that won't bring 50% IPC in practice. + +**7/** **@NOTimothyLottes** ^2106572522846147019 + +RT is effective useless on bandwidth and cache constrained portable. And ML scaling is crap. So whatever RDNA5 brings to the table for RT and ML is simply more static parasitic power draw. + +**8/** **@NOTimothyLottes** ^2106573070970306793 + +In the end if the rumored Deck 2 specs are true, in optimized code like what I'd do, you'd see a 3x realized perf increase. And that would be way better than any RDNA5 portable that didn't have matching clock*CU count capability. + +**9/** **@NOTimothyLottes** ^2106573791384215909 + +IMO Valve would be genius to just ship the same 800p OLED. A 3x ALU perf boost with no need to push 2x or more pixels, would make devs quite happy, something that actually feels quite a bit faster. + +**10/** **@NOTimothyLottes** ^2106574254456111306 + +But I'd expect the obvious mistake of going to 1080p or 1440p. And I'd mitigate that with a CRT emulation scaling to simulate a lower resolution display. That would be a little perf tax, but nothing horrible like an ML TAA pass. + +**11/** **@NOTimothyLottes** ^2106578083260289486 + +The real danger that this possible Deck 2 presents is this: it's Linux, you don't have to use Vulkan, you can go direct to the kernel driver. Someone could use AI to write a PS5 shader binary to RDNA 3.5 binary translator, and then do direct emulation of system libraries. + +**12/** **@NOTimothyLottes** ^2106579520711242085 + +If Deck 2 would release with similar sales as Deck 1, it's past the threshold of being interesting for a single indie for a to-the-metal non-portable game too, ie something going direct to the kernel drivers with assembly shaders. + +**13/** **@NOTimothyLottes** ^2106580194249281995 + +Also one has to wonder this, if the AI slop-gramming tools are as good as people claim they are, why use C? why use Vulkan? Why not just slop-gram direct to assembly on GPU? Challenge someone to go there. diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index 6d22aef..f6f12ed 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -152,3 +152,6 @@ tags: - [[archive/threads/NOTimothyLottes/2026-08-26-tech-overlords-have-long-since-realized-just-like]] - [[archive/threads/NOTimothyLottes/2026-08-27-thinking-about-visible-pipelining-in-the-isa]] - [[archive/threads/NOTimothyLottes/2026-09-04-nothing-changes-the-physical-reality-of-the]] +- [[archive/threads/NOTimothyLottes/2026-09-15-evening-project-building-a-spiritual-successor]] +- [[archive/threads/NOTimothyLottes/2026-09-24-exploring-minimum-size-compilers-on-x86-64]] +- [[archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation]] diff --git a/archive/threads/bonzajplc/2026-07-19-if-a-game-development-studio-claims-that-it-uses/index.md b/archive/threads/bonzajplc/2026-07-19-if-a-game-development-studio-claims-that-it-uses/index.md new file mode 100644 index 0000000..9b4b01d --- /dev/null +++ b/archive/threads/bonzajplc/2026-07-19-if-a-game-development-studio-claims-that-it-uses/index.md @@ -0,0 +1,90 @@ +--- +title: "If a game development studio claims that it uses “craft coding” or that there is no AI involved in making its games, there is a strong chance that they are lying." +type: archive +source: twitter +source_url: "https://x.com/bonzajplc/status/2078746072587870291" +author: "bonzaj/plastic" +handle: bonzajplc +post_id: "2078746072587870291" +date: 2026-07-19 +archived: 2026-09-20 +draft: false +tags: + - archive + - twitter + - bonzajplc +description: "If a game development studio claims that it uses “craft coding” or that there is no AI involved in making its games, there is a strong chance that they are lying." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/bonzajplc/status/2078746072587870291 +- Author: bonzaj/plastic (@bonzajplc) +- Posted: 2026-07-19 07:37:39 + +## Thread + +**1/** **@bonzajplc** ^2078746072587870291 + +If a game development studio claims that it uses “craft coding” or that there is no AI involved in making its games, there is a strong chance that they are lying. + +I’m coming back from a gamedev event where I hosted a panel on the use of agentic AI in game development. Not a single person said that they were not using AI. + +Across the entire event, we identified only around four artists who openly opposed the use of AI. They were actively looking for work. + +**2/** **@Jonathan_Blow** ^2078918518704414987 + +**@bonzajplc** + +If any programmers on my team are using AI code generation, we will have a serious conversation the gist of which is that they need to stop immediately. If they do not stop, they would get fired. + +**3/** **@bmcnett** ^2099281497643712655 + +**@Jonathan_Blow** **@bonzajplc** + +bookmarked for future reference + +(in the last 6 months every professional programmer i know has switched to AI code generation for almost everything) + +**4/** **@NOTimothyLottes** ^2099588135214604730 + +**@bmcnett** **@Jonathan_Blow** **@bonzajplc** + +Im NOT using AI at work or at home. Im going places people haven’t gone before so slop coding is useless. + +**5/** **@NOTimothyLottes** ^2099589450820895118 + +**@bmcnett** **@Jonathan_Blow** **@bonzajplc** + +As for work, I accidentally used slop docs once and that experience was horrible, the docs had been wrong, a lot of wasted time. Also slop analysis of my code for bug searching, another waste of time. I have zero tolerance for BS, thus not compatible with slop-gramming. + +**6/** **@NOTimothyLottes** ^2099591256712134955 + +**@bmcnett** **@Jonathan_Blow** **@bonzajplc** + +I’ve seen a slop-grammer startup fail, they slopped the whole backend to rush time to market, get a few customers on before thinking about making it actually work well enough, then no one could fix it, and no time for a human to write from scratch either. + +**7/** **@NOTimothyLottes** ^2099595083586637949 + +**@bmcnett** **@Jonathan_Blow** **@bonzajplc** + +So sure pattern permutations of what is already well traveled (common) in programming can get to low time, and thus also zero value. All the interesting stuff won’t, and won’t get tab completed either, well untill some leaks it by public tool usage. + +**8/** **@bmcnett** ^2099595738204549595 + +**@NOTimothyLottes** **@Jonathan_Blow** **@bonzajplc** + +this is correct - the interesting stuff is beyond the understanding of the best models. the best they can do is implement all the small stuff quickly with high stamina, *after* you’ve already broken the interesting stuff down into a series of small stuff. + +**9/** **@NOTimothyLottes** ^2099597183913730410 + +**@bmcnett** **@Jonathan_Blow** **@bonzajplc** + +Also I’d say at the point where most of the code is say “interpolatable”, the engineering already went way wrong in the specialization via code fail. Quite literally the systems I write are sized typically to run from the cache. Just not enough code to spend effort writing faster + +**10/** **@bmcnett** ^2099598039128433141 + +**@NOTimothyLottes** **@Jonathan_Blow** **@bonzajplc** + +yes it is absolutely no good at doing the last round of optimization work before a thing ships. maaaaybe if it did an exhaustive search of the optimization space, it would get close. but setting that up can be more work than just doing it yourself diff --git a/archive/threads/bonzajplc/2026-09-17-me-and-my-plasticdemo-team-escaping-a-wave-of/index.md b/archive/threads/bonzajplc/2026-09-17-me-and-my-plasticdemo-team-escaping-a-wave-of/index.md new file mode 100644 index 0000000..c8c9120 --- /dev/null +++ b/archive/threads/bonzajplc/2026-09-17-me-and-my-plasticdemo-team-escaping-a-wave-of/index.md @@ -0,0 +1,198 @@ +--- +title: "Me and my @plasticdemo team, escaping a wave of green aliens." +type: archive +source: twitter +source_url: "https://x.com/bonzajplc/status/2100543801626390926" +author: "bonzaj/plastic" +handle: bonzajplc +post_id: "2100543801626390926" +date: 2026-09-17 +archived: 2026-09-21 +draft: false +tags: + - archive + - twitter + - bonzajplc +description: "Me and my @plasticdemo team, escaping a wave of green aliens." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/bonzajplc/status/2100543801626390926 +- Author: bonzaj/plastic (@bonzajplc) +- Posted: 2026-09-17 11:14:03 + +## Thread + +**1/** **@bonzajplc** ^2100543801626390926 + +Me and my @plasticdemo team, escaping a wave of green aliens. + +Here's a showcase of a massive deterministic GPU simulation working in multiplayer . + +Big immersive worlds are possible to run fluently online (we are in 400 km range). + +Everyone is simulating exactly the same world. + + + +**2/** **@bendzzArt** ^2100567899106914717 + +**@bonzajplc** **@plasticdemo** + +how do you handle desyncs? Players desync all the time and affect the sim right? + +**3/** **@bonzajplc** ^2100571740015337813 + +**@bendzzArt** **@plasticdemo** + +No :). Generally we need to be 100% sure that the player will not desync + +**4/** **@AgileJebrim** ^2100600800896598170 + +**@bonzajplc** **@bendzzArt** **@plasticdemo** + +Oh that’s not workable at scale then lol. You need to rework your network protocol to utilize an eventual consistency UDP approach where you just constantly stream snapshots of current local state. + +**5/** **@AgileJebrim** ^2100600901962551569 + +**@bonzajplc** **@bendzzArt** **@plasticdemo** + +Be completely unreliable where it’s perfectly fine that any packet drops. + +**6/** **@bonzajplc** ^2100602329728708682 + +**@AgileJebrim** **@bendzzArt** **@plasticdemo** + +really hard with deterministic approach. The simulation cannot progress if you won't agree that everyone has sent their actions. It's probably not scallable to 1000's of unrealiable players. it's good for party of friends. + +**7/** **@AgileJebrim** ^2100602970580697111 + +**@bonzajplc** **@bendzzArt** **@plasticdemo** + +So where is the scale of the GPU being applied if not to the players? An enormous numbers of NPCs? + +Next question: Is there an authoritative server involved or is this entirely peer-to-peer? + +**8/** **@bonzajplc** ^2100609118717321547 + +**@AgileJebrim** **@bendzzArt** **@plasticdemo** + +There is still a server. NPCs, physics, fluids, world destruction. Dynamic multiplayer world + +**9/** **@AgileJebrim** ^2100611262203769111 + +**@bonzajplc** **@bendzzArt** **@plasticdemo** + +Is the server running the code on a GPU too? + +That’s very expensive hosting for only 4 players. That’s why I encourage an architecture that can scale to a massive number of players. You can then subdivide the hosting costs among many more users. + +**10/** **@AgileJebrim** ^2100611667801313390 + +**@bonzajplc** **@bendzzArt** **@plasticdemo** + +I guess the main reason you’re using the deterministic approach is to avoid sending all that vast dynamic state data across the network. Certainly an advantage on the bandwidth cost front. + +**11/** **@59thProfile** ^2100622133105705370 + +**@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +right, only need to send inputs! + +**12/** **@AgileJebrim** ^2100623336095023274 + +**@59thProfile** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +Yep. Fine for RTSes or anything with small player counts and many entities. He could stuff multiple independent running matches into a single server node and that might make it economical. + +**13/** **@59thProfile** ^2100625981266399498 + +**@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +multiple, as in thousands probably + +**14/** **@AgileJebrim** ^2100626906219421721 + +**@59thProfile** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +Tens of thousands. :P + +**15/** **@59thProfile** ^2100631876733944223 + +**@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +yeah and if you do it right (i think bonzaj is missing something here) desync should be impossible and can potentially be used as anti-cheat primitive + +**16/** **@AgileJebrim** ^2100634824293618129 + +**@59thProfile** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +Since his server is just a relay, he’s got no way to send someone the current state of the game newly connected or reconnected unless he either replays every packet that’s ever occurred or more likely just have one player forward a snapshot of their current state of the game. + +**17/** **@AgileJebrim** ^2100635000584470582 + +**@59thProfile** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +The game is also only as fast as the slowest player’s connection if he’s doing it like I think he is. That’s not good. + +**18/** **@bonzajplc** ^2100646208037433519 + +**@AgileJebrim** **@59thProfile** **@bendzzArt** **@plasticdemo** + +Yeah, that’s why I look into consoles :) + +**19/** **@AgileJebrim** ^2100646372349190392 + +**@bonzajplc** **@59thProfile** **@bendzzArt** **@plasticdemo** + +Doesn’t do much good if they’re on WiFi and constantly disconnecting. + +**20/** **@NOTimothyLottes** ^2100648916634984482 + +**@AgileJebrim** **@bonzajplc** **@59thProfile** **@bendzzArt** **@plasticdemo** + +When it’s massive destruction, I can seen the appeal of deterministic sim. Now if the sim can run faster than real-time you can handle disconnection. Clients that dont make the sim frame’s time cut have to take a predicted future state for the sim frame …. + +**21/** **@NOTimothyLottes** ^2100650025999093837 + +**@AgileJebrim** **@bonzajplc** **@59thProfile** **@bendzzArt** **@plasticdemo** + +Reconnect, the server give the corrected past, run faster than real-time until time syncs again, with all the workarounds that requires. Same with late connection, you’ve see the game in fast forward until the timelines meet. At least you only sync action and not effect. + +**22/** **@59thProfile** ^2100652524583723029 + +**@NOTimothyLottes** **@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +Server doesn’t have to do anything you could just relay the client + +**23/** **@NOTimothyLottes** ^2100658236483330316 + +**@59thProfile** **@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +In my example the server is relaying the authoritive actions for the frame (or series of past frames). Assuming no P2P in the architecture. Note Im assuming the server is also running the sim to correct for clients behaviors on forward extrapolation state that players see. + +**24/** **@NOTimothyLottes** ^2100659503112892821 + +**@59thProfile** **@AgileJebrim** **@bonzajplc** **@bendzzArt** **@plasticdemo** + +Im working on something with non deterministic massive destruction. But locally relative sync of state between peers. So effectively the opposite design. But seeing full deterministic in the video, is quite inspiring. + +**25/** **@bonzajplc** ^2100666022152003834 + +Maintaining that is quite a challange. yesterday I Introduced a change that breaks determinism randomly on one of the tests. The problem is that it triggered today after 10 other merges from the team. + +Also I know now that driver updates can also break determinism. By that I mean between players. We can detect that their startup hashes (based on a test that coverages most of the features) is different and warn them that they may desync, but it's quite nasty design + +**26/** **@NOTimothyLottes** ^2100667343441436815 + +**@bonzajplc** **@59thProfile** **@AgileJebrim** **@bendzzArt** **@plasticdemo** + +Haha, driver updates as in compiler changes to float ordering and factoring … if I went deterministic, I’d go to integer maths. But I did most of my learnings pre floating point, so integer is easy in the brain. + +**27/** **@NOTimothyLottes** ^2100667901661356378 + +**@bonzajplc** **@59thProfile** **@AgileJebrim** **@bendzzArt** **@plasticdemo** + +You could do screwy things like alias to int and zero the LSB bit periodically to force some amount of float sanity in the compiler (because the AND cannot be moved relative to neighboring ops). diff --git a/archive/threads/bonzajplc/index.md b/archive/threads/bonzajplc/index.md index f5a208f..31ea6f9 100644 --- a/archive/threads/bonzajplc/index.md +++ b/archive/threads/bonzajplc/index.md @@ -10,3 +10,5 @@ tags: --- - [[archive/threads/bonzajplc/2018-02-18-unity-tip-update]] +- [[archive/threads/bonzajplc/2026-07-19-if-a-game-development-studio-claims-that-it-uses]] +- [[archive/threads/bonzajplc/2026-09-17-me-and-my-plasticdemo-team-escaping-a-wave-of]] diff --git a/archive/threads/index.md b/archive/threads/index.md index 463bb7a..9b14736 100644 --- a/archive/threads/index.md +++ b/archive/threads/index.md @@ -27,6 +27,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/ChipsandCheese9]] - [[archive/threads/cmuratori]] - [[archive/threads/danishnxt]] +- [[archive/threads/DemetriSpanos]] - [[archive/threads/DevLeaderCa]] - [[archive/threads/dharmatrade]] - [[archive/threads/Dispatch_Graph]]