Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static Allocation with Zig

nickmonad.blog

Post reply on HN
Print view View original

91–100 of 112 posts

Re: Static Allocation with Zig

#91

Post by array_key_first »

leumassuehtam wrote: post #2

> All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. This avoids unpredictable behavior that can significantly affect performance, and avoids use-after-free. As a second-order effect, it is our experience that this also makes for more efficient, simpler designs that are more performant and easier to maintain and reason about, com…

I think it's more relevant than ever when most systems seem to dynamically allocate everything, some down to each individual object being its own runtime allocation, popularized by the likes of java.

On the surface it seems great: infinite scale and perfectly generic. The system can handle anything. But does it need to handle everything? And, what's the cost in terms of complexity of handling every single possible scenario?

Re: Static Allocation with Zig

#92

Post by array_key_first »

mikepurvis wrote: post #40
d3ckard wrote: post #28

Earlier quoted context omitted.

Personally, I see dynamic allocation more and more as a premature optimization and a historical wart. We used to have very little memory, so we developed many tricks to handle it. Now we have all the memory we need, but tricks remained. They are now more harmful than helpful. Interestingly, embedded programming has a reputation for stability and AFAIK game development is also more and more about avoiding dynamic allo…

Also not a game dev, but my understanding there is that there there's a lot of in-memory objects whose lifetimes are tied to specific game-time entities, like a frame, an NPC, the units of octtree/bsp corresponding to where the player is, etc. Under these conditions, you do need a fair bit of dynamism, but the deallocations can generally be in big batches rather than piecemeal, so it's a good fit for slab-type system…

I think most software is like this if you sit and reason about the domain model long enough. It's just easier to say "fuck it" and allocate each individual object on its own with a lifetime of ???.

Also, is easier to refactor if you do the typical GC allocation patterns. Because you have 1 million different lifetimes and nobody actually knows them, except the GC kind of, it doesn't matter if you dramatically move stuff around. That has pros and cons, I think. It makes it very unclear who is actually using what and why, but it does mean you can change code quickly.

Re: Static Allocation with Zig

#93

Post by array_key_first »

kibwen wrote: post #61
d3ckard wrote: post #45

Earlier quoted context omitted.

Yes, but allocations generate ever increasing combinatorial space of possible failure modes. Static allocation requires you to explicitly handle overflows, but also by centralizing them, you probably need not to have as many handlers. Technically, all of this can happen as well in language with allocations. It’s just that you can’t force the behavior.

Sure, but let's be clear: it's a tradeoff. If every program reserved as much memory at startup as needed to service 100% of its theoretically-anticipated usage, the amount of programs we could run in parallel would be drastically reduced. That is to say, static allocation makes OOM conditions dramatically more likely by their very nature, because programs are greedily sitting on unused memory that could be doled out…

You don't need to go balls to the wall and allocate 100% upfront. The typical split we see is either "allocate all the things" or "allocate every object, even if it's 16 bytes and lives for 100 microseconds".

Most programs have logical splits where you can allocate. A spreadsheet might allocate every page when it's created, or a browser every tab. Or a game every level. We can even go a level deeper if we want. Maybe we allocate every sheet in a spreadsheet, but in 128x128 cell chunks. Like Minecraft.

Re: Static Allocation with Zig

#94

Post by uecker »

kibwen wrote: post #89
pron wrote: post #79

Earlier quoted context omitted.

That what happens can be reasoned about in the semantics of the source language as opposed to being UB doesn't necessarily make the problem "a ton more benign". After all, a program written in Assembly has no UB and all of its behaviours can be reasoned about in the source language, but I'd hardly trust Assembly programs to be more secure than C programs [1]. What makes the difference isn't that it's UB but, as you p…

> In fact, take any C program with UB, compile it, and get a dangerous executable. Now disassemble the executable, and you get an equally dangerous program, yet it doesn't have any UB. I'd put it like this: Undefined behavior is a property of an abstract machine. When you write any high-level language with an optimizing compiler, you're writing code against that abstract machine. The goal of an optimizing compiler fo…

Since it has UB it is easy for the compiler to guarantee that the resulting code is semantics-preserving: Anything the code does is OK.

Re: Static Allocation with Zig

#95

Post by uecker »

kibwen wrote: post #75
AlotOfReading wrote: post #67

Earlier quoted context omitted.

The JPL C rules are quite old, but avoiding dynamic allocation outside initialization is am considered best practice for spaceflight software regardless of language. Here's the recommendation from NASA's language-agnostic cFS: 4.2.4 Consolidate Resource Allocations It is generally recommended to consolidate resource allocations to the application initialization function(s). Allocations and setup of resources such as…

