From b67e75857122dfd50ba7d1baff0cbe1cbb796fcb Mon Sep 17 00:00:00 2001 From: Ed_ Date: Fri, 4 Sep 2026 23:15:33 -0400 Subject: [PATCH] 2095923859547463785, 2095864387957412044 --- .../index.md | 50 +++++++++++++++++++ archive/threads/NOTimothyLottes/index.md | 1 + archive/threads/index.md | 1 + .../index.md | 47 +++++++++++++++++ archive/threads/stainless_code/index.md | 12 +++++ 5 files changed, 111 insertions(+) create mode 100644 archive/threads/NOTimothyLottes/2026-09-04-nothing-changes-the-physical-reality-of-the/index.md create mode 100644 archive/threads/stainless_code/2026-09-04-even-on-the-cpu-indices-pointers/index.md create mode 100644 archive/threads/stainless_code/index.md diff --git a/archive/threads/NOTimothyLottes/2026-09-04-nothing-changes-the-physical-reality-of-the/index.md b/archive/threads/NOTimothyLottes/2026-09-04-nothing-changes-the-physical-reality-of-the/index.md new file mode 100644 index 0000000..ef953a6 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-09-04-nothing-changes-the-physical-reality-of-the/index.md @@ -0,0 +1,50 @@ +--- +title: "Nothing changes the physical reality of the inefficiency of a vector of 64-bit pointers on the GPU." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2095864387957412044" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2095864387957412044" +date: 2026-09-04 +archived: 2026-09-04 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Nothing changes the physical reality of the inefficiency of a vector of 64-bit pointers on the GPU." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2095864387957412044 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-09-04 13:19:44 + +## Thread + +**1/** **@NOTimothyLottes** ^2095864387957412044 + +Nothing changes the physical reality of the inefficiency of a vector of 64-bit pointers on the GPU. It will always take double the register file space, double the ALU ops to manipulate compared to using HW shifted 32-bit indexes. + +**2/** **@NOTimothyLottes** ^2095865683745632563 + +4-byte type with a shifted 32-bit index supports a 16 GiB address window of buffer access. A 16-byte type with a shifted 32-bit index supports a 64 GiB address windows of buffer access. More than enough given where {cost,thermal,power,perf} scales to in a human lifetime. + +**3/** **@NOTimothyLottes** ^2095866371796058560 + +Nothing changes the reality that 64-bit pointer loads of packed types like {shared exponent}, {11,11,10 float}, {8:8:8:8 sRGB}, and even {10:10:10:2 unorm} are effectively too slow to be of any use due to ALU overhead to decode. + +**4/** **@NOTimothyLottes** ^2095866785899659649 + +So the argument to say raw non-typed 64-bit pointers are future forward is to say discard the very basic of compressed types in buffer storage, ie the foundation of programmable vertex fetch. That is just stupid. + +**5/** **@NOTimothyLottes** ^2095867642342941073 + +To argue that peak always hit in the cache performance of say raw 32-bit values grabbed from 64-bit pointers on any architecture is what correlates with actual performance in real complex programs is also totally naive. + +**6/** **@NOTimothyLottes** ^2095868058485068266 + +If you are bandwidth bound, then it is often the HW type conversion that is important. If you are ALU bound, then it is getting logic off the ALU that is important (that 2x pointer math cost, or type conversion cost, etc), and if you are latency bound, then the 2x vgpr cost kills diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index 9378d14..6d22aef 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -151,3 +151,4 @@ tags: - [[archive/threads/NOTimothyLottes/2026-08-26-for-an-integer-dsp-if-one-wants-2-negative]] - [[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]] diff --git a/archive/threads/index.md b/archive/threads/index.md index 60e47ec..463bb7a 100644 --- a/archive/threads/index.md +++ b/archive/threads/index.md @@ -87,6 +87,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/SheriefFYI]] - [[archive/threads/simplex_fx]] - [[archive/threads/skdh]] +- [[archive/threads/stainless_code]] - [[archive/threads/TheAllenChou]] - [[archive/threads/TheGingerBill]] - [[archive/threads/ThePrimeagen]] diff --git a/archive/threads/stainless_code/2026-09-04-even-on-the-cpu-indices-pointers/index.md b/archive/threads/stainless_code/2026-09-04-even-on-the-cpu-indices-pointers/index.md new file mode 100644 index 0000000..06fec7e --- /dev/null +++ b/archive/threads/stainless_code/2026-09-04-even-on-the-cpu-indices-pointers/index.md @@ -0,0 +1,47 @@ +--- +title: "Even on the cpu indices > pointers." +type: archive +source: twitter +source_url: "https://x.com/stainless_code/status/2095923859547463785" +author: "Yuriy Stets" +handle: stainless_code +post_id: "2095923859547463785" +date: 2026-09-04 +archived: 2026-09-04 +draft: false +tags: + - archive + - twitter + - stainless_code +description: "Even on the cpu indices > pointers." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/stainless_code/status/2095923859547463785 +- Author: Yuriy Stets (@stainless_code) +- Posted: 2026-09-04 17:16:03 + +## Thread + +**1/** **@stainless_code** ^2095923859547463785 + +Even on the cpu indices > pointers. +The pointers waste a lot of cache space to store useless bits that do not carry much of a value. + +But I havent yet found a good/elegant solution of how to organize storage of multiple indices that belong to different contiguous chunks of memory. +Because if all of your indices belong to a single space, then you can carry the single base pointer around OOB, and index only off of that pointer. But If you have multiple spaces, let's say one or more index spaces per thread (e.g. per-thread arenas or something), like what would be an efficient way to represent that. +One way you can take some bits of an index to say which chunk you want to address into, but that eats into the size of indexable space and if you have a user-selectable number of threads - the number of bits reserved would be unpredictable. + +**2/** **@NOTimothyLottes** ^2095927369949184094 + +**@stainless_code** + +The right workaround is to have a way to run a process in a lower bounded address space. Hell, we have a VM tax we already pay for, so this is trivial. On Linux you can just do this and use system calls and bypass libc/etc. Only then some interfaces like Vulkan need workarounds. + +**3/** **@NOTimothyLottes** ^2095928068615307653 + +**@stainless_code** + +I personally indexify my VK dlsym() jump table down to 32-bit indexes from a fixed base, but of course some VK objects still force a little 64bit waste. diff --git a/archive/threads/stainless_code/index.md b/archive/threads/stainless_code/index.md new file mode 100644 index 0000000..b195d75 --- /dev/null +++ b/archive/threads/stainless_code/index.md @@ -0,0 +1,12 @@ +--- +title: stainless_code +type: note +draft: false +description: Archived threads by stainless_code. +tags: + - archive + - twitter + - stainless_code +--- + +- [[archive/threads/stainless_code/2026-09-04-even-on-the-cpu-indices-pointers]]