Please allow me to ask a stupid question.  Why are there three benchmarks for each version?  Are you testing on different computers or something?

>The most amazing thing here is the dramatic performance difference between these D runs and the previous ones.  I won't speculate on why, bu the exact same app appears to be running 3 times as fast as it did this morning.

That is very strange ... so it seems that these benchmarks, being inconsistent, were inconclusive.  Sounds like we need more testing.  Anyway, D came out on top that time so that is good news!

>Finally, as these tests were quite informal I don't suggest reading too much into them.

Agreed.  Benchmarking one small program doesn't really say much.

>However I think a reasonable conclusion would be that D
>is faster than C++ for typical user applications

I would agree, but not just based on a single benchmark.

-Craig




-Craig

> By the way, I do think that GC performance can be improved significantly over where it is now, so don't take my other reply as an admission that GC is slow.  Also, I suspect that by the time D hits 1.0, GC performance will be much improved over what it is now.

I hope that you are right.

>This can be achieved a
> number of different ways, but the most obvious would be for the GC to ignore memory blocks that don't contain pointers.

I didn't know such selective scanning was possible with GC.  Would this optimization be easy to implement?  If such an optimization were implemented, then I suppose it would be wise to keep heap allocation local to small blocks of memory so that the GC would not have much to scan.

-Craig

Craig Black wrote:
> Please allow me to ask a stupid question.  Why are there three benchmarks
> for each version?  Are you testing on different computers or something?

I wanted to reduce the chance that random system noise would affect a result.  I suppose I could have simply posted the mean for each test, but it was easier to cut & paste than to get out a calculator.


Sean