5 ms·

Great "old-school" article! Intrigued to try Odin sometime. > One interesting thing: in Odin, similarly to Zig, allocators are passed to functions wishing to a

Great "old-school" article! Intrigued to try Odin sometime. > One interesting thing: in Odin, similarly to Zig, allocators are passed to functions wishing to allocate memory. Contrary to Zig though, Odin has a mechanism to make that less tedious (and more implicit as a result) by essentially passing the allocator as the last function argument which is optional.

wredue 2y ago
One of zigs core tenets is “no hidden allocations”. You’ll never see zig language supporting a default value for allocator parameters to support hiding it at first glance. Zig does have support for empowering library users to push coded settings in to libraries, and you could conceivably use this for writing this type of code. Although it’s probably not worthwhile. Or you can just straight up default your library to using a specific allocator, fuck the calling code. Anyway. Zig has patterns to do stuff like this, but it’s probably unwieldy in large projects and you’re better off just making it a parameter. You can also look in to the std ArrayList, which provides managed and unmanaged variants for yet another way that you might write code that empowers users to set an allocator once, or set it every time.
- deleted 2y ago
  [deleted]
bsder 2y ago
The problem with "implicit allocation" is always multithreading. An allocation library cannot serve two masters. Maximizing single thread performance is anathema to multithreaded performance. I'd go further. If allocators don't matter, why are you using a systems programming language in the first place?
- kragen 2y ago
  it sounds like implicitly passing the allocator as an extra parameter in every call would solve the problems you identify. if it's passed in a call-preserved register, it doesn't even make that implicit passing slower, because it requires zero instructions to not change the register before calling a subroutine (when i've done similar things, it's been to pass an arena for inlined pointer-bumping allocation, a strategy widely used by runtimes that want to make allocation fast. normally this requires two registers, though chicken gets by with just one)
  - bsder 2y ago
    Sure, it does, sorta. However, again, if you don't care about your allocators, why are you using a systems programming language? If you're willing to give up control over allocation, you are way, way better off in a managed memory (garbage collected or reference counted) language. Systems programming is pain for gain. You give up a lot of convenience in order to have strict control over things--control of latency, control of memory, control of threading, etc. The price for that control is programming with a lot fewer abstractions and far less help from the language/compiler/interpreter to keep you from shooting yourself in the foot. If you aren't using that "control" then you're just making life painful for yourself for no good reason. Obviously, people can use whatever language they perfectly well want for whatever reason they want. Given how much I talk about and use C, Rust and Zig, people are always surprised that if they ask if they should use any of the systems languages (C/C++/Rust/Zig/etc.) my first response is always "Oh, hell, no."
    - kragen 2y ago
      passing an allocator as an implicit parameter doesn't give up any control over allocation; with that mechanism you can still pass a different allocator when you want (and i assume odin allows that, though i haven't tried it) but i disagree pretty comprehensively with your comment. i don't agree that systems programming is pain, i don't agree with your definition of systems programming as programming with tight low-level control, i don't agree that tight low-level control is pain, i don't agree that abstraction is a necessary or useful thing to give up either for systems programming or to get tight low-level control (though it certainly is expedient), i don't agree that garbage collection (including reference counting) is the only way to simplify memory management, and i don't agree that either systems programming or tight low-level control requires accident-prone languages (and i'm especially surprised to see that assertion coming from an apparent rustacean) that is, i recognize that these tradeoffs are possible. i just disagree that they're necessary
      - nottorp 2y ago
        Not to mention we're talking about programming games here and you generally preload your assets and don't mess with them dynamically or your performance tanks. It's not only systems programming.

wredue 2y ago

One of zigs core tenets is “no hidden allocations”. You’ll never see zig language supporting a default value for allocator parameters to support hiding it at first glance. Zig does have support for empowering library users to push coded settings in to libraries, and you could conceivably use this for writing this type of code. Although it’s probably not worthwhile. Or you can just straight up default your library to using a specific allocator, fuck the calling code. Anyway. Zig has patterns to do stuff like this, but it’s probably unwieldy in large projects and you’re better off just making it a parameter. You can also look in to the std ArrayList, which provides managed and unmanaged variants for yet another way that you might write code that empowers users to set an allocator once, or set it every time.

deleted 2y ago
[deleted]

bsder 2y ago

The problem with "implicit allocation" is always multithreading. An allocation library cannot serve two masters. Maximizing single thread performance is anathema to multithreaded performance. I'd go further. If allocators don't matter, why are you using a systems programming language in the first place?

kragen 2y ago
it sounds like implicitly passing the allocator as an extra parameter in every call would solve the problems you identify. if it's passed in a call-preserved register, it doesn't even make that implicit passing slower, because it requires zero instructions to not change the register before calling a subroutine (when i've done similar things, it's been to pass an arena for inlined pointer-bumping allocation, a strategy widely used by runtimes that want to make allocation fast. normally this requires two registers, though chicken gets by with just one)
- bsder 2y ago
  Sure, it does, sorta. However, again, if you don't care about your allocators, why are you using a systems programming language? If you're willing to give up control over allocation, you are way, way better off in a managed memory (garbage collected or reference counted) language. Systems programming is pain for gain. You give up a lot of convenience in order to have strict control over things--control of latency, control of memory, control of threading, etc. The price for that control is programming with a lot fewer abstractions and far less help from the language/compiler/interpreter to keep you from shooting yourself in the foot. If you aren't using that "control" then you're just making life painful for yourself for no good reason. Obviously, people can use whatever language they perfectly well want for whatever reason they want. Given how much I talk about and use C, Rust and Zig, people are always surprised that if they ask if they should use any of the systems languages (C/C++/Rust/Zig/etc.) my first response is always "Oh, hell, no."
  - kragen 2y ago
    passing an allocator as an implicit parameter doesn't give up any control over allocation; with that mechanism you can still pass a different allocator when you want (and i assume odin allows that, though i haven't tried it) but i disagree pretty comprehensively with your comment. i don't agree that systems programming is pain, i don't agree with your definition of systems programming as programming with tight low-level control, i don't agree that tight low-level control is pain, i don't agree that abstraction is a necessary or useful thing to give up either for systems programming or to get tight low-level control (though it certainly is expedient), i don't agree that garbage collection (including reference counting) is the only way to simplify memory management, and i don't agree that either systems programming or tight low-level control requires accident-prone languages (and i'm especially surprised to see that assertion coming from an apparent rustacean) that is, i recognize that these tradeoffs are possible. i just disagree that they're necessary
    - nottorp 2y ago
      Not to mention we're talking about programming games here and you generally preload your assets and don't mess with them dynamically or your performance tanks. It's not only systems programming.