3 ms·
Yeah, but Unity is very Indie oriented, no? I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal. Unreal
by Ygg2 12y ago
Yeah, but Unity is very Indie oriented, no?
I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal.
Unreal is defacto industry standard.
iOS, has ARC IIRC, not sure it has true GC like Java or C#. ARC is a super primitive GC.
- eridius 12y agoARC is not GC. It's automated reference counting. It's not a "super primitive GC" because it's a completely different approach to memory management. Notably, it has predictable behavior/performance characteristics, is suitable for realtime work (inasmuch any object-oriented approach with allocation/deallocation is; basically, it doesn't pause like GC does), and is fast. The downside is it is vulnerable to reference cycles.
- fulafel 12y agoThe question was about precise control over memory allocations. Arc hides it like other forms of GC. You can tread carefully to avoid pauses with GC, but it is more fragile than explicitly manual mem management. Ref counting does pause, you get cascading deallocations. More deterministic than other GC though.
- eridius 12y agoNeither ARC nor GC hide memory allocations. They automate the process of deallocating memory. And ARC does not hide that either. Values get released when they go out of scope, and they get deallocated when the last reference disappears. It's a very explicit process, the only "hiding" is the fact that there is no `[foo release]` line anymore. But it's no more hidden than C++ destructors are. > Ref counting does pause, you get cascading deallocations. That's not pausing. That's it doing work, upon request (i.e. when the object is released). If you have a single object that roots a massive object graph, and you release that single object, yes, it will have to destruct that entire object graph. But that's not the fault of ARC in the slightest, and would happen just the same with manual memory management. > More deterministic than other GC though. It's not GC, so what do you mean by "other GC"? --- ARC has the exact same performance characteristics as manual memory management, except it's all automated so you can't screw it up (e.g. over-releasing or under-retaining). But it's subject to optimizations too (such as skipping the autorelease pool), which actually makes it faster than MRR in a lot of cases.
- fulafel 12y agoTop 5 Google hits for reference counting agree with me and say rc is a form of GC. GC pauses are because of work in other forms of GC too. As for explicitness... no. that's not explicit in my book.
- Ygg2 12y agoYeah, the error is on my part. Meant to say 'ARC is like a super primitive GC'. It gives a very small amount of automatism over manually freeing memory, but must be done by hand. It's a super primitive in a same way an abacus is a super primitive computer.
- eridius 12y agoYeah, no, you aren't helping your case at all. ARC is, again, not like a super primitive GC. And it most certainly is not "done by hand". That completely contradicts the "Automated" part of "Automated Reference Counting".
- Ygg2 12y agoYeah, no - is a very bad linguistic form. Try to avoid it. I speak from experience. Also, it is like a super primitive GC, in that it's a much more primitive and much more performant automatic memory management system (like GC). It's just a different level of abstraction we're talking here. It's no different than saying how is polygon is like a super primitive circle.
- eridius 12y agoGC and ARC are two very different approaches to memory management. Neither is more "primitive" than the other. They have different characteristics, different goals, different strengths & weaknesses.
- Ygg2 12y agoGuess I was wrong about 'like', it's 'is'. ARC is GC, what you call GC is a tracing GC. Any automated memory managment is garbage collection. http://www.memorymanagement.org/glossary/g.html#glossary-g http://www.memorymanagement.org/glossary/g.html#glossary-g