6 ms·
That's true for GC vs. manual heap-based memory management, but most GC languages don't do stack allocation at all or only for primitive types and stack allocat
by btmorex 10y ago
That's true for GC vs. manual heap-based memory management, but most GC languages don't do stack allocation at all or only for primitive types and stack allocation is much, much faster than any sort of heap-based memory management.
- foota 10y agoThat's fair. Does Go do this? Or any other somewhat mainstream language? Any thoughts on how arenas (rust) compare to gc and manual allocation for speed?
- kasey_junk 10y agoC# & Go both have stack allocation options. The JVM is supposedly getting them sometime soon.
- CyberDildonics 10y agostack allocation: 20 years in the making.
- weberc2 10y agoI'm of the impression that Java has done escape analysis for a while now. They just haven't had value types, which as I understand, just introduce a semantic for stack allocation.
- pjmlp 10y agoActually I have seen presentations that mentioned Graal is much better at it than Hotspot.
- yxhuvud 10y agoMalloc is O(n²) so it totally depend on how able you are to not do gradual allocation.
- pjmlp 10y agoCheck my other comment https://news.ycombinator.com/item?id=12823102 https://news.ycombinator.com/item?id=12823102
- buzzybee 10y agoArenas trade some granularity and flexibility for speed and fragmentation-free allocation; they're a great choice for bulk data that you can precompute the size of and want to iterate over very quickly, and they're also easy to reason about. You can do many tasks using only arenas and stack allocations, and it'll zip along very quickly. If needed, you can flag liveness to get very efficient reuse of short-lived objects. They're less ideal if you are gradually adding more data over time, and you want to retain a consistently low usage, since you end up with "stairsteps" of latency when it copies into a bigger buffer, and once you have the big buffer, it's quite complicated to shrink it down again. malloc()-style allocation gives you precision over how much you want, and this is most interesting to a memory-constrained system trying to allocate amongst many different processes(the original Unix use-case). But willy-nilly use of malloc() and free() leaves you with lots of fragmentation, as well as a larger attack surface for memory errors. What the actual allocation algorithm does is out of your hands, too, at least if you're depending on the OS allocator(you can always go write your own and supply it with a giant heap to munch on, and this may occur when you need tuning for individual allocation scenarios). In the right scenario, a GC won't do too much differently from a manual allocator(there are lots of optimizations that could bring the allocation to same-or-negligible runtime), but as we all know, right scenarios are something you can't always count on. A GC does, however, greatly simplify the memory management of a long-lived process since it can do nifty things like automatically compact the heap. IME, a mix of stack, GC, and some arenas in the form of growable arrays, is absolutely fine for the needs of most applications. Quite often this last requirement creates a sticking point, though, where the language disallows value semantics for arrays of objects, and then you can no longer assume they're allocated linearly, plus the GC is taxed with additional references to trace. In those cases, if I have them I use arrays of primitive values as crude containers for an equivalent optimization. Either way, it's very annoying and creates some awful code, because those huge batches that I'd like to put in arenas also tend to be the bottleneck for the GC.
- kasey_junk 10y ago> stack allocation is much, much faster than any sort of heap-based memory management. Is that true? I thought nursery allocation was usually as fast if not faster than stack allocations.
- johncolanduoni 10y agoThe allocation speed will be close; a bit worse since the pointer to the end of the current allocation buffer usually isn't in a register and a function call and range check is required. However the overall cost of handling that memory from start to finish is significantly higher than the stack even if it gets clobbered in the first nursery collection. Not because it is very high, but because stack allocation/deallocation is so very simple.
- klodolph 10y agoRange checks can be done by the MMU, they're basically free.
- deleted 10y ago[deleted]
- pjmlp 10y agoAll these GC languages (RC is GC, just in case) do allow stack allocations for any user defined type. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, D, Swift
- CyberDildonics 10y agoThe unfortunate part is finding good IDEs with solid debuggers and auto-completion.
- pjmlp 10y agoYes, but that is not relevant for those that live on VI and Emacs.
- weberc2 10y agoGo has excellent auto-completion support, even for vim. It's debugger (delve) is also decent, though not graphical. There are not many languages with better tooling than Go, in my experience.
- NateDad 10y agoFYI, delve is integrated into a lot of editors, and basically works exactly like visual studio when used in VS Code (I used visual studio for C++ & C# for 13 years before moving to Go).
- Dylan16807 10y agoListing largely-obscure languages and repeating them multiple times doesn't do much against a claim of "most".
- weberc2 10y agoJava, Go, and C# all do stack allocation either implicitly via escape analysis (Java), explicitly via value types (C#), or both (Go). I don't know that this is "most" (perhaps by marketshare), but these are certainly 3 of the most popular languages in this space.
- sz4kerto 10y agoIn Java, heap allocation is a single instruction, most of the time.
- PDoyle 10y ago"stack allocation is much, much faster than any sort of heap-based memory management" No, it's not. For short-lived objects, at least on the JVM, allocation is a pointer bump, and collection is free, because unreachable objects are not even walked. Stack allocation doesn't beat that by much.