4 ms·

That's a a compelling argument: GC/RC w/ stack allocation where possible. I associate GC w/ pointer chasing and the unavoidable L1, L2, L3 cache trashing that g

by ibiza 4y ago

That's a a compelling argument: GC/RC w/ stack allocation where possible. I associate GC w/ pointer chasing and the unavoidable L1, L2, L3 cache trashing that goes w/ it. To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? I'm guessing no, and instead it's local & one-off, rather than something one can bank on.

netbioserror 4y ago
https://zevv.nl/nim-memory/ https://zevv.nl/nim-memory/ Local variables (also called automatic variables) are the default method by which Nim stores your variables and data. Nim will reserve space for your variable on the stack, and it will stay there as long as it is in scope. In practice, this means that the variable will exist as long as the function in which it is declared does not return. As soon as the function returns the stack unwinds and the variables are gone. In Nim, all your data is stored on the stack, unless you explicitly request it to go on the heap. Strings and seqs are allocated on the heap and accessed via a stack pointer, but the stack pointer controls their lifetimes, and semantically behaves like any other local variable.
- j-james 4y ago
  Do note that this was written before Nim's new runtime, ARC/ORC, became stable! The author has been working on a companion guide to the new runtime that goes over how it manages to be efficient with reference counting, but it's (very) much a work in progress.
arc619 4y ago
> That's a a compelling argument: GC/RC w/ stack allocation where possible. Indeed, it's a great combination that means you're productive and performant without really trying most of the time. The type system is really good as well, and in general there's a strong focus on compile time over run time like Zig, but with better procedural macros than Rust. > To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? The GC is built on general move analysis with destructors you can hook for your own types. The nice thing is it's a deterministic, compile time expansion (you can view with '--expandArc:somefunction'), so it's useful for embedded or high performance stuff. The intro to ARC is pretty good for an overview: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

by ibiza 4y ago

netbioserror 4y ago

https://zevv.nl/nim-memory/ https://zevv.nl/nim-memory/ Local variables (also called automatic variables) are the default method by which Nim stores your variables and data. Nim will reserve space for your variable on the stack, and it will stay there as long as it is in scope. In practice, this means that the variable will exist as long as the function in which it is declared does not return. As soon as the function returns the stack unwinds and the variables are gone. In Nim, all your data is stored on the stack, unless you explicitly request it to go on the heap. Strings and seqs are allocated on the heap and accessed via a stack pointer, but the stack pointer controls their lifetimes, and semantically behaves like any other local variable.

j-james 4y ago
Do note that this was written before Nim's new runtime, ARC/ORC, became stable! The author has been working on a companion guide to the new runtime that goes over how it manages to be efficient with reference counting, but it's (very) much a work in progress.

arc619 4y ago

> That's a a compelling argument: GC/RC w/ stack allocation where possible. Indeed, it's a great combination that means you're productive and performant without really trying most of the time. The type system is really good as well, and in general there's a strong focus on compile time over run time like Zig, but with better procedural macros than Rust. > To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? The GC is built on general move analysis with destructors you can hook for your own types. The nice thing is it's a deterministic, compile time expansion (you can view with '--expandArc:somefunction'), so it's useful for embedded or high performance stuff. The intro to ARC is pretty good for an overview: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...