El 7/9/2007, a las 10:36, Walter Bright escribió:
Wincent Colaiuta wrote:
Git is all about speed, and C is the best choice for speed,
especially in context of Git's workload.
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.)
While I accept that this is generally true, I think Git is somewhat
of a special case. From a design perspective the data structures and
algorithms are remarkably simple -- therein lies its elegance. I
think it's precisely the kind of problem that can be tackled well
with a close-to-the-metal language like C.
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.
This mirrors my experience in desktop application development.
Despite GC being "slower" the app actually runs faster and a lot of
nasty problems (shared resources, locking etc) just magically go
away. Development is easier too.
But once again I think Git falls into a special category where the
design makes the "hassle" of developing in C worth it.
Wincent
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
