<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>For that very reason, I put an upper limit of 2,048 on the jump table size (which results in an 8 KiB table), although it was modified later so this bound doesn't apply if every single label points to a single value and more or less forms a continuum (e.g, you have 2,500 labels and none of them are a range).<br>
<div><br>
</div><div>For a linear search, each branch takes between 2 and 4 instructions to test, if I remember correctly, although there is a lot of dependency, since it usually involves a subtraction followed by a conditional jump. My additional changes over at #34859 introduce some extra conditional jumps to break out sooner once the program knows there won't be a match (because, for example, there are labels for just 1 and 3 and the input value is 2). Before, the flow only jumped out if it reached a range and the input was less than the lower bound. I did some preliminary testing with tests/bench/bcase.pp and the overall timespan is about 5% faster.<br>
<br>
Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Tue 15/01/19 17:27 , Martok listbox@martoks-place.de sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Am 14.01.2019 um 15:01 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> Martok mentioned doing some checks differently in the bug report in question,
</span><br>
<span style="color: rgb(102, 102, 102);">> such as 6 comparisons being faster than a jump table. Are there any others
</span><br>
<span style="color: rgb(102, 102, 102);">> worth mentioning?
</span><br>
Not neccessarily faster, but in that code definitely smaller. Is there a way to
<br>
directly estimate how large the generated code might be, maybe something like
<br>
"numlabels*constant"?
<br>
<br>
For the "faster" question, the cache line occupation matters more than
<br>
instruction throughput. If your jumptable gets large enough to force a full data
<br>
cache line flush, you could have done a lot of instructions in the time the CPU
<br>
waits for the data. And I haven't found reliable information how the
<br>
Spectre-related microcode updates changed that, given that both cmp/jmp and
<br>
jmp[indirect] used to be heavily optimized, but were both affected.
<br>
<br>
<br>
--
<br>
Regards,
<br>
Martok
<br>
<br>
<br>
_______________________________________________
<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>
<br>
</blockquote></HTML>