I'd say that manual memory management is usually going to be faster than GC unless you have really bad manual management and a very good GC. The best a good GC can hope for is to be close to manual management. That's one of the reasons the majority of systems software is still in C/C++ (memory layout is another). Note that not all GC's are created equal: the performance of GC's can range from terrible to excellent depending on the algo & the tuning. The Oracle JVM alone has several GC algos built-in each with its advantages & disadvantages.
On Wednesday, May 13, 2015 at 6:58:24 PM UTC+2, Páll Haraldsson wrote: > > On Monday, May 11, 2015 at 10:03:20 PM UTC, Michael Louwrens wrote: >> >> I am starting to read "Region-Based Memory Management for a >> Dynamically-Typed Language >> <http://link.springer.com/content/pdf/10.1007/b102225.pdf#page=240>" it >> proposes a second inference system, region inference. >> > > Interesting, I just scanned the paper down to Table 1. I see GC is in all > ten benchmark cases faster than "Region" based. The heap size is usually > larger (not always! Can be order of magnitude larger for "Region") for GC, > so there is/can be a time-space trade-off. > > Should I expect GC (I assume this GC is similar to Julia's) to always be > faster for manual memory management (such as in C/C++)? This "region"-based > is not the same/similar as in C/C++? > > GC has to do the same allocations (and deallocations - except in a > degenerate case - closing program..) as manual memory management - at I > expect the same speed, noting: > > GC *seems* to have an overhead as it has to scan the heap, but that is > overblown as a drawback, right? As with larger memories that overhead will > be arbitrarily reduced? [Not taking caching effects into account.. The > memory itself will not cost you anything (in a single application scenario) > as RAM burns energy whether it is "used" or not.] And compared to C/C++ you > would use less redundant copying. How much necessary copying is there, > really..? > > > I do not worry to much about hard real-time, GC seems to only have > drawbacks with stuttering (and not so much with better GC algorithms). Even > for games that are only soft-real-time wouldn't it be ok? Already as is (in > 0.4)? It is not clear to me that something other than GC would be helpful > there (one of the benchmarks was ray-tracing), as you could force GC on > vblank, and in next-gen ray-tracing, vblank/fps isn't that important.. > > Besides, if you only work on datastructures that are > static/updated-in-place, there shouldn't be much GC activity? > > -- > Palli. > >
