Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Fri, 7 Sep 2007, Andreas Ericsson wrote: > >> Wincent Colaiuta wrote: >> > El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?: >> > >> > > I just wanted to get a sense of how many people share this "Git should >> > > be in pure C" doctrine. >> > >> > Count me as one of them. Git is all about speed, and C is the best choice >> > for speed, especially in context of Git's workload. >> > >> >> Nono, hand-optimized assembly is the best choice for speed. C is just >> a little more portable ;-) > > I have a buck here that says that you cannot hand-optimise assembly > (on modern processors at least) as good as even gcc. That assumes that the original task can even expressed well in C. Multiple precision arithmetic, for example, requires access to the carry bit. You can code around this, for example by writing something like unsigned a,b,carry; [...] carry = (a+b) < a; but the problem is that those are ad-hoc idioms with a variety of possibilities, and thus the compilers are not made to recognize them. Another thing is mixed-precision multiplications and divisions: those are _natural_ operations on a normal CPU, but have no representation in assembly language. As a consequence, most high performance multiple-precision packages contain assembly language in some form or other. gcc's assembly language template are excellent in that they actually cooperate nicely with the optimizer, so the optimizer can do all the address calculations and register assignments and opcode reorderings, and then the actual operations that are not expressible in C can be done by the programmer. But anyway, I have worked as a graphics driver programmer for some amount of time, and bit-stuffing memory-mapped areas with data was still something where hand assembly was best. I have also done BIOS terminal emulators, and being able to write something like ld b,whatever myloop: push bc push hl call nextchar pop hl pop bc ld (hl),a inc hl djnz myloop in order to suspend the terminal driver until the application comes up with the next `whatever' output characters in an escape sequence is _wagonloads_ more maintainable than using a state machine or whatever else for distributing material delivered into the driver. But this requires that nextchar can do something like nextchar: ld (driverstack),sp ld sp,(appstack) ret and the entrypoint, in contrast, does outchar: ld (appstack),sp ld sp,(driverstack) ret Cheap and expedient. You just need to set up a small stack, and presto: coroutines, at absolutely negligible cost. I know that there are some "portable" coroutine implementations that use setjmp/longjmp in a rather horrific way, but those are way more unnatural. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
