<br><br>On Tuesday, May 25, 2021, Jacob Lifshay &lt;<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div></div><div dir="auto"><div dir="auto" style="font-family:sans-serif"><div dir="auto"><div dir="auto"><div dir="auto"><div dir="auto"><div dir="auto"><div dir="auto">RISC-V has an architectural forward-progress guarantee for the equivalent loop, suggesting that a cpu implementation prevents live-lock by blocking other cpus from taking the cache block associated with a reservation for a few cycles (enough for at least 16 simple integer instructions), giving the cpu enough time to get to the store-conditional and successfully store.</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>they call it &quot;constraints&quot;.</div><div><br></div><div>the RV spec states that anything that falls outside of these constraints *requires* a counter on the loop, to avoid live-lock.  that in turn introduces inefficiency (additional instructions inside the critical loop).</div><div><br></div><div>as a Hybrid GPU, dealing with Vulkan Shader data, Jacob how many atomic data structure lock operations did you estimate per second?  i can&#39;t recall if you said it was 100,000 LR-SC locks per second or 1,000,000?</div><div><br></div><div>bottom line here is that live-lock or even going a few hundred times round a loop before a lock is achieved is not viable, that&#39;s thousands of cycles wasted, representing an unacceptably high percentage of CPU time compared to other standard general-purpose compute workloads.</div><div><br></div><div>the &quot;constraints&quot; as they are called, which allow for backwards-branches only, are designed to allow implementors to cut out any paths that might involve complexity: branch prediction, speculation, TLBs, illegal instruction traps, and, as Jacob says, get the job done atomically, all the way from LR to SC, on a single (2 at most) cache line exclusive lock-and-block, *guaranteeing* completion in the process, without disruption of other cores when those cache lines are locked.</div><div><br></div><div>now, there *may* have been such optimisations put into IBM POWER processors, but if there are, they didn&#39;t actually end up in the actual spec.</div><div><br></div><div>the RV spec shows, in combination with the extreme use-case of a 3D GPU (10^5 to 10^6 LRSCs per second) that these things are important.</div><div><br></div><div>l.</div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>