3 ms·
Yes, but in this case we know when the allocations will occur, and when they will be freed. If using a GC we know when they will occur, but do not know when the
by daemin 10y ago
Yes, but in this case we know when the allocations will occur, and when they will be freed. If using a GC we know when they will occur, but do not know when they will be freed. Which means that at some indeterminate point in the future there will be a large temporary slowdown due to processing the GC.
This is one of the bigger reasons people use C++ and even techniques within it to explicitly collect such items at a known point in time. (Techniques such as marking items as dead in an array but still keeping them in there until the end of frame, etc)
- branchless 10y agoThis is the advantage of C++ for me. Deterministic behaviour.
- chrisseaton 10y agoBut is it deterministic? Will the allocator always have a deterministic amount of work to do to find enough free space for your string characters? I'm not sure that's the case.
- monocasa 10y agoWhich allocator? For those who care, they replace the allocator.
- deleted 10y ago[deleted]
- junke 10y agoYou can deactivate GC momentarily and reclaim memory when you want (end of frame, every ten frames, ...). Most of the time you can manage to write your code to minimize allocation, or make sure memory is allocated on the stack. Depending on your parameters and a little bit of profiling, you can manage to have a stable usage of memory over time and a bounded GC time.
- titzer 10y ago> If using a GC we know when they will occur, but do not know when they will be freed. Which means that at some indeterminate point in the future there will be a large temporary slowdown due to processing the GC. This just isn't true anymore. Incremental collectors can achieve pause times in the single-digit millisecond range, and concurrent collectors can achieve pause times in the single-digit to tens of microseconds range, even for super-high-allocation rate programs. There are even real-time collectors suitable for audio and other hard real-time applications. Azul GC (a high performance concurrent compacting collector): https://www.azul.com/products/zing/pgc/ https://www.azul.com/products/zing/pgc/ Metronome (a real-time GC with guaranteed maximum pause times): http://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 http://researcher.watson.ibm.com/researcher/view_group_subpa... GC scheduling in V8 (hides GC pause times between frames, reducing animation jank): http://queue.acm.org/detail.cfm?id=2977741 http://queue.acm.org/detail.cfm?id=2977741 The Go GC ships now with a very low-latency GC: https://blog.golang.org/go15gc https://blog.golang.org/go15gc
- paulsutter 10y ago> This just isn't true anymore. Incremental collectors can achieve pause times in the single-digit millisecond range Single digit milliseconds is millions of instructions, which /is/ a large slowdown in some applications.
- titzer 10y agoHow much do you think a page fault costs?
- paulsutter 10y agoPage faults cost zero. On locked pages.
- titzer 10y agoAgain downvotes. It'd be nice if people actually replied instead of downvoting.
- 10y ago