> The JPL C rules are quite old, but avoiding dynamic allocation outside initialization is am considered best practice for spaceflight software regardless of language. The rules are written with the historical context of C making it too easy to leak heap-allocated memory. In the safety-critical Rust code that I've worked on, we tend not to dynamically allocate due to the usual constraints, and we're well aware of the…

This is scary, the issue in safe-critical code is not leaks (which Rust also does not necessarily prevent), but accidental resource exhaustion. This is also why JPL forbids recursion.

Re: Static Allocation with Zig

#96

Post by CashWasabi »

This also works well for games. I use a FixedBufferAllocator that allocates everything except assets upfront (systems, entities, etc.). Tigerstyle is a good starting point for efficient and debuggable software.Thanks for the article!

Re: Static Allocation with Zig

#97

Post by skybrian »

chongli wrote: post #73
skybrian wrote: post #24

Earlier quoted context omitted.

A Turing machine has an unlimited tape. You can’t emulate it with a fixed amount of memory. It’s mostly a theoretical issue, though, because all real computer systems have limits. It’s just that in languages that assume unlimited memory, the limits aren’t written down. It’s not “part of the language.”

What about IO? Just because I have a statically allocated program with a fixed amount of memory doesn’t mean I can’t do IO. My fixed memory can just be a cache / scratchpad and the unlimited tape can work via IO (disk, network, etc).

Yes, good point.

Re: Static Allocation with Zig

#98

Post by badsectoracula »

d3ckard wrote: post #28
mikepurvis wrote: post #22

Earlier quoted context omitted.

I'm not an academic, but all those ByteArray linked lists have me feeling like this is less "static allocation" and more "I re-implemented a site-specific allocator and all that that implies". Also it's giving me flashbacks to LwIP, which was a nightmare to debug when it would exhaust its preallocated buffer structures.

Personally, I see dynamic allocation more and more as a premature optimization and a historical wart. We used to have very little memory, so we developed many tricks to handle it. Now we have all the memory we need, but tricks remained. They are now more harmful than helpful. Interestingly, embedded programming has a reputation for stability and AFAIK game development is also more and more about avoiding dynamic allo…

> AFAIK game development is also more and more about avoiding dynamic allocation.

That might have been the case ~30 years ago on platforms like the Gameboy (PC games were already starting to use C++ and higher level frameworks) but certainly not today. Pretty much all modern game engines allocate and deallocate stuff all the time. UE5's core design with its UObject system relies on allocations pretty much everywhere (and even in cases where you do not have to use it, the existing APIs still force allocations anyway) and of course Unity using C# as a gameplay language means you get allocations all over the place too.

Re: Static Allocation with Zig

#99

Post by ulbu »

brabel wrote: post #35
mitchellh wrote: post #17

Earlier quoted context omitted.

Snide and condescending (or at best: dismissive) comments like this help no one and can at the extremes stereotype an entire group in a bad light. I think the more constructive reality is discussing why techniques that are common in some industries such as gaming or embedded systems have had difficulty being adopted more broadly, and celebrating that this idea which is good in many contexts is now spreading more broa…

> had difficulty being adopted more broadly Most applications don’t need to bother the user with things like how much memory they think will be needed upfront. They just allocate how much and when necessary. Most applications today are probably servers that change all the time. You would not know upfront how much memory you’d need as that would keep changing on every release! Static allocation may work in a few domai…

you don’t know up front how much memory you’ll need, but you know up front how much memory you have.

Re: Static Allocation with Zig

#100

Post by jibal »

astrobe_ wrote: post #48
mitchellh wrote: post #17

Earlier quoted context omitted.

Snide and condescending (or at best: dismissive) comments like this help no one and can at the extremes stereotype an entire group in a bad light. I think the more constructive reality is discussing why techniques that are common in some industries such as gaming or embedded systems have had difficulty being adopted more broadly, and celebrating that this idea which is good in many contexts is now spreading more broa…

Because garbage-collected languages are easier to teach and to use. So the low-level, low-resource or high-performance stuff is left to a handful of specialists - or "insects" according to Heinlein. Speaking of old things, this reminds me of one of Asimov's short stories, where someone who rediscovers mental calculus is believed to be a genius.

https://ia800806.us.archive.org/20/items/TheFeelingOfPower/T...

Not even calculus, just basic arithmetic operations.

Post reply on HN