https://dirtyhandscoding.github.io/posts/performance-comparison-linear-search-vs-binary-search.html/2021-08-11T13:12:00+02:002021-08-11T13:12:00+02:002021-08-11T13:12:00+02:00Touisteurtag:dirtyhandscoding.github.io,2021-08-11:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-13md<p>Thanks for the link!</p>2021-08-11T11:26:00+07:002021-08-11T11:26:00+07:00dirtyhandscodingtag:dirtyhandscoding.github.io,2021-08-11:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-12md<p>Yes, indeed it can be used to compute order statistics.</p> <p>For instance, see it <a href="https://stackoverflow.com/questions/33307957/calling-stdnth-element-function-extremely-frequently/33325864#33325864">applied to median of 23 elements</a>.</p>2021-08-11T00:45:00+02:002021-08-11T00:45:00+02:00Touisteurtag:dirtyhandscoding.github.io,2021-08-11:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-11md

<p>Hi, I'm wondering whether this technique could be used for selection tasks. Like 'find the N-th-biggest (or -smallest) element of a small (up to 64-elements) unsorted array' without sorting/moving the original data.</p> <p>For each <code>a[i]</code> of the array <code>a[64]</code> count (from 0 to 63) the number of …</p>

<p>Hi, I'm wondering whether this technique could be used for selection tasks. Like 'find the N-th-biggest (or -smallest) element of a small (up to 64-elements) unsorted array' without sorting/moving the original data.</p> <p>For each <code>a[i]</code> of the array <code>a[64]</code> count (from 0 to 63) the number of elements bigger (or smaller) than <code>a[i]</code>. Then locate the one with value N with some other magic...</p> <p>Very, very insightful and inspiring.. Thanks!</p>2019-05-15T10:06:00+07:002019-05-15T10:06:00+07:00RyanBtag:dirtyhandscoding.github.io,2019-05-15:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-10md

<p>I came up with a little trick that seems to be 33% faster on my machine, for my use case (and it doesn’t require sorting): In linear_search_scalar(), replace <code>arr[i] &lt; key</code> with <code>(arr[i] == key) * i</code>. Presumably, this allows the loop to just do one non-trivial addition operation (or …</p>

<p>I came up with a little trick that seems to be 33% faster on my machine, for my use case (and it doesn’t require sorting): In linear_search_scalar(), replace <code>arr[i] &lt; key</code> with <code>(arr[i] == key) * i</code>. Presumably, this allows the loop to just do one non-trivial addition operation (or none if the item isn't to be found) instead of multiple. Give it a try!</p>2018-11-14T06:23:00+07:002018-11-14T06:23:00+07:00Dr. Khalid Omar Thabittag:dirtyhandscoding.github.io,2018-11-14:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-9md<p>If prefetch instruction was used with the AVX2 in linear search it would even improve the speed.</p>2018-04-01T02:35:00+07:002018-04-01T02:35:00+07:00Krishtytag:dirtyhandscoding.github.io,2018-04-01:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-8md<p>Thanks! I'm glad to hear they listened to your suggestion. Keep up the good work!</p>2018-03-30T23:00:00+07:002018-03-30T23:00:00+07:00dirtyhandscodingtag:dirtyhandscoding.github.io,2018-03-30:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-7md<p>Yes, I suggested this change, and it got included into MSVC 15.6 =)</p> <p>I wrote about it in <a href="/../../posts/addendum-to-performance-comparison-linear-search-vs-binary-search.html">the addendum</a>.</p> <p>Rerunning tests is not necessary: the revised results include a pretty good workaround.</p>2018-03-30T17:01:00+07:002018-03-30T17:01:00+07:00Krishtytag:dirtyhandscoding.github.io,2018-03-30:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-6md<p>FYI: Since the recent Visual Studio 15.6 update, Visual C++ has started to emit <code>MOV -1</code> instead of <code>OR -1</code> (if compiled for speed).</p> <p>Your article must have had some impact. Maybe you want to re-run your tests?</p>2017-09-12T23:04:00+07:002017-09-12T23:04:00+07:00dirtyhandscodingtag:dirtyhandscoding.github.io,2017-09-12:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-5md

<p>What I mean is: "the number returned by this code would be the same no matter how you shuffle the input array". Indeed, it does not necessarily mean that this number would be useful for a non-sorted array.</p> <p>In your case the answer would be 2 regardless of the order …</p>

<p>What I mean is: "the number returned by this code would be the same no matter how you shuffle the input array". Indeed, it does not necessarily mean that this number would be useful for a non-sorted array.</p> <p>In your case the answer would be 2 regardless of the order of elements.</p>2017-09-12T21:34:00+07:002017-09-12T21:34:00+07:00A Readertag:dirtyhandscoding.github.io,2017-09-12:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-4md

<p>I have a question about "In fact, this criterion would work the same way even if you shuffle the input array randomly"</p> <p>If my array is <code>[10, 2, 1]</code> and my key is 10, then the number of elements smaller than the key is 2, but this is not the …</p>

<p>I have a question about "In fact, this criterion would work the same way even if you shuffle the input array randomly"</p> <p>If my array is <code>[10, 2, 1]</code> and my key is 10, then the number of elements smaller than the key is 2, but this is not the index of the key. Am I missing something? The way I see it, is that this counting search requires a sorted array.</p>2017-08-26T19:06:00+07:002017-08-26T19:06:00+07:00dirtyhandscodingtag:dirtyhandscoding.github.io,2017-08-26:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-3md

<p>Yes, this is the official way of using IACA under MSVC x64. However, when you use <code>IACA_VC64_START</code>, you cannot guarantee that the marker would get exactly at the beginning of the loop in assembly (same issue for end marker), compiler can and does move it around freely. Maybe 32-bit case …</p>

<p>Yes, this is the official way of using IACA under MSVC x64. However, when you use <code>IACA_VC64_START</code>, you cannot guarantee that the marker would get exactly at the beginning of the loop in assembly (same issue for end marker), compiler can and does move it around freely. Maybe 32-bit case also has this problem...</p> <p>When you have a small loop and compiler moves marker away, you get quite different analysis. Moreover, sometimes inter-iteration dependencies are completely incorrect because a few first instructions of the loop are missing from the analysed section of assembly.</p> <p>I used these macros myself in the past. Now I know reliable way of setting the markers exactly where I want, so I’m done with the macros.</p>2017-08-26T18:16:00+07:002017-08-26T18:16:00+07:00optimizedawaytag:dirtyhandscoding.github.io,2017-08-26:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-2md<p>IACA runs just fine for 64 bit exes, use <code>IACA_VC64_START</code>, <code>IACA_V64_END</code> defines and <code>-64</code> command line arg i.e. <code>iaca -64 -arch HSW MyProgram.exe</code></p>2017-08-25T23:44:00+07:002017-08-25T23:44:00+07:00demofox2tag:dirtyhandscoding.github.io,2017-08-25:/posts/performance-comparison-linear-search-vs-binary-search.html//comment-1md<p>Nice analysis. Interesting stuff!</p>