[fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC website for the next release?

[Nikolay Nikolov]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220113/c7c4455a/attachment.htm>