Walter Bright wrote:
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.)
I haven't seen this in the development of git, although to be fair, you
didn't mention the number of developers that were simultaneously working
on your project. If it was you alone, I can imagine you were reluctant to
change it just to see if something is faster.
Opensource projects with many contributors (git, linux) work differently,
since one or a few among the plethora of authors will almost always be
a true expert at the problem being solved.
The current pack-format and how it's read is one such example. It was
done once, by the combined efforts of Linus and Junio (this is all off
the top of my head and I cba to go looking up the details, so bear with
me if there are errors). Linus and Junio are both very good C-programmers,
but the handling of packfiles was not what you'd call their specialty.
Along came Nicolas Pitre, another excellent C programmer, who probably
has done some similar work before. He constructed a better algorithm,
eventually resulting in the ultimate performance win with a net gain
in both time and size (gj, Nicolas).
The point is that, given enough developers, *someone* is bound to
find an algorithm that works so well that it's no longer worth
investing time to even discuss if anything else would work better,
either because it moves the performance bottleneck to somewhere else
(where further speedups would no longer produce humanly measurable
improvements), or because the action seems instantanous to the user
(further improvements simply aren't worth it, because no valuable
resource will be saved from it).
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
