I had a very close look at mono last year and was very disapointed , there was like zero work in the last 7 years on the actual jit compiler which was so far behind the Microsoft CLR and Java that its not funny. Major things that are missing are a good GC ( there current one is poor to ok the boehm/simple one they used for years was terrible) , some bounds check elimination ( they eliminate only a single trivial case) ,polymorphic inline caches etc etc so you dont really get any of the "runtime" benefits on mono you may as well statically compile. To have fast apps in mono you use LLVM now but its a very slow compiler.. and none of the generic / interface stuff works over LLVM (which then uses the old Mono code) . Mono does have some flashy things like a few SIMD intrinsics but the project seems to create things either for basic need ( the libs , platform support ) or marketting ( eg SIMD) but no general optomizations of the compiler etc like you see in Java runtimes. And since they use LLVM more it may be best to just use it. So while the project will run on Linux it will be much slower than windows and will certainly be little used for systems programming ..because you need the mono runtime and poor GC support.
If you just want to get something out there mono will do the job and fairly quick ( as the run time is reasonably easy to targtet ) but it wont go anywhere.. I still think either LLVM direct or a fork of Rust maybe the best way to introduce some of these elements with the best chance of long term success. For rust the code is modern and in rust not C++ and uses LLVM so a project can mature into its own self hosting code. They borrowed some ideas from bitc ( and have a solution for the issues found) and are maturing but have a poor run time library and lack natural number support. A really strong suite of rust is the trivial calling of C code which makes using it with existing libaries attractive. They are also currently discussing what to do about a GC , for those who dont know , rust is based on "tasks" now you can have a 1 task program but you can also have multiple tasks each with their own message pump.. allocations are specifically stated as global or local . They only have a poor GC for shared ( but you can also have non GC shared memory ) but there is work going on the GC now and the fact that memory is segmented means for most problems GCs will stay much smaller. There are also some performance issues due to poor runtime code compared to c and the fact they use a growing segmented stack which will probably become an option soon rather than the only type.. Also as LLVM jit support improves so will the case of a rust jit . On Sun, Jul 14, 2013 at 7:30 AM, Nigel Williams <[email protected]>wrote: > On Sun, Jul 14, 2013 at 8:22 AM, Jonathan S. Shapiro <[email protected]> > wrote: > > ...and of course that's > > part of what the DaVinci JVM was exploring - annoying that the site is > down > > at the moment - so maybe I'm jumping to uninformed biases about V8 and > > friends. > > Archive.org's WayBackMachine has navigable snapshots of the Da Vinci > Machine Project webpages: > > > http://web.archive.org/web/20130501134754/http://openjdk.java.net/projects/mlvm/ > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
