Yes they are complicated. But with enough rigor, structure and discipline, it is doable without breaking correctness guarantees.

Making it distributed opens a whole can of worms, which is where Jepsen shines.

What exactly is the architectural problem that has you convinced LLMs cannot learn how to strategize and architect well after enough RL?

It is combinatorial explosion of possible states (not as in memory state of program, but the differing visions of the next state of architecture). Plus high impact of mistakes, suboptimal solutions and randomness when switching between states.

Edit: I like this 10 years old blog post in regards to explaining the problem much better than I could do: https://pron.github.io/posts/correctness-and-complexity

How does this make the case for humans forever exceeding LLMs in planning and architecture? It doesn’t explain why a neural net couldn’t learn to do better than humans on this task at all. It certainly doesn’t point out any deficiency of attention, transformers, layers, encoders, decoders, or how the layers or their inputs/outputs are set up.

Yeah, good question, thanks. Llm reasoning is done exclusively in the way of symbolic manipulation. Human reasoning is done not in symbols but in mental models that are hard to explain for today science but we have evidence they are somewhat efficient for producing correct programs, at least after sufficient training. Ron's post makes the case to explain that symbolic reasoning is not sufficient for producing correct programs. Hope this helps.

> Llm reasoning is done exclusively in the way of symbolic manipulation. No, LLMs are not a classical symbolic system applying explicit rules to symbols.

The article asserts general guarantees of program correctness have fundamental limits, but it explicitly says those limits apply to humans too. While that suggests neither humans nor LLMs can reliably solve every planning or verification problem, it says nothing about which will do better on the software problems people actually encounter.

It certainly does not present a fundamental problem with LLMs as they exist today.

Thank you for the assessment and the link. I only read half of it as I was busy. Bookmarking it for later reading. Great read.

Yes. The combinatorial explosion is a great assessment of the "why".

But the problem is more nuanced than that because one has to assume that LLMs can reason accurately all the time which is demonstrably false.

The current LLMs cannot even state true sentences as true if they sound confident, without hedging.

Future LLMs may mitigate this, though it looks unlikely.

Nobody cares about conviction. What can be demonstrated is what matters.

darkwi11ow, in the sibling comment, gave a substantive response on the underlying mechanics with a link. Godel's incompleteness theorems also yield similar insight. But I want to shine some light on a different phenomenon.

What happens in the future is up for debate, but the current architectural reasoning capabilities of LLMs are pathetic.

Try having a discussion on designing an architecture for a new kv engine with cache-oblivious algorithms that beats lmdb on generic random point-key lookups on a disk-backed mmap file.

Or try any novel architectural discussion and see for yourselves.

Modern LLMs cannot even confidently state many true sentences as "maximally" true as possible without hedging and tone policing as if we were doing politics ;).

Hence an expert is required at every turn.

Talking about current LLMs while trying to assert future impossibility, and not mentioning an actual architectural problem, is giving a hint of not seeing past your own nose tbh

Your reading skills are commendable, especially since you "found" an assertion of future impossibility. Me having explicitly mentioned the future as "up for debate" makes your reading comprehension even more impressive.

Unable to see the architectural problem mentioned is just icing on the cake.

How do you do this?

Here let me point you to the assertion you made:

>> Its not happening, at least not with LLMs

> Correct.

Wrong. The entire arc was on database and novel architectures. Let me point you to the things you missed both on the example and the context.

>> Writing such a complex software as database engine requires strategy, awareness and rigor.

> Correct. Current LLMs are pathetic at architectural correctness without expert supervision at every turn.

> Try having a discussion on designing an architecture for a new kv engine with cache-oblivious algorithms that beats lmdb on generic random point-key lookups on a disk-backed mmap file.

> What happens in the future is up for debate,

Yes, but I said 1 - 2 years, not current LLMs.

My comment was to your parent comment :).

I find it unlikely, especially due to the numerous pathetic suggestions LLMs keep offering me on the architectural discussions I engage in.

Verbal abuse is what makes it useful to me. A punching bag where it infuriates me making me lay down the how and why its suggestions are stupid. This results in progress.

I guess we would have to wait and see. Maybe LLMs do get better at architecture in the future. But seems unlikely to me without expert supervision.

Reducing attack surface is a lesson for everyone. Newcomers are impressed by massive piles of code.

Seasoned developers are unimpressed, or even disgusted, by the same massive piles of code.

i don't think LoC is the metric. sometimes fewer lines of code results in a larger attack surface through type coercion / widening, poor abstractions, hiding or stuffing behavior (modules that do everything), etc. to me, making code easy to understand, test, fuzz, and verify is more important. sometimes that requires more lines of code.

