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.
-
It depends on how you use your threads I guess. That linear buffer was used for all the jobs and memory needed to be passed around between them. Jobs could also have their own local linear allocator. Long running threads would not use this memory.
In my experience, if you are trying to make sure your cores are working all the time, you want to get rid of as many sync points as possible. Sync points around something common like allocation are death, threads will logjam there very quickly.
-
-
But one may not notice this if one is not profiling threads with an eye to maximizing performance.
-
Passing memory between threads is annoying if the originating thread has to free it. But under this model, where nobody explicitly frees the memory (except the per-frame reset), there is no problem passing it between threads.
- Show replies
New conversation -
-
-
That is very true. And from profiling in our case we determined this was not an issue. We used an atomic allocator which allows for a much improved sync performance. And the number of allocations was somewhat small.
-
I never did anything on PS3 so I am not familiar with its memory characteristics. But I would say it is much worse to do this on a modern PC because cores can easily end up spending a lot of time fighting for ownership of that cache line.
- Show replies
New conversation -
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.