> > The problem with Mono performance is interesting. It's very possible that > two or three people, contributing actively, could make a *huge* improvement > in Mono performance. But as you note, the JIT implementation in mono was a > fairly small fraction of the effort. It's not at all out of the question > that one could simply build a new and better JIT and re-use most of the > library infrastructure investment that Mono has already made. > > Absolutely true but none of the layers you see in a modern compiler are present . Hotspot like runcheck elimination , polymorphic inline caches greater use of SIMD ( not just via copy) could easily add 20% ..
To me the big issue is not the issue but the reasoning for this .. they just dont see performance on the CLR as important. Maybe ( yes speculation) they just think its too hard to write a good compiler the current recommendation for performance goes something like dont use generics and interfaces , turn of run length checks use LLVM. If you had 2-3 people you would be better of fixing mono and LLVM and getting generics/interfaces to work a bit better work on run length elimination and inline caches which would be a bit painfull with more LLVM static compilation. Since "mono" is taken, the successor could perhaps be named after some more > aggressive disease. Perhaps "Spanish Flu". :-) > > I vote BirdF or PigF Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
