OK, the answer is of course hardware.<div>The illusion, as it's called, of running</div><div>more than one program at a time started</div><div>with the time slice, which is as old as </div><div>Unix itself.  And even that might not have</div>
<div>been cut from whole cloth.  Context switching</div><div>is necessary in order to suspend a process,</div><div>which your piece says is modernese for </div><div>program. That function is as old as </div><div>interrupts, and there is perhaps a connection</div>
<div>between interrupts and time slicing, where</div><div>the "interrupt" is a signal saying a time</div><div>slice has run out of time.</div><div><br></div><div>Anyway,  it gets back to the notion of </div><div>
keeping as many balls in the air at the </div><div>same time.  Modern processors can</div><div>run more than one thread at the same</div><div>time, but that might be a way of saying</div><div>one has more than one processor in</div>
<div>the same core.  One still cannot get</div><div>around the basic limitations of branches,</div><div>and the other kinds of hardware management</div><div>that a CPU has always had to do.  The </div><div>CDC 6600 had a dozen or so satellite </div>
<div>processors for doing arithmetic processing.</div><div>The problem was still management.</div><div><br></div><div>The lingo changes, but apparently not</div><div>the problems very much.  Let me ask </div><div>how much threading speeds things up</div>
<div>in practice?  Sun Microsystems used</div><div>"lightweight threads," or "lightweight </div><div>processes" 20 or more years ago. More</div><div>fine grained control.  I suspect the </div><div>concepts have made their way in to</div>
<div>some hardware today.  Something like</div><div>the 35 year old notion of a math</div><div>coprocessor - e.g., the old 80287.</div><div>Eventually that all made its way on to</div><div>the CPU, but it's more integration than</div>
<div>evolution. </div><div><br></div><div>IMHO anyway.</div><div><br></div><div>   -- Bob</div><div><br></div><div><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 3:22 PM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Sep 22, 2011 at 3:16 PM, Bob Kline <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>> wrote:<br>

> Is hyperthreading more of a hardware<br>
> function or a software?  The thing that<br>
> often kills speedup is branching.  If you<br>
> can keep a long sequence of computations<br>
> going, you get speedup, but that doesn't<br>
> always work out in practice either.<br>
> What role do compilers have here, if any?<br>
>    -- Bob<br>
<br>
</div><a href="http://web.archive.org/web/20030811130623/http://arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html" target="_blank">http://web.archive.org/web/20030811130623/http://arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html</a><br>

<font color="#888888">--<br>
:wq<br>
</font><div><div></div><div class="h5"><br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a></div></div></blockquote></div><br></div>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.