Why can’t the LLMs avoid the memory issues entirely?

"why?" is an interesting question. My best attempt at an explanation is that they have a poor sense of layout, especially in more than one dimension. That hidden time axis makes 1D problems like concurrency or memory fundamentally 2D+, and the results are then piss-poor unless I do a lot of the heavy lifting in the design. For that matter, they still frequently F it up and tell me it's perfect even with otherwise solid agentic patterns which can one-shot all kinds of other tasks, violating the spec I wrote to protect the agent from itself.

I don't have any justification for that explanation other than anecdotes. I will say that LLMs are typically quite bad at avoiding those memory issues, whatever the reason might wind up being.

▲

dnautics 2 days ago | parent [-]

I had the llms write an incredibly complex CV pipeline in zig through several iterations a and failed ideas and the only time it segfaulted was when I accidentally compiled it with avx intructions and deployed on a non-AVX machine

▲

hansvm 2 days ago | parent [-]

What made memory management challenging in that application?

▲

dnautics a day ago | parent [-]

It's running as a shared library under the BEAM so it better not leak or the OOM killer will come after me.

	▲	hansvm a day ago \| parent [-]
		But what made "better not leak" challenging? I ask because it looked like you were positioning "incredibly complex CV pipeline in Zig" as a counterpoint to my claim that LLMs are bad at memory management. I still think they're bad at it, but I'm interested in evidence to the contrary, so I'd love to know why your application rises to the level of something I should expect an LLM to struggle with. I've seen (have in prod right now actually) relatively simple ideas not much more complicated than resetting an arena each request, which would paper over a lot of memory-management sins even with quite bad models. I'm curious if that's why the LLM did well or if there's something else going on.

▲

gf000 2 days ago | parent | prev | next [-]

In the general case, there can be cases where it's simply straight up undecidable. (Think of a while loop going for as long as it finds a counterexample to insert your unsolved math problem of your choice) and call a free after. Sure, it's a very contrived example but similar "basically impenetrable barriers" do happen.

But the more common case is simply that each line of code gets some limited "thinking", whether it's inside the model's weights, a thinking block, or a whole turn. Only repeated turns can reason for arbitrary depths, so it's just not necessarily a good use of any of these buckets to spend on something we have a good and efficient algorithm for. Plus any of the former are stochastic which may accidentally ignore true issues (just like humans).

▲

14113 2 days ago | parent | prev [-]

Because LLMs are statistical. They can, with a given probability, avoid memory issues, but cannot prove the non-existance of memory issues in the way that that borrow checkers and other formal methods can.