I can appreciate that. I originally got into writing compilers because
my game (Empire) ran too slowly and I thought the existing compilers
could be dramatically improved.
And technically, yes, you can write code in C that is >= the speed of
any other language (other than asm). But practically, this isn't
necessarily so, for the following reasons:
1) You wind up having to implement the complex, dirty details of things
yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I
run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're reluctant
to try a different algorithm to see if it's faster. I've seen this
effect a lot in my own code. (I translated a large body of my own C++
code that I'd spent months tuning to D, and quickly managed to get
significantly more speed out of it, because it was much simpler to try
out different algorithms/data structures.)
2) Garbage collection has an interesting and counterintuitive
consequence. If you compare n malloc/free's with n gcnew/collections,
the malloc/free will come out faster, and you conclude that gc is slow.
But that misses one huge speed advantage of gc - you can do FAR fewer
allocations! For example, I've done a lot of string manipulating
programs in C. The basic problem is keeping track of who owns each
string. This is done by, when in doubt, make a copy of the string.
But if you have gc, you don't worry about who owns the string. You just
make another pointer to it. D takes this a step further with the concept
of array slicing, where one creates windows on existing arrays, or
windows on windows on windows, and no allocations are ever done. It's
just pointer fiddling.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html