On Sun, Oct 13, 2013 at 1:48 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > I should have been clearer ... I meant expensive in terms of development cost ... Which is why I stated a very quick to write and simple RC system that can evolve into it. This also gets bitc out the door. > 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. > Absolutely , I do think its good to have different opinions because we come from different areas. I have never cared that much about mem usage 150% or 200% min heap im fine with and reduced pauses are a nice to have ( which regions and better stack based algorithms will do anyway) . There are ways to move stuff of heap and a standard lib can improve. I like Rust but i think its complex and completely agree all those pointer types gain very little eg region analyses can do most for the programmer leaving a much simpler system - which is in turn easier to optomize.. The thing that impresses me most about Rust is you can use it now on embedded systems or to write libs . But i have changed my position a bit , 1) 10-20% just does not matter if you can express algortihms in SIMD ( see my other ad nauseum posts) and id much rather have basic RC as pointed out and SIMD expression as part of the language than a full RC-immix system. You get easier to write SIMD in the language and it can be called by native programs and you have a game changer - you need not much else . 2) the cost of concurrency is shocking me.. and i dont really see the reasons behind it. In languages with more pure functions it makes sense but with Java or C# it makes little sense. You have mutable data and 90% of the code will fail without a lock ...every class is marked in MSDN whether its thread safe. Does anyone thing that monos position to turn runlength checking of for benchmarks to be acceptable ? The same with simple Ref counting its an issue because of concurency. Even more so i think the idea of parralelism is failing with 1 important exception . Recent work has created easier to use libs but except fro big jobs ( which were easy enough to do anyway ) they create massive amounts of contention ( except for offloading IO ) .. I see more and more people going back to single threaded processing but ofloading IO with styles similar to Actor or Lmax or nodejs and they get bettert results with easier to write apps . The exception is the old FORTRAN style scientific work which is nearly always SIMD . Once your on SIMD the concurrency costs dont matter , your talking multiples.. So im thinking Its better to have structures in the standard lib which help gurantee concurency not the runtime since you need locks and a carefull design anyway. Or at least tell the JIT to emit which. Maybe for loops have for and foreach as well as concurrent foreach and concurrent for.. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
