Interesting on keeping the references for GC purposes without overhead , I suppose it is mainly needed for "pauseless" GC ( I hate that term as they are still not pauseless) but you may be able to remove the write barrier on some Generational collectors giving you a significant boost.
Re Go as an alternative : the fact Go is now supporting gccgo which is faster in the tests I have seen ( in my brief glance) and similar to Haskell (GHC) confirms my suspicions that while your own compiler can be faster , the work is so huge ( and not just the initial implementation but maintaining it eg ARM , MIPS , 32/64 , SSE4 / YMM etc) that you will never get close unless you can manage a significant dedicated team for a few years just on performance tuning. Ie this is far more than the 10% saving .. I know this is a much later step but its nice to have an idea where things are heading.. and the options are limited eg LLVM - C++ / Loose the 10% gcc - C++ / A mess / loose the 10% one of fastest compiler go backend - slower than above good runtime /GC support Open64 - Probably not up to scratch go it alone - long maturity time , highest potential IF you can dedicate the resources. Only option for a non C++ implementation. No stand out choice ..It may be better to take LLVM/gcc and add fork it / add an option to ensure it works well with a GC . Though the introduction of Meta Data in the IR took forever which may indicate changes are difficult. Also from the GO FAQ , while this looks interesting its still a C++ compiler. Also "What compiler technology is used to build the compilers? Gccgo has a C++ front-end with a recursive descent parser coupled to the standard GCC back end. Gc is written in C using yacc/bison for the parser. Although it's a new program, it fits in the Plan 9 C compiler suite ( <http://plan9.bell-labs.com/sys/doc/compiler.html> http://plan9.bell-labs.com/sys/doc/compiler.html) and uses a variant of the Plan 9 loader to generate ELF binaries. We considered writing 6g, the original Go compiler, in Go itself but elected not to do so because of the difficulties of bootstrapping and especially of open source distribution-you'd need a Go compiler to set up a Go environment. Gccgo, which came later, makes it possible to consider writing a compiler in Go, which might well happen. (Go would be a fine language in which to implement a compiler; a native lexer and parser are already available in <http://golang.org/pkg/go/> /pkg/go.) We also considered using LLVM for 6g but we felt it was too large and slow to meet our performance goals." Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
