Language Shootout

[kmk]

Craig Black Wrote:

> I like the idea.  Since Walter's time is so limited we shouldn't expect him 
> to do all of the work.  If someone who is performance savvy could look at 
> the code generated and try to suggest solutions.  Then this information 
> could be submitted to Walter to help improve the compiler.
> 
> -Craig
> 
> "Dan" <murpsoft at hotmail.com> wrote in message 
> news:eu8t71$d2p$1 at digitalmars.com...
> >
> > Hi guys,
> >
> > This idea will only work with Walter in on it.  : p  I was thinking that 
> > we might go through the various benchmarks in "the language shootout" and 
> > find out those items where D is significantly behind for any reason, and 
> > correct the performance.
> >
> > For example, against Eiffel, you see their Fasta implementation is 38 
> > times faster than D's.  Why not compile the code, find out how it works 
> > and see why D's that much slower - and then Walter can fix the code?
> >
> > Likewise for GCC's k-nucleotide, G++'s meteor-contest and k-nucleotide, 
> > Clean's sum-file, Erlang's cheap-concurrency etc.
> >
> > We may find that there's a good reason D is slower, but we may find 
> > there's a performance bug or enhancement that would significantly improve 
> > D?
> >
> > Just an idea. 
> 
> 

Most of the differences in speed when comparing to C and C++ on that site have to do with slower recursion when using the DMD compiler. When I compare GDC with DMD using the same applications from that site, GDC offers on average 2x better performance in recursion. 

So, if GDC compiled apps were compared with the C and C++ apps compiled with GCC, I think you would find that D performs just as well if not better.