With 64 bit address spaces, thread stacks should have GBs reserved by default, and programming with alloca should be encouraged. A lot of string and container work could be done at high performance with alloca and no frees if you don't let them escape.
-
Having a per-thread temporary allocator that is a standard convention, so that everyone including libraries can use it, is better... you can return temporary strings / arrays / nodes from functions, etc. (I do this all the time in the language I am working on).
You just pretend like you have a GC for all these things, and it just gets completely reset once per frame at a known point.
-
-
We had this on one of the engines I worked on, a per frame linear buffer that would reset at a known time. It was shared among threads though, and it would be double buffered so GPU could access it on a different frame as well.
-
The problem with sharing across threads is that now it's a contended resource. Also the threads have to sync to reset it, but, if that is part of your design already then it is fine.
- Show replies
New conversation -
-
-
Basically a bump allocator?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
So like objective c autorelease pool?
-
No, because it does not have the same imposition of structure, not performance impact.
End of conversation
New conversation -
-
-
This is actually quite like NeXT’s auto release pools in concept (yes, I know those use ref counting). IMO it works really well in practice.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I am doing exactly that in my framework. Lazily initialized per-thread arena style temporary allocator. But I decided to avoid forcing the per-frame reset. It does not cost much to do it manually and is more explicit and flexible for unforeseen use-cases.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.