Re: [Lightning] Re: Lightning source compatibility

[Paulo César Pereira de Andrade]

2010/9/22 Ludovic Courtès <address@hidden>:
> Hi,

  Hi,

> Paulo César Pereira de Andrade
> <address@hidden>
> writes:
>
>>>>   Another good advantage (other than strict type/value checking) is
>>>> compile time. The pseudo assembler I use as a testing tool, at
>>>>
>>>>
>>>> http://code.google.com/p/exl/source/browse/trunk/check/lightning/lightning.c
>>>>
>>>> compiles roughly 5 times faster now, the significant speed increase I
>>>> suppose is because it does not need to parse a large sequence of
>>>> nested macro calls, and then a large amount of duplicated expressions.
>>
>>   I was actually expecting it to become slower, but it seems the C 
>> preprocessor
>> is the problem, so, better not to abuse macros :-)
>
> OTOH, how does this affect compilation time of a smaller file (the one
> above contains 4000+ lines, with many large macros expansions)?  More
> importantly, does compilation time really matter?

  Probably for very small files, it most likely would not make much of a
difference, as an example, the test tool itself spawns cpp to parse the
*.tst files. An interesting fact was that initially, it used qsort/bsearch to
build and keep sorted the labels table, but suddently, when generating
like over 10k labels (to test all register combinations), it was like 99.9%
of the time in qsort, then I added a simple hash table to use for labels...
Now, for most test cases, actually like over 50% of the time is in cpp.
But that does not mean cpp is bad, it is parsing very complex macros,
and most times generating several MB of input for the pseudo assembler.

  I commented before that this was just worth a note, but compilation time
does not matter much, it is jit generation and jit run speed that would matter.
And this was also the reason I started working on adding inline functions, so
that more complex logic could be used, static type checking, more clear
conditional logic, for example, choosing x87, sse, and specific sse versions,
or very simple things, like instead of transforming "jit_addi_i(%r0, %r0, 1)"
in the explicit add constant one, it uses the "inc" opcode (but not for
jit_addc of course, as inc does not set the carry).

> And if cpp is slow on some pathological input, then cpp hackers could
> analyze whether it makes sense to optimize it, as opposed to having cpp
> users change their coding style just to work around the slowness.  :-)

  The problem is more like the macro expansions would generate way
too much duplicated expressions, most of which would be constant
expressions, but again, the idea of using inline functions was also to
avoid duplicated non constant expressions, and those should be what
would cause the slowdown, in the compiler, not in cpp itself.

> Thanks,
> Ludo’.

>

Thanks,
Paulo