[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 16:33, Nikolay Nikolov wrote:
>
>
> 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".
>
Ok, I did some testing in Windows 10 21H2 and the 32-bit crosscompiler 
was faster. I tested compiling lazarus for win64 from lazarus git, using 
FPC 3.2.2. The crosscompiler is the one that we ship, the native 
compiler is the one that is shipped with lazarus 2.2.0 for win64. I did 
not use multithreaded compilation, because "make -j24" didn't work with 
lazarus. Maybe the lazarus makefiles don't support that and I should use 
lazbuild, but I don't know how. I tested "make all", not "make bigide". 
Both the FPC 3.2.2 crosscompiler and the native compiler were on an SSD, 
on an NTFS filesystem, with NTFS compression enabled. The lazarus 
sources that I compiled were on a HDD (no space on my windows SSD 
partition, sorry), but I have 128GB RAM, most of which are free and used 
by Windows as cache. I did several runs and discarded the first result, 
to avoid the effect of HDD files not being in the cache. Before each 
run, I cleaned up with right click->TortoiseGit->Clean up...->Clean Type 
= "Remove all untracked files (-fx)"; + "Remove untracked directories 
(-d)". This was followed by emptying the recycle bin. I have the default 
Microsoft antivirus program Windows Defender installed and fully 
updated. I tested both with antivirus real-time protection enabled and 
disabled. All measurements were made using "Measure-Command" in 
PowerShell. Here are the best results for each case:

antivirus off:

ppcrossx64: 83.8517351 seconds

ppcx64: 85.0845576 seconds

with antivirus on there's a huge variance of speeds:

ppcrossx64: 90.3048706 seconds - 95.4332713 seconds

ppcx64: 86.8207751 seconds - 99.2315772 seconds.

There were some ppcx64 runs that were slightly faster with antivirus on, 
but there were also slower and they didn't converge to a single value 
after several runs, but retained their random variance. But with the 
antivirus off, the crosscompiler was clearly faster.

Any suggestions for testing multithreaded compilation of lazarus are 
welcome. I'll be happy to test that as well.

Nikolay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220113/c23abf4e/attachment.htm>