Re: C23 thoughts and opinions

On 26/05/2024 17:35, Michael S wrote:

On Sun, 26 May 2024 16:25:51 +0100
bart <bc@freeuk.com> wrote:
 

On 26/05/2024 14:18, Michael S wrote:

Are you talking about a 5MB array initialised like this:
>
unsigned char data[] = {
     45,
     67,
     17,
     ...            // 5M-3 more rows
};
>

 Yes.
 

The timing for 120M entries was challenging as it exceeded physical
memory. However that test I can also do with C compilers. Results for
120 million lines of data are:
>
    DMC          -    Out-of-memory
>
    Tiny C       -    Silently stopped after 13 second (I thought it
had finished but no)
>
    lccwin32     -    Insufficient memory
>
    gcc 10.x.x   -    Out of memory after 80 seconds
>
    mcc          -    (My product) Memory failure after 27 seconds
>
    Clang        -    (Crashed after 5 minutes)
>
    MM         144s   (Compiler for my language)
>
So the compiler for my language did quite well, considering!
>

 That's an interesting test as well, but I don't want to run it on my HW
right now. May be, at night.
 

>
Back to the 5MB test:
>
    Tiny C     1.7s    2.9MB/sec (Tcc doesn't use any IR)
>
    mcc        3.7s    1.3MB/sec (my product; uses intermediate ASM)

 Faster than new MSVC, but slower than old MSVC.

My mcc is never going to be fast, because it uses ASM, which itself will generate a text file several times larger than the C (so the line "123," in C ends up as "   db    123" in the ASM file).
However I've looked at a possible way of speeding this up in general, see below.

>
    DMC        --      --        (Out of memory; 32-bit compiler)
>
    lccwin32   3.9s    1.3MB/sec
>
    gcc 10.x  10.6s    0.5MB/sec
>
    clang      7.4s    0.7MB/sec (to object file only)
>
    MM         1.4s    3.6MB/sec (compiler for my language)
>
    MM         0.7     7.1MB/sec (MM optimised via C and gcc-O3)
>

 That's quite impressive.
Does it generate object files or goes directly to exe?

All produce EXE files, via linkers if necessary, except Clang (its hefty LLVM installation doesn't come with standard C headers, nor a linker; it depends on MS tools, but never manages to sync with them).
My MM product directly generates EXE files with no intermediate OBJ files.

Even if later, it's still impressive.

So, it's more impressive if it first generates an OBJ file then invokes a linker? I'd have thought that eliminating that pointless intermediate step would be more impressive!
Anyway, I thought of a way of speeding up initialisation of byte-arrays which is, instead of parsing each value into its own AST node, to directly parse successive numeric values into a special data-string object (similar to normal strings, and identical to the data-strings used for embedded data).
Then there is only one AST node containing one 'string' value, instead of 5M or 120M nodes.
This produced a timing, for 5M lines, of 0.34s (0.28s optimised), a throughput of 15-18MB/sec.
When I applied this to the 120M line data (which is a 0.6GB source file), it finished in 6.5 seconds (5.5 optimised), or 18-21MB/sec. Previously that took 144 seconds.
However I can't keep that experimental code, since if it turns out not all values are constant expressions, it has to revert to normal processing, which is tricky to do; it may already have read 1M numbers and needs to backtrack). This was just to see how fast it could be.
Processing 120MB as binary rather than text is still faster; that works at up to 110MB/sec with an optimised compiler.

As a reminder, when using my version of 'embed' in my language,
embedding a 120MB binary file took 1.3 seconds, about 90MB/second.
>
>

But both are much faster than compiling through text. Even "slow"
40MB/3 is 6-7 times faster than the fastest of compilers in my
tests.

>
Do you have a C compiler that supports #embed?
>

 No, I just blindly believe the paper.

Funny that no one else has access to an implementation! Those figures have been around for a while.

But it probably would be available in clang this year and in gcc around
start of the next year. At least I hope so.
 

It's generally understood that processing text is slow, if
representing byte-at-a-time data. If byte arrays could be represented
as sequences of i64 constants, it would improve matters. That could
be done in C, but awkwardly, by aliasing a byte-array with an
i64-array.
>

 I don't think that conversion from text to binary is a significant
bottleneck here.

That's not quite what I meant. That conversion is the lexical part of processing source code, it can be very fast.
It is parsing, and especially constructing a list of 5M or 120M AST nodes, each containing one expression, and the subsequent type-checking and code generation that takes the time.
However your benchmark looks intriguing and I'll have a closer look later.