On 1/13/22 10:58, Ben Grasset via fpc-devel wrote:
On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel
<fpc-devel@lists.freepascal.org> wrote:
I haven't tested in Windows, but it would be very strange and
suspicious if the results are very different.
It would be neither of those things. The exception handling on x64
Windows is the fastest provided by FPC, for example (though the
compiler AFAIK avoids doing anything that would generate exception
handling code within its own codebase as much as possible).
So, instead of giving actual benchmark data on the Windows performance,
you speculate by claiming that having faster exception handling matters,
and then you immediately debunk your own argument by admitting it
probably doesn't matter for the compilation speed. Sure, using SSE2 is
also faster, but it doesn't matter for the compilation speed at all,
because all the performance critical parts are integer code, therefore
it would be silly to give this as an argument as well. Sometimes 64-bit
is faster (due to SSE2, AVX, exception handling, having more registers),
sometimes 32-bit is faster (pointers are half the size, leading to less
memory use, leading to less memory bandwidth requirements and more data
fitting in the processor caches). Which is faster must always be
determined by running some sort of benchmark, not by theoretical
speculation. Rule number 1 of optimization is "never assume".
The fact that 32-bit x86 is sometimes faster is the reason why things
like x86-32
On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel
<fpc-devel@lists.freepascal.org> wrote:
A bug report with steps to reproduce would probably be nice.
That limit is a fundamental hardware limitation, not a bug.
We claim it's virtually impossible to exceed it in practice and we don't
support a native win64 compiler, therefore it's a bug, if it's
impossible to compile something with the 32-bit crosscompiler.
Not at all hard to imagine someone encountering it on 32-bit
particularly if they're using Lazbuild for multi-threaded compilation.
Imagining something is one thing, whether it's possible to occur in
practice is another.
Why would it matter whether you use lazbuild with multi-threaded
compilation? Doesn't lazbuild start separate compiler processes? Every
32-bit process gets a separate 4GB address space (meaning that each
process has a different set of page tables, thus a different mapping of
linear to physical memory addresses, this is a memory protection
mechanism, that ensures that one process isn't able to destroy the
memory of another process). In 64-bit operating systems (as well as
32-bit, that use PAE, that is Physical Address Extension), each such set
of page tables can map 32-bit linear memory pages to physical memory
beyond the 4GB limit (with PAE it's a 32-bit to 36-bit mapping, in long
mode it's a 32-bit to 64-bit mapping), therefore running multiple 32-bit
processes at the same time can access more than 4GB in total, even
though each process is limited to 4GB.
Nikolay
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
