Re: Hyperthreading on 2.4.18 and 2.4.20 (Redhat)

From: Stephen SM WONG (wongsm_at_netvigator.com)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 09:50:52 +0800

Yeah, Hyperthread is just such an exotic idea! In order to
minimize dependent instructions in a single thread and make
a stall on the pipeline / waste of executable units, just
run 2 threads in parallel, and hopefully to fill those
pipeline stages. But there are a lot of different
situations, your mentioned contention of CPU registers and
cache lines are real. Intel should really think about other
ways to improve execution speed instead of make longer and
longer pipelines!

Keep on to try your setting on 2.6 kernel, and let us know
your results. But I don't think the speed degradation on
single thread is too much dependent on the scheduler. The
task scheduler is too high level in determining which 2
processes will not contend on CPU registers and/or cache
line.

My 2 cents.

Stephen Wong @ Hong Kong.

On Thu, 18 Mar 2004, General Schvantzkoph wrote:

> On Thu, 18 Mar 2004 16:00:24 +0800, Stephen SM WONG wrote:
>
> > Interesting, but since you will not have (physical)
> > processor affinity in hyperthreading situation, you might
> > run into the case that only one (physical) processor is
> > running 2 tasks on 2 hyperthreaded virtual processors, and
> > hence you saw the slow down.
> >
> > My 2 cents.
> >
> > Stephen Wong @ Hong Kong.
> >
>
> It's certainly worth trying the same experiment with the 2.6.x kernel,
> rumor has it that the 2.6 kernel has a better scheduler. However the
> reason to believe that the individual thread performance will still suffer
> significantly is that when the P4 is operating in hyperthreaded mode the
> number of physical registers assigned to each thread reduced by 1/2. Also
> the cache is shared between both threads so the cache is going to thrash.
>
>
>

Relevant Pages

  • Re: Hyperthreading on 2.4.18 and 2.4.20 (Redhat)
    ... Hyperthread is just such an exotic idea! ... a stall on the pipeline / waste of executable units, ... cache lines are real. ... single thread is too much dependent on the scheduler. ...
    (alt.os.linux)
  • Re: Hyperthreading on 2.4.18 and 2.4.20 (Redhat)
    ... Hyperthread is just such an exotic idea! ... a stall on the pipeline / waste of executable units, ... cache lines are real. ... single thread is too much dependent on the scheduler. ...
    (comp.os.linux.hardware)
  • Re: Hyperthreading on 2.4.18 and 2.4.20 (Redhat)
    ... Hyperthread is just such an exotic idea! ... a stall on the pipeline / waste of executable units, ... cache lines are real. ... single thread is too much dependent on the scheduler. ...
    (comp.os.linux)
  • Re: Big OOO, SpMT, and possible designs (Was Re: Free/Open x86 Sim)
    ... whose execution is delayed because of memory". ... Do the same thing for memory operations, especially cache misses - 0 latency, infinite bandwidth - and you get a much better result. ... Especially if you handle branch mispredictions - in such an idealized model, should branch mispredictions cost 0 cycles or N cycles, where N is the pipeline depth (in which case you get good, but not great, speedups, if you have a pipeline. ...
    (comp.arch)
  • Re: ARM926 caching question
    ... caching devices are single cycle. ... On GHz+ processors a L1 cache hit ... pipeline and may cause stalls. ... There are two ways to make sure your cached data gets there on time - start fetching it at an earlier clock cycle, or use a faster cache design. ...
    (comp.arch.embedded)