reitzensteinm

Ember is an absolute treasure. Often you'll see articles on HN from places like Elektrek which are blogspam linking back to Ember's original reporting.

Their electricity data explorer is to my knowledge the most complete on the open internet.

Could you macroexpand your claims a little here?

"An example of the unaddressed complexity: use of acquire-release semantics for head_ and tail_ atomics imposes no ordering whatsoever between observations of head_ and tail_."

The Acquire / Release in version 4 looks right to me, but I'd like to know if I'm missing something.

Also, while your linked paper is good background for what the C++11 memory model is intended to abstract over, it's almost entirely its own thing with a mountain of complexity.

Somebody else in this comment section brought atomics knowledge to an Acquire/Release fight and it didn't go well.

As a starting introduction I'd probably recommend this:

https://www.amazon.com.au/C-Concurrency-Action-Practical-Mul...

How did you test with 1024 players - were they real? Often synthetic loads are very different to those caused by real players.

I owned an i9 MBP with a discrete GPU. It absolutely was too thin. The CPU and GPU ran hot, it throttled like crazy. It would drain battery while USB-C docked while idling. Worst laptop I've ever owned.

The M1 Max I replaced it with was the opposite. I don't think I heard the fans for the first month. But it was much larger.

Based on the fanless Air, I strongly suspect an M1 Max in the old chassis would have been totally fine for non synthetic workloads and an M1 Pro would probably have been fine in all scenarios.

But I think they over corrected on the chassis design when they were shipping borderline faulty products and haven't walked it back yet.

It's all about relative difficulty. It's not trivial to convince LLM vendors to include your pet new language in their internal synthetic datasets, and you can build your own and publish it but it'll be fiddly and expensive.

But compared to the immense amount of effort that goes into convincing a critical mass of humans to learn and write about your new language, and using _that_ material to train an LLM, I think it's fair to say things have gotten easier, not harder.

Coding is a verifiable domain, so I think you actually have it backwards on that first point. We can now synthesize Stack Overflow sized datasets for an arbitrary new language, and use those to train LLMs to understand it.

It's expensive of course, but if a new language is genuinely better for LLMs to write and understand, that would not be an issue.

The keen cynics of Hacker News have unmasked seven of the last three major astroturfing campaigns.

> Quite a red flag in retrospect.

No pun intended?

It would have been a super reasonable reply to talk about the history of TypeScript, why fundamentally its types exist to retroactively describe complicated datastructures encountered in real world JavaScript. And why when TypeScript overstepped that by creating enums, which require code generation and not mere type erasure to compile, it was decided to be a mistake that they won't repeat.

But instead your rebuttal was pointing out that TypeScript can compile OP's example code, which OP presented as valid TypeScript that they disliked. I'm not defending their position, I'm just saying that it didn't appear you had even properly read their comment.

type Mutt = Dog & Cat

const imposter: Mutt = { bark: () => console.log("woof"), meow: () => console.log("meow"), }

You're both misunderstanding parent's point as well as the original point. Nobody ever claimed your link wouldn't compile.

Nah, the analogy for your argument is:

Two Americans and ten Chinese are on a lifeboat. The Americans are each eating two sandwiches a day and the Chinese are eating one. Supplies are low. You do the math and note that the Chinese sure are eating a lot of sandwiches.

But how did he find out about that line?

If he was intentionally reading the notes his wife took of attorney meetings regarding their divorce, you may want to consider the possibility that the DVRO was genuinely sought.

Parakeet V3 is over twice the parameter count of Moonshine Medium (600m vs 245m), so it's not an apples to apples comparison.

I'm actually a little surprised they haven't added model size to that chart.

Proceeds going to charity is a must for me - it keeps it friendly and significantly reduces the impact of counterparty risk.

There's a reason Long Now uses this format, and I'm happy to use their platform and pay the fee: https://longbets.org/rules/

Email is reitzensteinm@gmail.com if you're interested.

Claude Code would have been science fiction five years ago. I'm not looking a gift horse in the mouth over a few papercuts.

No, they're generally pretty solid. Once an hour one will crash, and sometimes there are performance problems, but it's a very workable setup.

The field will spread. I'm working on what I'm intending up be the best game of my career, but you can ship barely functional slop in a few days.

I think this is doable for very long tail experts that get swapped in for specialised topics - say, orbital mechanics.

But for experts that light up at, say, 1% frequency per batch, you're doing an awful lot of transfers from DRAM which you amortize over a single token, instead of reads from HBM which you amortize over 32 tokens.

Yeah, I've got a 7950x and 64gb memory. My vibe coding setup for Bevy game development is eight Claude Code instances split across a single terminal window. It's magical.

I tried the desktop app and was shocked at the performance. Conversations would take a full second to load, making rapidly switching intolerable. Kicking off a new task seems to hang for multiple seconds while I'm assuming the process spins up.

I wanted to try a disposable conversations per feature with git worktree integration workflow for an hour to see how it contrasted, but couldn't even make it ten minutes without bailing back to the terminal.

I think part of the issue is that in production deployments, you're batching high enough that you'll be paging in those long tail experts constantly.

Unless you're handing that in some kind of fancy way, you'll be holding up the batch while waiting for host memory which will kill your throughout.

