Janthinidae:
> There is no benchmark, it's just that the software has to have a
> worstcase latency to some relevant below 1 ms. If the GC kicks in the
> wrong time shit happens. With not using malloc at all or the GC I just
> have some kind of proof that this will never be a problem.
> ...
> Trying everything with alloca is maybe a better idea (and rewriting the
> Scope template).
The GC gets active when you allocate memory. So if you allocate some GC-heap
memory at the start of your program, and then you never allocate some more of
it, the GC will be dormant. So it's not required to allocate everything on the
stack.
> Yes both are Turing complete :)
I meant to add "with similar efficiency of C++ code too" :-)
> Ok I understand it, but if some linkers fail, then isn't this the
> linkgers problem?
I don't know, but I presume lot of people lump compiler and linker in their
mind.
> then one can ask why it's
> not possible to write
>
> int[10000000] t10 = void;
>
> but possible to write
>
> int[1000000] t0 = void;
> ...
> int[1000000] t0 = void;
I don't know. I guess the total amount of memory and the largest chunk of
memory are two different parameters for a linker.
> But the problem for me here is that all static arrays are in the .data
> section (that's why I mentioned it) and make the executable that big.
> If I declare an array with "Type[N] = void" I somehow expect, that it
> is not initialized and that there is no data allocated in the .data
> section.
Try this too:
__gshared int[1_000_000] array;
void main() {}
> Ok I'll do that. Thanks once more.
Generally Walter listens to efficiency concerns. You are welcome.
Bye,
bearophile
