5 ms·
M1 Memory and Performance
- pjmlp 6y agoI guess Apple's ARC needs all the help it can get to catch up with tracing GCs, there is a reason why everyone else in the industry went with them. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- boxed 6y agoRust doesn't do tracing GC, and Nim is moving to an ARC system I hear.
- pjmlp 6y agoBorrow checking isn't reference counting and Nim still needs to prove itself.
- physicsyogi 6y agoRust can use reference counting though, in addition to borrow checking.
- pjmlp 6y agoJust as it can use a tracing GC, like in Servo interop.
- boxed 6y agoBorrow checking isn't tracing GC. That's all I said and all I meant.
- akmarinov 6y agoGCs are faster if you have 4 times the needed RAM. Most everyone in the industry doesn't care about wasting RAM.
- pjmlp 6y agoNope, reference counting is a GC algorithm, and having a tracing GC doesn't preclude other forms of memory management, e.g. D or .NET Native.
- mpweiher 6y agoMixing tracing GC with other forms of memory is an open research project. Doesn't mean it hasn't been "done", for example Google has talked about getting their GCs to interop in Chrome, but it's (a) really hard and (b) so far results are, at best, "mixed".
- pjmlp 6y agoLet's see Swift when catches up with .NET 5 improvements. Apple's talk about RC over GC is just marketing speak for the failure to have a tracing GC in Objective-C that wouldn't crash left and right when integrated with C like code. It was a very sound decision given Cocoa semantics, and the difficulty to make anything written in C not to fall apart with segfaults, but lets not oversell it. Likewise Swift RC makes sense from having to integrate with Objective-C runtime and existing ecosystem, but again that is all about it. There is no RC implementation with comparable performance to tracing GC languages that isn't just yet another tracing GC from the amount of runtime support needed to make it actually fast.
- mpweiher 6y agoSo we are agreed that mixing tracing GCs with any other form of memory management (including another GC) is an unsolved problem. Good. Swift is a disaster, also agreed. So? For the rest: actual research disagrees with your forceful but unsubstantiated assertion: https://2013.splashcon.org/details/oopsla-2013-papers/21/Taking-Off-the-Gloves-with-Reference-Counting-Immix https://2013.splashcon.org/details/oopsla-2013-papers/21/Tak... And once again, tracing GCs do well in microbenchmarks where you only check the cost of local operations. They are horrible when you take the global effects into account, with those local/benchmarking advantages not translating into real world use. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Very similar to JITs, which also do massively better in microbenchmarks than in production code: http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html Oh, and integrating well and without high cost to fast languages where you have even more control is actually an important feature.
- benbenolson 6y agoBut all of these performance measurements won't matter if users don't actually own their devices; without being able to run applications without Apple's permission and knowledge, these devices should be ignored by many privacy-conscious computer scientists from the get-go.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- dogma1138 6y agoI don’t see the reason for the focus on the amount of memory given the potential theoretical advantages of a unified memory pool that extends beyond the DRAM. PCIe gen 4 SSDs have obscene data rates and tons of IOPs. In fact the whole SSD is now an extension of your RAM is a selling point of the new consoles. Is it as fast as having more DRAM in all possible scenarios? No, but with good memory management the real world performance might very well be identical to a system with the same capabilities and even greater than traditional memory systems with larger non-unified pools.
- voldacar 6y ago>Is it as fast as having more DRAM in all possible scenarios? Is it as fast as having more DRAM in any scenario?
- zepto 6y agoObviously so based on Apple’s numbers.
- dogma1138 6y agoNot just Apple we have multiple other examples of when a unified memory pool outperforms larger non unified memory pools just due to the overhead of having to copy memory manage multiple memory address spaces with all the translation and lookups you need to do etc. We have cheap consumer SSDs today offering 5GB/s of read performance and more than enough I/O to satisfy caching.
- dogma1138 6y agoYes, and based on non Apple systems it’s faster than having much larger pools of non-unified memory. Essentially all the big compute vendors moving towards memory unification and cache coherent interfaces.
- voldacar 6y agoOk I misread the numbers somehow. This is interesting - I wonder what it means for the future of conventional desktop computing, when considering peripheral chips like GPUs that already have DMA capability
- moondev 6y agoIs "unified" the same thing as "shared" outlined here? https://en.wikipedia.org/wiki/Shared_graphics_memory https://en.wikipedia.org/wiki/Shared_graphics_memory I'm curious if the same drawback mentioned for shared applies to unified > A side effect of this is that when some RAM is allocated for graphics, it becomes effectively unavailable for anything else, so an example computer with 512 MiB RAM set up with 64 MiB graphics RAM will appear to the operating system and user to only have 448 MiB RAM installed.
- ksec 6y ago>Is "unified" the same thing as "shared" outlined here? Yes. Previously shared was used in the context and goal of cost savings. But* Unified* now has a goal of higher performance.
- smallstepforman 6y agoSanitory memory habits are still faster than using reference counting ...
- bfrog 6y agoSo basically they needed their own silicon to deal with Arc's.
- crb002 6y agoYou pay roughly 1 NS per foot of light travel. Closer to the CPU means lower worst case speed of light bound latency.