[0]: https://web.archive.org/web/20120113030236/http://groups.csa...
Memory model
– Garbage collection should be the only option
but he also says:
By 2009, game developers will face...
CPU’s with:
–20+ cores
The presentation isn't explicitly dated, but since the sample game is Gears of War, which came out in 2006, later on he says "by 2009" as if it was not-yet 2009, and the file name is "sweeney06games.pdf", gonna say this is almost certainly a presentation given in 2006. At the time this was given, the iPhone hadn't even come out yet.
It's an interesting presentation. I wonder what Sweeney would say today about this presentation, about how much of it still rings true, and about which things he would second-guess nowadays.
You seem to forget the GPU, how may cores does that have? (but really the question is: isn't parallelism the default mode when working with GPUs.
They just see C++ and don't look into the details.
Besides that, given that most engines now have a scripting layer, even if deep down on the engine GC is forbidden, the layer above it, used by the game designers, will make use of it.
It is like fostering about C and C++ performance, while forgetting that 30 years ago, they weren't welcomed on game consoles, and on the 8/16 bit home micros for games.
My phone is more powerful than any Lisp Machine or Xerox PARC workstation, it can spare some GC cycles.
Speak for yourself; most phones I see still take 2+ seconds to open some apps.
As far as desktop goes, even fewer cycles can apparently be spared - IntelliJ frequently freezes for 5s just after startup, most applications have insane startup times considering the power they have.
So, no, I don't want to add yet another slowdown because "our machines are 1000x faster than high-end digital workstations from 30 years ago", because it seems to me that all off the increases in hardware power have already been used up, and more.
The problem isn't the hardware or the language, rather how many stuff gets programmed in an age where plenty of people run for Electron apps and don't care about algorithms and data structures.
My first applications had 64KB and 3.5 MHZ at their disposal to make their users happy.
Why is that though? I've written code since the 8 bit days of BBC micros and ZX Spectrums.
Casey Muratori's (who has been on here a lot lately) talk nails it [1] - developers just don't realise how fast their code could and should run. And the fact that we have layers upon layers of frameworks and no one cares.
1. Completely deterministic, so no worrying about pauses or endlessly tweaking GC settings.
2. Manual ref counting is a pain, but again ARC basically makes all that tedious and error prone bookkeeping go away. As a developer I felt like I had to think about memory management in Obj C about as much as I did for garbage collected languages, namely very little.
3. True, you need to worry about stuff like ref cycles, but in my experience I had to worry about potential memory leaks in Obj C about the same as I did in Java. I.e. I've seen Java programs crash with OOMs because weak references weren't used when they were needed, and I've seen similar in Obj C.
> has bad cache behavior for multithreading
Why is this? Doesn't seem like that would be something inherent to ref counting.
> Also, not deterministic
I always thought that with ref counting, when you decrement a ref count that goes to 0 that it will then essentially call free on the object. Is this not the case?
Determinism: the time taken is not deterministic because (1) malloc/free, which ARC uses but other GCs usually not, are no deterministic - both can do arbitrary amounts of work like coalescing or defragmenting allocation arenas, or performing system calls that reconfigure process virtual memory - and (2) cascading deallocations as rc 0 objects trigger rc decrements and deallocation of other objects.
> not deterministic perf wise.
was what parent wrote (emphasis added), I assume referring to the problem that when an object is destroyed, an arbitrarily large number of other objects -- a subset of the first object's members, recursively -- may need to be destroyed as a consequence.
determinism: you reset a pointer variable. Once in a while, you're the last referent and now have to free the object. That takes more instructions and cache invalidation.
Thank you! This was the response that made the cache issues clearest to me.
Once I know I can read the data, it usually doesn't matter that another thread is also reading it. Reference counting changes that because we both need to write to the count every time either of us takes or drops a reference to the data, and in the latter case we need to know what's happened on the other core, too. This means a lot more moving of changing data between processor cores.
> > Also, not deterministic
> I always thought that with ref counting, when you decrement a ref count that goes to 0 that it will then essentially call free on the object. Is this not the case?
That's my understanding, but is that "deterministic" as we mean it here? It's true that the same program state leads to the same behavior, but it's non-local program state, and it leads to you doing that work - potentially a lot of work, if you (eg) wind up freeing all of a huge graph structure - at relatively predictable places in your code.
There are good workarounds (free lists, etc) but "blindly throw language level reference counting at everything" isn't a silver bullet (or maybe even a good idea) for getting low-latency from your memory management.
It is inherently so. A reference count is an atomic mutable value that must be updatable by any thread.
A significant selling point of ARC compared to traditional ObjC reference counting was that the compiler could elide retain/release calls better than the programmer could, thus preventing a ton of stalls.
1. Automatic reference counting adds a barrier every time you pass around an object, even if only for reading, unlike both manual memory management and tracing GC.
2. ARC still requires thought about ownership, since you have to ensure there are no cycles in the ownership graph unlike tracing/copying/compacting GC.
3. ARC still means that you can't look at a piece of code and tell how much work it will do, since you never know if a particular piece of code is holding the last reference to a piece of data, and must free the entire object graph, unlike manual memory management. In the presence of concurrency, cleanup is actually non-deterministic, as 'last one to drop its reference' is a race.
4. ARC doesn't solve the problem of memory fragmentation, unlike arena allocators and compacting/copying GC.
5. ARC requires expensive allocations, it can't use cheap bump-pointer allocation like copying/compacting GC can. This is related to the previous point.
6. ARC cleanup still takes time proportional to the number of unreachable objects, unlike tracing GC (proportional to number of live objects) or arena allocation (constant time).
Reference counting is a valid strategy in certain pieces of manually memory managed code (particularly in single-threaded contexts), but using it universally is almost always much worse than tracing/copying/compacting GC.
Note that there are (soft) realtime tracing GCs, but this can't be achieved with ARC.
1. I'm guessing you mean lock based implementations? There's several non lock, non atomics based ARC designs that still handle threading safely. That means it's little more than a single integer operation.
2. True, but for many contexts this is easy to do and makes it easier to understand data flows. In other cases it's possible to use index based references pretty readily, like in Rust. Or add a cycle collector.
3. In theory you can't, but in practice it's often pretty easy to tell. At least in non-oop languages. I use Nim with its ARC (1) on RTOS and this is really only a concern for large lists or large dynamic structures. It can be managed using the same patterns as RAII where you call child functions who know they won't be the last ones holding the bag. Also you can use the same trick as some Rust code does where you pass the memory to another thread to dispose of (2).
4/5. It depends on the implementation, but you can use pools or arenas or other options. Nim provides an allocator algorithm (tlsf) with proven O(1) times and known fragmentation properties (3). Still tracing gcs can make better usage of short lifetime arenas true. Though with ARC you get similar benefits using stack based objects.
6. It's tradeoffs. Tracing gcs also end up needing to scan the entire heap every so often. ARC's only need to check a root object during usage and only access the entire graph when de-allocating.
Your last point isn't accurate, as you can use an appropriately designed ARC in a hard realtime context. I've found it quite easy to do, but granted it takes a little bit of care, but any real time systems do. For items like interrupt handlers I ensure no memory is allocated or destroyed.
1) https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... 2) https://abramov.io/rust-dropping-things-in-another-thread 3) http://www.gii.upv.es/tlsf/
Don't think that's even doable at all, at least not portably. Do you have some examples?
- Nim's ARC only allows one thread to manage a reference count at a time, but enables an isolated graph of memory to be moved to another thread. The concept is called `Isolate`, and is very similar to Rust's single owner of mutable references. There's still WIP to have the compiler automate the checks, but it's usable now (I used it with FreeRTOS's xQueue mechanism just fine). https://github.com/nim-lang/RFCs/issues/244
- Python's new non-GIL proposal that does this using biased references: https://hackaday.com/2021/11/03/python-ditches-the-gils-and-...
- The source of Python's biased references: https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf
- Defered Reference counting: https://dl.acm.org/doi/pdf/10.1145/3453483.3454060
It's pretty cool stuff!
Just one nitpick though:
> 6. It's tradeoffs. Tracing gcs also end up needing to scan the entire heap every so often.
This is not accurate: tracing GCs always start from the roots and only ever visit live objects. By definition, the objects that they free are not reachable from anywhere. "Full scans" typically refer to various optimization strategies that tracing GCs implement to avoid scanning all roots (e.g. generations, per-thread scans) which do rely on still occasionally doing a full scan (scanning all live objects in all generations, or in all threads).
https://floooh.github.io/2016/01/14/metal-arc.html
There are ways around this overhead at least in Metal, but this requires at least as much effort as not using ARC to begin with.
https://news.ycombinator.com/item?id=25203924
> this requires at least as much effort as not using ARC to begin with.
Designing a brand new CPU architecture certainly counts as "at least as much effort", yes. ^_^
P.S. While I'm here, your "handles are the better pointers" blog post is one of my all-time favorites. I appreciate you sharing your experiences!
It mostly means "I can know (as in "determine") how much time, or instructions, or calls, or memory an operation will take".
And this knowledge can come in degrees (be more or less fuzzy).
The only significant cost tracing has these days is in memory footprint.
And that's not insignificant. The top-of-the-line Pixel 6 Pro has twice as much RAM as the top-of-the-line iPhone 13 Pro. Maybe the Android camp is just more eager to play the specs game, but I've long speculated that iOS simply needs less RAM because of its refusal to use tracing GC.
I used all my models until their hardware died.
"Determministic" is a double edged sword. You get deterministic allocation and release times, but they might be bigger than what really is achievable.
https://github.com/ixy-languages/ixy-languages
When doing all the required optimizations, it turns into tracing GC optimizations with another more political accepted name.
There are no GC implementations that have no pauses. You couldn't make one without having prohibitively punitive barriers on at least one of reads and writes.
There are no operating systems that have no pauses; if you don't want to share the CPU, you're going to have to take responsibility for the whole thing yourself. Most people are not even using RTOS.
There are no reference counting implementations that have no pauses. Good luck crawling that object graph. Most people are not even using deferred forms of reference counting.
As far as I know, there is one malloc implementation which runs in constant time. No one uses it.
There are tracing GCs whose pause times are bounded to 1ms. That is enough for soft-real-time video and audio (which is what matters to video games). In general, you are not going to get a completely predictable environment unless you pick up an in-order CPU with no cache and write all your code in assembly.
(I suspect this is obvious to a lot of programmers, but especially in working with Java programmers who just skim JVM release notes and then repeat "pauseless", it's also not obvious to many too.)
As a game dev I still will take a modern GC over refcounting or manual lifetime management any day. There are scenarios where you simply don't want to put up with the GC's interference, but those are rare - and modern stacks like .NET let you do manual memory management in cases where you are confident it's what you want to do. For the vast majority of the code I write, GC is the right approach - the best-case performance is good and the worst-case scenario is bad performance instead of crashes. The tooling is out there for me to do allocation and lifetime profiling and that's usually sufficient to find all the hotspots causing GC pressure and optimize them out without having to write any unsafe code.
The cost of having a GC walk a huge heap is a pain, though. I have had to go out of my way to ensure that large buffers don't have GC references in them so that the GC isn't stuck scanning hundreds of megabytes worth of static data. Similar to what I said above though, the same problem would occur if those datastructures had a smart pointer in them :/
Of course not! Nothing can. But—two things:
1. Per Knuth on premature optimization, 97% of your code should not care about such things. For those parts of your code that do need to effect their own allocation strategies, they can generally do so as well in a GCed language as another. Tracing GC forces minimal cognitive overhead on the remaining 97%, and allows it to interoperate smoothly with the 3%.
2. Tracing GC has better performance characteristics than other automatic memory management policies, in a few important respects. Compacting adds locality; bumping gives very fast allocation; copying gives very fast deallocation of deep graphs in the nursery.
Like I said - "of course" to me, and apparently you, and probably anyone who has worked with multiple GCs and unmanaged languages over many years - but that's not most programmers. The vast majority of Java developers I interview, up to those with 5-6y experience, have no clue how their idioms affect allocations.
> Per Knuth on premature optimization, 97% of your code should not care about such things.
No, this is the classic misstatement of Knuth. 97% of the time, I shouldn't worry about such things. But 100% of my program still might be affected by a design needed to reduce GC pressure, if that means switching core data structures to pools or SoA or something.
The problem with GC or with reference counting is that it needs to operate on each allocated object separately. If the task for the GC can be reduced to operate on whole memory areas only, its overhead is greatly reduced.
Try-with-resources is ok, but not great.
Ultimately developers, especially those concerned with performance, prefer full control. And that means deterministic lifetime of memory and resources.
It seems like he was off by a matter of a few months at most.
I have a quad AMD Opteron(tm) Processor 6172 (Mar 2010) 2U server with 48 hardware cores. This motherboard can also take the 16 core CPU's which were also introduced the following year, which would put it at 64 cores and 128 threads.
The Opteron 6 core CPU's were introduced in June 2009, so a quad server would be 24 cores, or 48 threads.
Of course, that's not cores in a single CPU, if that's what even what the prediction was referring to, but that probably wouldn't matter very much from a gaming dev perspective anyway. It was probably a pretty good guess, all things considered.
That‘s not usually what people game on, though. Even today, 20 core CPUs are the exception for gaming rigs.
But i think the trend is clear - more cores is the future as clock speed has slowed down.
~0.31% according to the Steam hardware survey [1] If you are including 8-core machines with simultaneous multithreading (so 16 logical cores, 8 physical), then you would be at ~17%, however.
And of course none of these happened. GPU and CPU did not converged, they both scale far ahead than anyone could imagined.
I mean, if you ask developers in 2006, no one would thought of doing 4K rendering with HDR / 120fps and still not doing Ray Tracing.