Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

Johannes Schindelin [off-list ref] writes:

On Fri, 7 Sep 2007, Andreas Ericsson wrote:

quoted

Wincent Colaiuta wrote:

quoted

El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:

quoted

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