Pinned Tweet
Left: From-scratch debug build, launching target, and stepping with RADDBG.
Right: Launching target & stepping with Visual Studio 2022.
Right: Launching target & stepping with Visual Studio 2022.
52
153
1,776
710,869
Ryan Fleury retweeted
We have origin and/or "ingredient" labeling for most kinds of consumer products. It is an anomaly that software has not been required to have such disclosures. I think it's very reasonable to require AI use to be disclosed, as well as other information that may be relevant.
@mattworkman Forcing developers to write a political statement to be used against them by the hate mob they’re helping organize is abhorrent.
75
67
1,167
31,519
See, if we want really good food made very efficiently, what we should do is get the world's top chefs, and then force feed them hundreds of pounds of factory produced microwaved slop. They will use their discernment and taste to pick the best ones. Taste is the new moat
14
25
607
12,968
Early progress on remote debugging! Some slowness and a bug at the end to fix, but getting much more solid.
4
8
347
8,057
I’ve kept the functionality for multi-process debugging working since the beginning of RADDBG, but I’ve never really dogfooded it much because I’ve mostly focused on one process. That is, until now. It has been absolutely awesome for client/server debugging!
One thing which might not be obvious is that this pass over the debug engine is for supporting *multi-server*, multi-process debugging. This means you can debug a remote server *and* a remote client (or a local client), all at once.
One thing which might not be obvious is that this pass over the debug engine is for supporting *multi-server*, multi-process debugging. This means you can debug a remote server *and* a remote client (or a local client), all at once.
5
3
62
3,233
Lol, turns out the slowness is almost entirely just conhost, due to the simple logging on the server. Amazing.
1
0
33
1,539
The multitude of "searching for a needle in a haystack" games are fitting for the modern programming era, because searching for value in an LLM-generated PR is doing effectively that.
5
8
328
7,665
Ryan Fleury retweeted
When I design performance code, I always think about the working set. How much data we access and what kind of access pattern. Can the L1$ hold it all.
Petafab material pass was sampling SDF to calculate normal. Nothing else accesses the SDF in this pass, so L1$ is cold. zed codebase) did normal calculation at end of the SDF sphere tracing pass (compute shader). It is guaranteed to hit L1$ there. No extra memory traffic. RGB10A2 normal of course requires some memory bandwidth on its own, but it's extremely cache coherent and delta color compressed.
Similarly I split the SDF AO rays and shadow rays to separate passes, so that material shader doesn't need to access the SDF at all.
Combining passes can be a win, but if they access a completely different data set, you are just increasing your working set size, and you get more L1$ trashing. Splitting processing by data access, and communicating with minimal data between processing steps (such as 8-bit SSAO/shadow mask) is a huge win.
Petafab material pass was sampling SDF to calculate normal. Nothing else accesses the SDF in this pass, so L1$ is cold. zed codebase) did normal calculation at end of the SDF sphere tracing pass (compute shader). It is guaranteed to hit L1$ there. No extra memory traffic. RGB10A2 normal of course requires some memory bandwidth on its own, but it's extremely cache coherent and delta color compressed.
Similarly I split the SDF AO rays and shadow rays to separate passes, so that material shader doesn't need to access the SDF at all.
Combining passes can be a win, but if they access a completely different data set, you are just increasing your working set size, and you get more L1$ trashing. Splitting processing by data access, and communicating with minimal data between processing steps (such as 8-bit SSAO/shadow mask) is a huge win.
4
7
196
7,442
Step 7 of bare metal N64 programming: using the C processor to assemble MIPS code (with the vector instruction extensions) for the RSP, uploading it, and running it. Next step will be using it to more quickly build RDP commands!
Step 6 of bare metal M64 programming: Still building RDP command buffers on the CPU. But now worked out depth testing and rasterization parameters for projected triangles.
5
7
182
4,921
Ryan Fleury retweeted
First Blick development blog post by @falk_moritz, if you're wondering how fast and resource efficient immediate mode UI can be for desktop applications, you can read about it here!
A look under the hood of Blick. @falk_moritz shares how our UI renderer works and some of the decisions that shaped it. blickeditor.com/blog/caching-a…
4
8
147
5,287
Ryan Fleury retweeted
@rfleury I recommend any dev to try reverse engineering their own (small) binaries at least once!
try writing a really simple program in C, and then do it again in rust.
drop it in ghidra, use a model / mcp / whatever to churn away at it, and watch how different (or not!) the decompilation is from the original source code. you'll be surprised how it looks...especially rust (lol)
try writing a really simple program in C, and then do it again in rust.
drop it in ghidra, use a model / mcp / whatever to churn away at it, and watch how different (or not!) the decompilation is from the original source code. you'll be surprised how it looks...especially rust (lol)
2
7
320
9,237
🚨 BREAKING: Texas Instruments declares HUMANS THE BOTTLENECK when doing calculations on the TI-84
Anthropic’s report is basically saying humans are the bottleneck.
“Amid this model-driven acceleration, human attention is a constant bottleneck. Claude sessions amount to around 80% idly waiting for human input. As one engineer put it, people are “bottlenecking the agents.”
13
50
1,173
18,138
