I've had significant success using DS 4 Pro and now 4.1 flash for fairly complex coding tasks on C++, Rust and Python projects at home.
I have access to Claude Code at work (and use it quite a bit), so I feel I can honestly compare them.
You do have to plan things first a bit more with DS (than say Opus can (Opus will have more chance of one-shotting something, although I generally don't think that's a good idea), although it often over-engineers and tries to be too helpful in my experience) and be a bit more explicit at times, but I feel it's quite close to Sonnet in performance for implementing plans, debugging issues and explaining how codebases work.
Yeah, I've often wondered about this, but more locally (say within a local office, or maybe a data centre)...
I wonder if even "just" throttling up/down the CPU / GPU on tasks as morse code might be visible externally to other devices on the same mains supply. Obviously it would be very inefficient speed-wise, but a higher current (say + 300 watts for the GPU being used) should result in a slightly lower voltage on the mains supply I think for the duration?
Obviously things like PSUs could (I'm not an expert at any of this) get in the way of this, and I'd assume in data centres there's some isolation between different racks.
But for a scenario of DIY "airgapping" two machines in an office for AI testing (i.e. not doing it very well), it might be a plausible way of AIs finding to communicate if there's no actual network connection.
Obviously other electronic devices connected to the same mains circuit could also be adding their own noise, which might make it a lot harder to actually identify and decode the response, but... if ML/AI agents are good at anything, it's finding patterns, so I wouldn't want to bet against it being theoretically possible...
I'm confused by the scenarios in this thread. How is the machine on the other side receiving this information? How is it measuring voltages on the mains supply, or receiving radio waves emitted by RAM?
It wouldn't measure it directly, it would (admittedly, very hypothetically) be able to measure a knock-on effect of the mains voltage change via secondary effects: i.e. CPU/GPU frequency changing, PSU fan speeds changing a very small amount from the expected rate, maybe even the motherboard / CPU socket voltage amount directly changing (some motherboards expose this info directly for overclocking use).
Obviously, given variation in these things anyway (i.e. due to temperature, and PSUs being in the way), it's incredibly unlikely to be that easy to pin down a robust communications method, but again, might be just within the bounds of possibility.
Without wanting to be snarky, are the "hand optimized" C++ benchmark files mentioned on the benchmark page available anywhere, as the ones in the "bench/cpp/" directory don't look that optimized to me?
e.g. I see a general lack of reserve()s on strings and vectors (a few tests do use them a bit, like `graph` and `particles`), and there are several other things which I wouldn't personally call "optimized", so I assume those ones are the 'idiomatic' ones?
Same goes for the Rust code: a lot of the code seems to be using Vec::new() and String::new(), instead of ::with_capacity() which would optimize the memory re-allocation (reducing it as the containers/strings grow).
It's been a few years since I last tried, so hopefully no longer an issue, but trying to encode 8192 × 5464 images from a Canon R5 a few years ago with libavif, and avifEncoderAddImage() would return a generic error.
If I reduced the res a bit, then it worked, so there did seem to be a limit there somewhere. height and width are stored as u32s internally though, so yes, the format itself technically supports it...
I never looked into it more, so might have been a libavif issue, or maybe the way I was using it (maybe it has defaults or profiles?)
Maybe it's doing all sorts of queries internally.
reply