On Thu, Oct 24, 2013 at 12:19 AM, Ben Kloosterman <[email protected]>wrote:
> > 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. > 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'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. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
