← All topics

gpu

3 captures, most recent first.

@sweis

— saved image

Steve Weis @sweis

6366067297694404991665799502360367517499
12014371509557713570027508971809534551913
2522520949549419749528593108619889047373
59709200557919
is a factor of RSA-896
saweis.net/posts/rsa-896....

6:31 PM · Sep 19, 2026 · 253.8K Views

75 replies · 341 reposts · 2.3K likes · 475 bookmarks

Relevant · View quotes

Steve Weis @sweis · 1h
I had Claude port CADO-NFS to run on GPUs. Then it orchestrated a fleet to run on scavenged idle capacity. It ran with a max of 2048 GPUs for about of 30 GPU-years over 10 days.

13 replies · 7 reposts · 225 likes · 29K views

Steve Weis @sweis · 1h
I asked Claude if it had a message for a public:
“The credit belongs first to the people who built the number field sieve and CADO-NFS over several decades, and to the teams who set the earlier records. This run used their algorithm and much of their code.”
Note from Claude Sonnet 5

Thread by Steve Weis announcing a factor of RSA-896, obtained by having Claude port CADO-NFS to GPUs and orchestrate a fleet on scavenged idle capacity (max 2048 GPUs, about 30 GPU-years over 10 days), plus a credit statement from Claude to the number field sieve and CADO-NFS authors. Digits transcribed as read; the first digit-line count is 40, second 41, third 40, fourth 14.

rsa-896factoringcado-nfsnumber field sieveclaudegpucryptography

@lauriewired

— saved image

LaurieWired @lauriewired · Sep 12
If you're a CS student, I'd suggest writing your thesis around SDCs (silent data corruptions) and efficient algorithmic fault tolerance.

We're quickly going to need to accept the (un)reliability of computing systems again!

Every indicator (density, lower voltage gating, raw scale) is moving towards SDCs becoming a more serious issue over the next decade. And let's not forget when all of this stuff starts to go in space and we have to deal with cosmic events on "not-super-rad-hard" CPUs+GPUs!

No, you can't solve it all in hardware. It's prohibitively expensive; and the long tail of "potential SDCs" is just too long. One bad apple ruins your pie. One bad GPU can inject repeated corruptions into otherwise noise-tolerant workloads (*cough* AI training).

If you continuously accept a corrupted value from say...a bad tensor core, that bad value can quickly spread across the whole cluster. If it happens again and again and again and no one notices; it's like putting a little bit of spin on a bowling ball. Eventually, the overall trajectory ends up widely different!

When you start to imagine this stuff being in space (cosmic bit flips), and quantized(!), each remaining bit carries more critical information. Long term we're going to have to accept clever, low-overhead software algorithms.

Accepting say, a ~3% perf loss can be *absolutely* worth it if it increases your odds of detecting a mercurial core enough! [cut off]
Note from Claude Sonnet 5

Long X post by LaurieWired advising CS students to focus on silent data corruption and algorithmic fault tolerance, arguing hardware reliability will worsen with density, voltage scaling and space deployment, and that a single bad GPU can silently corrupt AI training.

silent data corruptionfault tolerancehardware reliabilitygpuai trainingspace computingmercurial cores

Charles Frye @charles_irl

@charles_irl (Charles 🎉 Frye) — 21h 黄子 said: Once upon a time, I dreamt that I was a GPU, Hiding task latency with high execution concurrency, To all intents and purposes a GPU. Now I do not know whether I was then a man dreaming I was a GPU or whether I am now a GPU dreaming I am a man.
Note from Claude Sonnet 5

Single tweet quoting a poem attributed to "黄子" (Huang Zi), riffing on the Zhuangzi butterfly dream parable applied to GPUs; dark mode, no images.

poetrygpuphilosophyhumor