It makes much more sense for non batched local inference, especially if you can keep the MoE routing stable like you say, but most folks aren't optimising for that.

Sure. I'll bet you that in calendar year 2028 Waymo has more paid passenger trips than Tesla. Loser donates $1k USD to Doctors Without Borders.

I'm not a camera only doomer, and expect that in ten years Waymo will also not use Lidar, or that the units will be incredibly cheap and well integrated.

But I think the pro Tesla camp is exaggerating how quickly the march of 9s will happen for them, and underestimating and how quickly Waymo will expand in the next few years.

Loom does exhaustive search, with clever methods to prune it. On real world programs, you have to set a limit to that because it obviously grows extremely quickly even with the pruning.

I've built something similar to Loom, except it's more focused on extensively modeling the C++11/Rust memory model (https://github.com/reitzensteinm/temper). My experience is that fairly shallow random concurrent fuzzing yields the vast majority of all concurrency bugs.

Antithesis (https://antithesis.com/) are probably the leaders of the pack in going deeper.

Martin Kleppmann has this tool that's quite relevant: https://martin.kleppmann.com/2014/11/25/hermitage-testing-th...

Well, even if the levels are well made and I've just got poor taste, Half Life was such a tightly designed package, introducing new weapons, things to play with (like the trains), enemies, environment modifiers at a steady pace.

Replacing a 5 minute level with a 20 minute level, even if it's better, ruins that pacing. There's just not enough content in the game to support it.

I agree Xen was by far the weakest of the original levels, but I don't think it's a coincidence that it was also pretty short. I think they knew it had novelty but no staying power and probably cut it to the bone.

Black Mesa is an almost exact copy of Half Life at the start, and where that's true it's incredibly well done. Feels very much like a remaster.

Unfortunately, by the end of the earth levels and certainly on Xen, the levels switch over to original designs. They become massive and sprawling, boring and confusing. They really should have stuck to doing a like for like reimplementation.

I grew up on Half Life, so playing the first half of Black Mesa a few years ago was one of my favorite adult gaming experiences. But I gave up who knows how close to finish line after Xen was insufferable.

But coding is largely trained on synthetic data.

For example, Claude can fluently generate Bevy code as of the training cutoff date, and there's no way there's enough training data on the web to explain this. There's an agent somewhere in a compile test loop generating Bevy examples.

A custom LLM language could have fine grained fuzzing, mocking, concurrent calling, memoization and other features that allow LLMs to generate and debug synthetic code more effectively.

If that works, there's a pathway to a novel language having higher quality training data than even Python.

Yet 2025 power sector emissions fell, which is quite discordant with the picture you're attempting to paint.

https://ember-energy.org/data/electricity-data-explorer/?dat...

It's a good call out re: tokens vs letters, but I think you might have misunderstood my point - you can't do it a token at a time unless the intermediate KV cache is stored after each token is generated.

This won't be the case in any non toy implementation, as it would be unneccessary and slow.

Hill climbing a password would only be possible if intermediate KV cache entries were stored. To hillclimb "hunter2", you're going to try "a", "b", "c", etc, until you notice that "h" comes back faster. Then you try "ha", "hb" and so on.

But that's only going to work if the cache looks like: "h", "hu", "hun", ..., "hunter2"

If just "hunter2" is in the cache, you won't get any signal until you stumble on exactly that password. And that's before getting into the block size granularity of the caches discussed elsewhere in this thread.

That's not to say timing attacks aren't possible. I haven't looked at Claude Code's prompt generation, but there's no intrinsic reason why you couldn't do things like figure out what open source code and research papers your competitors are loading into context.

Sharing caches between orgs would be an incredible misstep.

I'm a little nervous about the correctness of the memory orderings in this project, e.g.

Two acquires back to back are unnecessary here. In general, fetch_sub and fetch_add should give enough guarantees for this file in Relaxed. https://github.com/frostyplanet/crossfire-rs/blob/master/src...

Congest is never written to with release, so the Acquire is never used to form a release chain: https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...

The queue appears to close the channel twice (once per rx/tx), which is discordant with the apparent care taken with the fencing. https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...

The author also suggests an incorrect optimization to Tokio here which suggests a lack of understanding of what the specific guarantees given are: https://github.com/tokio-rs/tokio/pull/7622

The tests do not appear to simulate the queue in Loom, which would be a very, very good idea.

This stuff is hard. I almost certainly made a mistake in what I've written above (edit: I did!). In practice, the queue is probably fine to use, but I wouldn't be shocked if there's a heisenbug lurking in this codebase that manifests something like: it all works fine now, but in the next LLVM version an optimization pass is added which breaks it on ARM in release mode, and after that the queue yields duplicate values in a busy loop every few million reads which is only triggered on Graviton processors.

Or something. Like I said, this stuff is hard. I wrote a very detailed simulator for the Rust/C++ memory model, have implemented dozens of lockless algorithms, and I still make a mistake every time I go to write code. You need to simulate it with something like Loom to have any hope of a robust implementation.

For anyone interested in learning about Rust's memory model, I can't recommend enough Rust Atomics and Locks:

https://marabos.nl/atomics/