On Sun, Oct 13, 2013 at 1:51 AM, Bennie Kloosteman <[email protected]>wrote:
> 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. > Sorry I misinterpreted. > 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) . > One of the things that I find curious is that there are no measurements in the literature for malloc/free under constrained total heap size, and also that nobody talks about the overhead of the arena management structures. In most mallocs there is an 8 to 16 byte overhead per allocated object (on 32-bit systems). Java object headers generally run 8 bytes. Where I'm going here is that the the required heap sizes may be closer than people think, simply because corresponding studies do not appear to have been done. > 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 . > I think we all know by now that you are very excited about SIMD. I understand that mono isn't doing a good job, but it's not hard to do. > 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. > What numbers are you looking at that are shocking you? In languages with pure functions there is essentially *no* cost to concurrency, so I don't understand what you are saying there. In Java and C# the problem boils down to maintaining memory consistency at the hardware level, which is inherently expensive. 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.. > Implementation of concurrent algorithms has to be done in the language (possibly in the library). *Safety* of concurrency has to be done in the compiler/runtime. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
