<story><title>Single-chip processors have reached their limits</title><url>https://spectrum.ieee.org/single-chip-processors-have-reached-their-limits</url></story><parent_chain><item><author>bob1029</author><text>Despite the limitations apparently present in single chip&amp;#x2F;CPU systems, they can still provide an insane amount of performance if used properly.&lt;p&gt;There are also many problems that are literally impossible to make faster or more correct than by simply running them on a single thread&amp;#x2F;processor&amp;#x2F;core&amp;#x2F;etc. There always will be forever and ever. This is not a &amp;quot;we lack the innovation&amp;quot; problem. It&amp;#x27;s an information-theoretic &amp;#x2F; causality problem you can demonstrate with actual math &amp;amp; physics. Does a future event&amp;#x27;s processing circumstances maybe depend on all events received up until now? If yes, congratulations. You now have a total ordering problem just like pretty much everyone else. Yes, you can cheat and say &amp;quot;well these pieces here and here dont have a hard dependency on each other&amp;quot;, but its incredibly hard to get this shit right if you decide to go down that path.&lt;p&gt;The most fundamental demon present in any distributed system is latency. The difference between L1 and a network hop in the same datacenter can add up very quickly.&lt;p&gt;Again, for many classes of problems, there is simply no handwaving this away. You either wait the requisite # of microseconds for the synchronous ack to come back, or you hope your business doesnt care if john doe gets duplicated a few times in the database on a totally random basis.</text></item></parent_chain><comment><author>tgamblin</author><text>All of this is true, but I’ll just be nitpicky to make a point:&lt;p&gt;&amp;gt; Does a future event&amp;#x27;s processing circumstances maybe depend on all events received up until now?&lt;p&gt;In a parallel prefix sum, the final sum does depend on all prior inputs, but a good parallel implementation runs in O(log(n)) time. It is, of course, not a total ordering problem, but that’s not obvious at first glance — I’ve always thought it was a beautiful example of something that &lt;i&gt;appears&lt;/i&gt; to be entirely sequential but actually parallelizes really well.&lt;p&gt;All of which is to say that, yeah, we’re latency bound at the end of the day, but there’s a lot more innovation and performance left to be wrung out of most systems. A little creativity goes a long way, and I like the idea of a universe where the software is the main determinant of performance — where you can’t get away with just waiting for the next generation of chips.</text></comment>
<story><title>Single-chip processors have reached their limits</title><url>https://spectrum.ieee.org/single-chip-processors-have-reached-their-limits</url></story><parent_chain><item><author>bob1029</author><text>Despite the limitations apparently present in single chip&amp;#x2F;CPU systems, they can still provide an insane amount of performance if used properly.&lt;p&gt;There are also many problems that are literally impossible to make faster or more correct than by simply running them on a single thread&amp;#x2F;processor&amp;#x2F;core&amp;#x2F;etc. There always will be forever and ever. This is not a &amp;quot;we lack the innovation&amp;quot; problem. It&amp;#x27;s an information-theoretic &amp;#x2F; causality problem you can demonstrate with actual math &amp;amp; physics. Does a future event&amp;#x27;s processing circumstances maybe depend on all events received up until now? If yes, congratulations. You now have a total ordering problem just like pretty much everyone else. Yes, you can cheat and say &amp;quot;well these pieces here and here dont have a hard dependency on each other&amp;quot;, but its incredibly hard to get this shit right if you decide to go down that path.&lt;p&gt;The most fundamental demon present in any distributed system is latency. The difference between L1 and a network hop in the same datacenter can add up very quickly.&lt;p&gt;Again, for many classes of problems, there is simply no handwaving this away. You either wait the requisite # of microseconds for the synchronous ack to come back, or you hope your business doesnt care if john doe gets duplicated a few times in the database on a totally random basis.</text></item></parent_chain><comment><author>AnthonyMouse</author><text>The alternative is speculative execution. If you can guess what the result is going to be, you can proceed to the next calculation and you get there faster if it turns out you were right.&lt;p&gt;If you have parallel processors, you can stop guessing and just proceed under both assumptions concurrently and throw out the result that was wrong when you find out which one it was. This is going to be less efficient, but if your only concern is &amp;quot;make latency go down,&amp;quot; it can beat waiting for the result or guessing wrong.</text></comment>