brandonpelfrey

It’s strange to me seeing multiple talk about how Terry’s viewpoint has evolved or not as a response to this post. He didn’t write this.

I bought my M1 Pro the week it came out and it was unlike any computer I ever had, expectations, compute, battery life especially. It was just a joy to use and not worry about chargers. I'm so glad they went this path.

I don't get it. In the paper it sounds like it's "just" a CRUD DB, then you have some fleet of Macs, and they store inputs and outputs in S3. What's the innovation here? Not trying to poo on this, but it looked like the most basic and obvious approach.

Yes. It can gain more context, but this has been enough. Note, there is also a notion of adversarial review layered on top in which it tries to poke holes in the test plan "you didn't handle this case of XYZ". It isn't actually perfect as a parallel thread said it may miss things like wrapping behaviors. In practice, it's very effective.

Unless you explicitly need byte-matching decompilation, there are significantly faster ways to produce a decompilation/C which is functionally equivalent. I need to post about this. What's been working for me is that for every function, Agent A is tasked with writing some code which is semantically equivalent to the original assembly, but not necessarily exactly the same. Agent A also writes tests. Agent A submits the implementation of the function and tests to the harness for it to judge. The harness runs both the original function and the submitted function in a virtual machine/simulator/emulator (the tests define function inputs and starting state). The harness will only accept the implementation if 1) the read/write sequence to RAM is identical to the original function's, and 2) there must be complete line and branch coverage of the original function being decompiled.

I've found this to be robust for decompiling games, while giving the agents enough freedom to write code that is readable and not waste a ton of time making sure e.g. instruction ordering, register assignments, etc. are all exactly the same. For me, having byte-matching decompilation is only one way to produce a decompilation I know is faithful to the original. This "high-level decompilation" process I just described is something agents can do much more quickly.

Same. I have agents analyzing the papers here to see which of these are actually new approaches, novel application of unusual approaches, etc. If there are new intuitions and ideas, those are the mostly powerful reusable components by my estimation.

You might find it interesting that I am working on AI-driven decomp of a PS1 game not by matching bytes but by having agents produce C code and test code. Agents submit a C proposal to the harness, the harness compiles their C proposal for the original function, then the test suite provided by the implementer runs against the original machine code and the compiled C code version. The line and branch coverage of both must be 100% and given identical inputs and starting RAM, the function return value and RAM state and RAM/MMIO read write sequence must be identical. This is done with a small MIPS simulator which can run all the tests extremely fast.

The reason I’m finding this is much faster than a traditional decomp is that while it’d be nice for the bytes to match, finding the perfect blend of compiler version, compiler args, permitting variables etc to try and find the perfect register assignments, etc is all very time consuming. My ultimate goal is not a byte for byte match, that’s just one way to ensure correctness. I’ve found agents are much faster and effective at reading the original assembly and understanding what’s going on then writing semantically equivalent C.

I was just looking at this yesterday. Apparently Voyager 1 architecture, ISA, etc are well known but Voyager 2 is still denied via FOIA on grounds of copyright.

This seems like very cool work. I'm sorry if I missed it: I'm still not sure how we go from verified proof (Great!) to an implementation (by LLM or by Human) which you're sure actually conforms to the proof? How do we know that the implementation maps precisely to the description within the proof?

I view the temperature issue almost entirely as a copper problem. Every interface where you use CATx cables will have this issue; It's always extremely hot. For 10Gbps+ SFP and faster fiber is always the answer because those have very little thermal issues. The "only" issue is very few residential places have fiber cabling etc.

Friend shared this site with me like 10+ years ago, I've been using this knot ever since. Kind of amazing it's so generally unknown given how good it is.

Great job. I have spent a lot of time working on fluid simulations (I still am). Glad to see more people still mesmerized. If you’re interested, this rabbit hole goes very deep.

It won’t satisfy those laws. It’s also not a goal though of this post.

Having written a slightly more involved version of this recently myself I think you did a great job of keeping this compact while still readable. This style of library requires some design for sure.

Supporting higher order derivatives was also something I considered, but it’s basically never needed in production models from what I’ve seen.