<HTML>
<a name="bugnotes" id="bugnotes">Got some new timing metrics for
compiling Lazarus under Windows. I haven't got them for Linux because I
only have it on a virtual machine, which significantly skews the
performance:<br>
<br>
----<br>
<br>
-O3: Trunk<br>
<br>
[125.383] 1285571 lines compiled, 125.4 sec, 9137600 bytes code, 788740 bytes data<br>
[122.078] 1285571 lines compiled, 122.1 sec, 9137600 bytes code, 788740 bytes data<br>
[119.125] 1285571 lines compiled, 119.1 sec, 9137600 bytes code, 788740 bytes data<br>
<br>
Avg. 122.195 sec. Binary size = 19,325,952 bytes<br>
<br>
-O3: Overhaul<br>
<br>
[103.133] 1285571 lines compiled, 103.1 sec, 9133968 bytes code, 788740 bytes data<br>
[105.234] 1285571 lines compiled, 105.2 sec, 9133968 bytes code, 788740 bytes data<br>
[104.906] 1285571 lines compiled, 104.9 sec, 9133968 bytes code, 788740 bytes data<br>
<br>
Avg. 104.424 sec. Binary size = 19,322,368 bytes<br>
<br>
Time improvement: 14.5%<br>
Size improvement: 0.0185%<br>
<br>
----<br>
<br>
-O2: Trunk<br>
<br>
[118.852] 1285571 lines compiled, 118.9 sec, 9103760 bytes code, 788996 bytes data<br>
[120.266] 1285571 lines compiled, 120.3 sec, 9103760 bytes code, 788996 bytes data<br>
[116.531] 1285571 lines compiled, 116.5 sec, 9103760 bytes code, 788996 bytes data<br>
<br>
Avg. 118.550 sec. Binary size = 19,292,672 bytes<br>
<br>
-O2: Overhaul<br>
<br>
[100.875] 1285571 lines compiled, 100.9 sec, 9100096 bytes code, 788996 bytes data<br>
[100.922] 1285571 lines compiled, 100.9 sec, 9100096 bytes code, 788996 bytes data<br>
[101.813] 1285571 lines compiled, 101.8 sec, 9100096 bytes code, 788996 bytes data<br>
<br>
Avg. 101.203 sec. Binary size = 19,289,088 bytes <br>
<br>
Time improvement: 14.6%<br>
Size improvement: 0.0186%<br>
<br>
----<br>
<br>
-O1: Trunk<br>
<br>
[114.641] 1285571 lines compiled, 114.6 sec, 10196576 bytes code, 788996 bytes data<br>
[112.734] 1285571 lines compiled, 112.7 sec, 10196576 bytes code, 788996 bytes data<br>
[113.516] 1285571 lines compiled, 113.5 sec, 10196576 bytes code, 788996 bytes data<br>
<br>
Avg. 113.630 sec. Binary size = 20,370,432 bytes<br>
<br>
-O1: Overhaul<br>
<br>
[99.711] 1285571 lines compiled, 99.7 sec, 10193536 bytes code, 788996 bytes data<br>
[102.375] 1285571 lines compiled, 102.4 sec, 10193536 bytes code, 788996 bytes data<br>
[102.211] 1285571 lines compiled, 102.2 sec, 10193536 bytes code, 788996 bytes data<br>
<br>
Avg. 101.432 sec. Binary size = 20,370,360 bytes<br>
<br>
Time improvement: 10.7%<br>
Size improvement: 0.000353%<br>
<br>
----<br>
<br>
Note there are no actual new optimisations, so to speak. The size
improvements come from more intelligent elimination of dead labels and
the removal of unnecessary alignment hints, which allows some new branch
optimisations to be found. </a><br>
<br>
<div>One thing that is a little bit mysterious and might warrant further investigation... the binary size is larger on O3 than it is for O2 on both the trunk and the overhaul patches. It might be that some of the optimisations sacrifice code size for speed, but over 3 kilobytes feels rather significant. I may be wrong though.</div><div><br>
</div><div>Does anyone have other test projects to compile that would give more coverage for the timing metrics?<br>
</div> <div><br>
</div><div>Gareth aka. Kit</div><div><br>
</div><br>
<span style="font-weight: bold;">On Thu 06/12/18 15:55 , "J. Gareth Moreton" gareth@moreton-family.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
I believed I've fixed the bug. Thanks for your help.<br>
<br>
I had misunderstood one of the internal methods and, as a result, it wasn't resetting the register allocation usage with each iteration of the loop (and to add insult to injury, caused a memory leak!). By sheer coincidence, this wasn't a problem under Windows because of some additional code that skipped over the function prologue, but got triggered under Linux.<br>
<br>
I've updated all of the patch files in the bug report and added an additional one, since one function in particular got a bigger rework than everything else (overhaul-mov-refactor).<br>
<br>
I haven't had a chance to re-test the timings yet, although I've tried to provide a couple of additional savings for -O1 and -O2.<br>
<br>
<div>Gareth aka. Kit<br>
<br>
P.S. Note that the code is very messy with functions being split between i386 and x86_64. This is for testing and control cases. If x86_64 is successful, I intend to remove the distinctions and have i386 and x86_64 share the same overhaul. One platform at a time though!<br>
</div><div><br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sun 02/12/18 23:21 , "Marģers ." margers.roked@inbox.lv sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"><div id="eml-cke__body" title="">I run it no linux. Problem code part.<br>
<br>
type PLongData = ^TLongData;<br>
TLongData = array [0..100] of longint;<br>
<br>
function binarySearchLong ( sortedArray:PLongData; nLen, toFind:longint):longint;<br>
var low, high, mid, l, h, m : longint;<br>
begin<br>
{ Returns index of toFind in sortedArray, or -1 if not found}<br>
low := 0;<br>
high := nLen - 1;<br>
<br>
l := sortedArray^[low];<br>
h := sortedArray^[high];<br>
<br>
while ((l <= toFind) and (h >= toFind)) do<br>
begin<br>
mid := (low + high) shr 1; { var "low" in register r8d }<br>
m := sortedArray^[mid];<br>
<br>
if (m < toFind) then<br>
begin<br>
low := mid + 1;<br>
l := sortedArray^[low];<br>
<br>
{ asm code generated<br>
-- with trunk<br>
lea r8d, [r11d+1H] <br>
mov esi, r8d<br>
--end trunk<br>
-- with overhaul it never set r8d to new value, but should<br>
lea esi, [r11d+1H] <br>
-- end overhaul<br>
<br>
mov r10d, dword [rdi+rsi*4] <br>
jmp ?_00144 <br>
<br>
}<br>
end else<br>
if (m > toFind) then<br>
begin<br>
high := mid - 1;<br>
h := sortedArray^[high];<br>
end else<br>
begin<br>
binarySearchLong:=mid;<br>
exit;<br>
end;<br>
<br>
end;<br>
<br>
if (sortedArray^[low] = toFind) then<br>
begin<br>
binarySearchLong:=low;<br>
end else<br>
binarySearchLong := -1; { Not found}<br>
end;<br>
<br>
</div>
<div id="eml-cke__signature_top" title="Paraksts">
<div class="eml-cke__signature" id="eml-cke__signature_top-wrap" title=""> </div>
</div>
<div class="noTransl">----- Reply to message -----<br>
<span style="font-weight: bold;">Subject: </span>Re: [fpc-devel] x86_64 Optimizer Overhaul<br>
<span style="font-weight: bold;">Date: </span>2018. gada 2. decembris 23:32:36<br>
<span style="font-weight: bold;">From: </span> J. Gareth Moreton <a href="javascript:top.opencompose(" target="_blank" gareth@moreton-family.com','','','')"=""><gareth@moreton-family.com></gareth@moreton-family.com></a><br>
<span style="font-weight: bold;">To: </span> FPC developers' list <a href="javascript:top.opencompose(" target="_blank" fpc-devel@lists.freepascal.org','','','')"=""><fpc-devel@lists.freepascal.org></fpc-devel@lists.freepascal.org></a></div>
<blockquote>Thanks for the feedback. Do you have a reproducible case, and does it fail on Linux or Windows? I'll have a look for the infinite loops in the meantime.
<div> </div>
<div>Gareth aka. Kit</div>
<blockquote>
<div> </div>
</blockquote>
</blockquote>
<div id="eml-cke__signature_bottom" title="Paraksts"> </div>
</blockquote>
_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>
<br>
</blockquote></HTML>