On 09.03.2019 14:33, Jonas Maebe wrote:
On 09/03/2019 13:06, Fabio Luis Girardi wrote:
Thanks by your feedback. Do you think that should I fill a bug report?
That's up to you.
I think that 2GB on 64 bits a very conservative limit.
2GB stack space on is very large on any platform. Normally the heap is used for
large allocations.
This probably mostly stems from 32 (and 16) bit platforms, where the issue was that it was hard to have large contiguous
address ranges in the virtual memory space. OTOH,
* several systems still support limiting the stack size separately from the rest of the program's memory to more quickly
catch infinite recursion errors. Thread stacks are also often limited in size.
* The offsets you can encode in a single instruction are always limited. E.g. on x86-64, offsets relative to the
stack/frame pointer are limited to 2GB. So if you allocate more stack space than that, accessing local variables that
are outside this addressable range will become slower because you'll need extra instructions (while local variables are
often accessed a lot)
FYI on 64-bit Windows the stack size limit is hard coded to 1GB. The same 1GB limit applies on 32-bit Windows. Probably
Linux can be configured for larger stack.
But I agree with Jonas, that using huge local vars is pointless and inefficient.
So it is not the FPC issue, but the library design issue.
Yuriy.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
