<story><title>Go GC: Solving the Latency Problem in Go 1.5</title><url>https://sourcegraph.com/blog/live/gophercon2015/123574706480</url></story><parent_chain><item><author>alexbock</author><text>&amp;gt; ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn...&lt;p&gt;This is the exact opposite of the experience I&amp;#x27;ve had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstraction or poorly written code until it runs at the same speed that old code ran on the old CPU. I&amp;#x27;m impressed that hardware designers and compiler authors can do their jobs well enough to make this sort of bloated software (e.g. multiple gigabytes for a word processor or image editor) succeed in spite of itself.&lt;p&gt;There are of course CPU advancements that make a huge performance difference when used properly (e.g. SSE, multiple cores in consumer machines) and some applications will use them to great effect, but these seem to be few and far between.</text></item></parent_chain><comment><author>jerf</author><text>It&amp;#x27;s probably fair to call that a reasonable characterization of the Go&amp;#x27;s &amp;quot;home problem domain&amp;quot;, though. Contrary to popular belief that &amp;quot;cloud&amp;quot; means you can just write crappy code and throw cheap hardware at it, when you are truly working at cloud scale you actually try to write software as lean and mean as possible, because everybody cares about 10x and 100x differences in the amount of hardware that a particular cloud service takes.&lt;p&gt;Yes, desktops continue to be gluttonous hogs, because you&amp;#x27;d rather have your software now than glorious software three years from now (which you can&amp;#x27;t have anyhow because the company went out of business trying to polish it instead of releasing it). Lately &amp;quot;mobile&amp;quot; is really pushing it, I think. But in Go&amp;#x27;s wheelhouse, efficiency has actually manifested.&lt;p&gt;I&amp;#x27;ve often thought that the there is less difference than you&amp;#x27;d think between embedded programming and cloud programming; both groups of programmers may literally be counting cycles and watching their L1 caches. It&amp;#x27;s those in the middle who have more power sitting around than they know what to do with who can afford to be a bit &amp;quot;lazy&amp;quot;.</text></comment>
<story><title>Go GC: Solving the Latency Problem in Go 1.5</title><url>https://sourcegraph.com/blog/live/gophercon2015/123574706480</url></story><parent_chain><item><author>alexbock</author><text>&amp;gt; ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn...&lt;p&gt;This is the exact opposite of the experience I&amp;#x27;ve had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstraction or poorly written code until it runs at the same speed that old code ran on the old CPU. I&amp;#x27;m impressed that hardware designers and compiler authors can do their jobs well enough to make this sort of bloated software (e.g. multiple gigabytes for a word processor or image editor) succeed in spite of itself.&lt;p&gt;There are of course CPU advancements that make a huge performance difference when used properly (e.g. SSE, multiple cores in consumer machines) and some applications will use them to great effect, but these seem to be few and far between.</text></item></parent_chain><comment><author>Retra</author><text>It&amp;#x27;s just far easier to write bloated software than it is to write efficient software. Particularly in the &amp;quot;just get it done&amp;quot; atmosphere most programmers operate under.</text></comment>