On Sat, Oct 12, 2013 at 9:58 AM, Bennie Kloosteman <[email protected]>wrote:
> - Its complex and expensive ( though less so than a concurreny GC) > I'm getting frustrated, though not at Bennie. It's a prior constraint in the BitC discussion that we *will* have a memory safe language. At the moment, that means GC or RC. Then we say we want real time response and a minimal marginal DRAM requirement. Then somebody does a *tour de force* piece of work that *gives* us all that and we bitch about the overhead. Complaints about overhead almost always need to be framed comparatively. In this case, we aren't taking into account the overhead of unmanaged languages. Yes, spending ~30% of our time in reference counting, allocation, and deallocation is a lot (and I think we can do better). But * unmanaged* allocators impose a ~28% increase in L1 cache misses, which is essentially 1:1 with execution time. So what we're really likely to lose here (if anything) is 2% in overall performance. And we've got tricks that RC-immix couldn't use. And if you're not one of those pesky people doing real-time (and you know who you are!), and you have the DRAM to spare, you're welcome to switch to conventional and/or concurrent GC. TANSTAAFL, folks. There ain't no such thing as a free lunch.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
