> >> What interestes me here also is the "managed cost" , Java and C# ( on >> windows) are not far behind native yet they pay heavy costs ie header , >> bounds checking , card table , GC , no embedded value types if you add >> those costs it means the base performance is higher than the native >> languages. Probably due to JIT and Polymorphic inline caches ( which alone >> were measured at 14%) . I note some people using LLVM have noted that the >> execution engine ( which compiles an encoded IR) runs faster in a lot of >> cases. >> > > There is a *huge* difference between a JIT compiler and a low-level > dynamic binary translator. The JIT compiler has to do all sorts of stuff > like register allocation and optimization. The goal of a good DBT is to do > *none* of that. JIT optimizes for target performance. DBT optimizes for > least-overhead translation. This is part of why I'm prepared to use DBT to > support late-bound GC - it has no dynamic overhead to speak of. >
ExecutionEngine JIT not Execution engine bc. I dont know how much it does though ... > > >> Anyway i have been inspired and think i will build something to >> investigate the higher perf costs ( and learn more) , bitc may benefit >> from the experiment if i get somewhere.... >> > > Yeah. I've been thinking wistfully in that direction as well. Mono isn't > that good, and the overwhelming majority of the work there is in the class > library. > I think LLVM is the best here.. there is new GC work all the time , rust are pushing there changes back in etc .. its slow but it will happen . Im only using the parser and tokenizer from Mono ..though i will just stick with LLVM# ( LLVM C# compiler a Masters student in Thailand wrote) ( its old ,incomplete has tons of bugs but style is reusable and there is quite a lot of code there ) . It didnt have memory allocation but it will get me up and running with something fast and i can get into more important stuff and with the list i mentioned it has a reasonable time frame , prove quite a lot of things and produce something usefull .. Anyway compiler will be C# as will the base language initially. > I've actually been wondering if it would be worth the time to do a new > implementation of CLR. On the one hand, it would be nice to have a > high-performance CLI for linux. On the other, it would be nice to have a > working bytecode machine as a jumping off point for BitC. > > Except, of course, that it's harder than it looks on paper. :-) > Its a big job ..What about CLR on Vmkit ( CIL to IR translator is only a few week project) and make changes / fork Vmkit . This would allow a much larger audiance. Im not sure where a CLR for Linux will go , it would be funny though for it to beat the Java bench marks and have low pauses but its a big ask for them to change . Mono would have improved if there were a lot of users so you need a compelling case. The problem with mono is it wasnt better than Java as the JVM on Unix are much better but its entrenched now. I can see merchant banks being tempted even if a commercial product if you can get C++ competative as they can rationalize there C#/Java/C++ into just C#. Really there are big groups - Java Middleware tradition bastion ( and some C#) - C++ Server and games . Where ultra high performance and no pauses . - C# Desktop - Dynamic language server web ( and some C#) - HTML5/ Javascript web apps / Flash and silverlight will fade in this space . - Hand helds are going native iOS /WinRT and even Android for competative advantage. Most are pretty entrenched , i would say hand helds development being native competative is the best market ( i dont mean financially but where you will get a userbase) . There are a lot of small hand held apps where the extra cost of native does not show but as these apps grows and the fact you need mutli platform so will the pain and development costs. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
