On Wed, Mar 2, 2011 at 11:41 PM, Ben Kloosterman <[email protected]> wrote:
> So what I'm saying here is that the cost of multiple GCs is low, but the > cost of multiple static compilation strategies is high. > > > > I agree with these statement… That said Bitc will have multiple standard > libs > > - you will need to support a kernel lib ( threaded ? , > reentrant ?) . In my case processes have a single user thread why pay the > price for a concurrent lib ? > > - You need to support libs for arm which may be a major market as > it is more c dependent and changing . > I do not believe that this is correct. Yes, there will be multiple libraries in the sense that there will be multiple different "DLL"-like things. That's not what I was referring to. What I was referring to is the need for multiple **compilation modles**. Concerning the cost of concurrency on non-concurrent applications, I think this is a non-issue for the following reasons: - To first order, *all* processors in the world - including embedded processors - are now multicore. In practice, this means that non-concurrent code is (perhaps sadly) going away. This may not be true for deeply embedded processors, but we should view those as a distinct target. - Similarly, nearly all processors are now multi-issue. I also think that it's an option to consider nullifying the lock operations (by NOPs) at library load time, leaving only one on-store image of the library. > Also customers will create there own libs this is a compete and utter > mess in Unix (esp linux) which should have been sorted out years ago . 95% > of apps can make do with a VM ( where you can change the GC strategy) and > the pauses are irrelevant ( too small to matter) . I would strongly push > customers into this at it gives a much better experience with user written > libs. > This is a separate discussion, and an important one. I'll take it up in a separate response. > Yes. And all of the really clever schemes do a good job of optimizing > away the barriers in a whole lot of cases - as we will. > > > > Every single one requires at least an if on each reverence … > > Yes. And on modern multi-issue cores, when correctly compiled, that if costs effectively nothing when not taken. I agree that what you say has been a very important issue in the past on single issue cores. Those cores are going away quickly. I also feel that you are ignoring a bunch of other techniques. > I like your example very much. It's a wonderful illustration of a bad > problem with a pretty simple solution. It's therefore a *great* example of > why optimizers designed to compile non-GCd languages don't do a good job on > GC'd code, and why compilation strategies really matter a lot. > > > > I see what your saying , you can communicate to the GC like don’t pause > now , or fix this object but this communication needs to be synchronized > ( ie an interlock on a variable) and what if you run lots of small loops ( > eg contains on a collection of strings) each requiring such communication... > This is *exactly* the right question, so let's open a discussion - again I'll respond separately to start another thread. > Umm. On modern multi-issue processors, assuming a decent compiler, I > doubt that very much, but there certainly is a cost, and it's certainly > significant. > > > > With the code as written on x86 and no apparent dependencies , yes you > are right. On some ARMs it will cost 100%... > Given truly crappy code generation (which has been historically typical on ARM) targeting a pre-cortex-A8 processor, I agree. For Cortex-A8 and later, I strongly doubt it. > ... Meaning super scalar is either dangerous telling the GC it requires > the reference after the work is done or requires synchronization which > again can be expensive for lots of little things. > Umm. Since correct superscalar implementations preserve sequential semantics, this is untrue. The bigger problem on ARM is the crappy memory model defined by the architecture. > Maybe I’m just not brave enough I like small steps and keeping it > simple. But I would have though if its easy there would be more Java or C# > concurrent collectors on the market... > There hasn't really been a compelling reason to do this work. Bytecode based code has been viewed as being not-time-critical, though this view is changing. > In fact if you write such a collector im sure you can sell it to M$. > I'm pretty sure they wouldn't, since Bjarne Steensgaard has already built and published the results from one. The big issue for MSFT has (had?) been that their support for ARM in general was weak, and they didn't have a compiler that targeted Thumb code (the 32-bit-wide ARM instruction set is going to be deprecated). Couple that with the fact that ARM has been very slow with their 64-bit story, and you have a lot of issues all in the air at the same time - more than enough to cause any sensible development organization to adopt a "go slow and see" approach. ARM's entire 64-bit story is in a serious state of disarray, and all of this stuff is something that you *really* don't want have to do twice! shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
