Re: else ladders practice

On 24/11/2024 15:00, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

On 24/11/2024 05:03, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

>

As for sizes:
>
    c:\c>dir hello.exe
    24/11/2024  00:44             2,048 hello.exe
>
    c:\c>dir a.exe
    24/11/2024  00:44            91,635 a.exe         (48K with -s)
>
(At least that's one good thing of gcc writing out that weird a.exe each
time; I can compare both exes!)

>
AFAICS this is one-time Windows overhead + default layout rules for
the linker.  On Linux I get 15952 bytes by defauls, 14472 after
striping.  However, the actual code + data size is 1904 and even
in this most is crap needed to support extra features of C library.
>
In other words, this is mostly irrelevant, as people who want to
get size down can link it with different options to get smaller
size down.  Actual hello world code size is 99 bytes when compiled
by gcc (default options) and 64 bytes by tcc.

>
I get a size of 3KB for tcc compiling hello.c under WSL.

 That more or less agrees with file size that I reported.  I
prefer to look at what 'size' reports and at looking at .o
files,

Oh, I thought you were reporting sizes of 99 and 64 bytes, in response to tcc's 2048 bytes.
So I'm not sure what you mean by 'actual' size, unless it is the same as this reported by my product here (comments added):
   c:\cx>cc -v hello
   Compiling hello.c to hello.exe
   Code size:          34 bytes         # .text
   Idata size:         15               # .data
   Code+Idata:         49
   Zdata size:          0               # .bss
   EXE size:        2,560
So at 49 bytes, I guess I win! But in terms of actual file-size, since both tcc/cc can run programs from source, then all that's needed is hello.c, 53 bytes minimum.

It can also do manipulations that are harder in a 'softer', safer HLL.
(My scripting language however can still do most of those underhand things.)

 Anything computational can be done in a HLL.  You may wish to
play tricks to save time.  Or possible some packing tricks to
save memory.  But packing tricks can be done in HLL (say by
treating whole memory as a big array of u64), so this really
boils down to speed.

I'm sure that with Python, say, pretty much anything can be done given enough effort. Even if it means cheating by using external add-on modules to get around language limitations, like using Ctypes module, which you will likely find uses C code.
This is different from having things part of the core language so they become effortless and natural.
But, everything you've said seems to have backed up my remark that people only seem to consider two possibilities:
* Either a scripting language where it doesn't matter that it's 1-2 magnitudes slower than native code
* Or a compiled language where it absolutely MUST be at least as fast as gcc/clang-O3. Only 20 times faster than CPython is not enough!
(In my JPEG timings I posted earlier today, CPython was 175 times slower than gcc-O3. and 48-64 times slower than unoptimised C.
Applying the simplest optimsation, which I can tell you adds only 10% to compilation time) made native code over 100 times faster than CPython, and only 50 slower than gcc-O3. This was on a deliberately large input
Basically, if you are generating even the worst native code, then it will already wipe the floor with any scripting language, when comparing them both executing the same algorithm.)