LoC *IS* the metric. It is obviously not perfect tho but still the best one to compare software surface. Including to compare the same solution in different languages and platforms. The less code you need to manage, the less code you need to change and the less code you need to hold in your head to understand it (or in the LLM context nowadays).

More abstract code probably results in more high-abstraction-level bugs per LoC, but also less low-abstraction-level bugs so I'd guess it about cancels out to an even rate per LoC.

A single line in C++, Rust or Haskell can have a really subtle logic error. A single line in assembly can't, but it has that same likelihood of having a register allocation error instead, and when you add up all the many lines of assembly you probably still wrote the same number of logic errors as the C++ version.

True. The guide is an interesting read. When you are deep in the trenches, most of what the github link says is just common sense.

Eg: < Optimize for the slowest resources first (network, disk, memory, CPU) in that order, after compensating for the frequency of usage, because faster resources may be used many times more. For example, a memory cache miss may be as expensive as a disk fsync, if it happens many times more.>

This is just obvious common sense. Great read.

mimalloc aggressively reclaims space and it benefits the use case in our Dip database built on rust.

This is for a long running process where consuming compute and memory should only occur on processing a request and must revert to a baseline memory consumption once the request is completed.

malloc with default allocator always gradually increases the memory consumption. This continues with enough request bursts on our testing until the process runs out of memory. mimalloc doesn't.

On mobile, we are stuck with the default allocator. On mobiles, the phenomenon of the default allocator consuming memory is reproducible even with normal Qt apps. It is what it is.

> This continues with enough request bursts on our testing until the process runs out of memory

Curious, how much memory and how many requests does that take to exhaust?

I first encountered this behaviour on Linux desktop with Qt QML apps as far back as 2015. For a long time, I thought it was Qt QML ListView's inefficiency and didn't think much of it.

But in recent years, the phenomenon was visible with Dip which was built on rust.

Dip does massive parallel fanout using green threads ('may' coroutines) with work being NUMA pinned (software hash) using a thread per core model.

A default request may span up to _chunk_count_ jobs (default 5k) configurable per request.

Every request (x 5k jobs) from the client on a stress test sees a jump of ~10-20 MB of memory. Sometimes the jumps use large swaths of memory - say 100s of MB and stabilizes for a while only to gradually climb up again later. Rinse and repeat - OOM kicks in and the process crashes.

Many times we thought we were leaking memory somewhere. But armed with the Qt experience a decade ago, we intuited maybe its the allocator - and switched to mimalloc on desktop executable.

Dip's memory, using mimalloc, stabilizes at ~60 MB post request completion no matter how many requests you throw at it.

Pity that on mobiles, more specifically Android, we have to live with the default allocator on even trivial Qt apps let alone embedded Dip. But people have lived with it for at least a decade, so it is what it is.

Thus on mobiles, we just have to be content like everybody else, unable to squeeze every last ounce of performance and efficiency out of the hardware on stress tests ensuring Dip remains "just better :(" :)

Interesting, thanks for elaborating.

What has that got to do with anything? Look into his work rather than his online persona.

It's his/her prerogative to keep an online footprint or not.

Peer review and scrutiny out in the public is more valuable than only done by a couple of paid guys from a journal.

It's fairly basic. For a work published on a public platform, the same guys paid by the journal can also review it if they so choose to in addition to those people in the public who were not paid by anyone.

It’s always funny to read general-public takes on academic peer review, because they almost always betray a complete misunderstanding of how peer review works. Academic reviewers for the vast majority of journals notoriously do not get paid; in fact, paying peer reviewers is one of the most frequently suggested approaches to peer review reform.

Most still get benefits. I concede that many don't get "direct" remuneration. Some journals do pay. But many do get vouchers, discounts, free access, early access, etc. which amounts to a form of payment and thus compensated in kind. This effectively is "paid" as far as I am concerned.

The logic stands. A reviewer, even those who get zero compensation, can always review publicly published papers just like others.

This looks great.

We have smart batching in Dip where we deduplicate work received in what we call a "batched" request. We use BTreeMap to deduplicate work in the preprocessing "scatter" phase.

This deduplication in smart batching is the slowest phase on most bulk write workloads (200k+ inserts in a single request) and takes sometimes up to 3x the time taken for the combined fanout + db writes + db commits + gather.

Will try out with Bbtree and see how it goes.

You are asking all the right questions. The answer is obvious.

Many don't want to say it or admit it.

That literally was history in the making. Much respect.