http://www.vr-zone.com/?i=4322

The next generation Intel processor based on the Nehalem architecture
is clearly exciting as VR-Zone has learned. Successor to quad core
Yorkfield which forms part of the 45nm Penryn architecture, Bloomfield
will come along and sit right on top of the 45nm Nehalem desktop
processors in mid 2008. Bloomfield will have 4 cores and is capable of
8 threads like the old Hyper-Threading technology but only more
advanced. Bloomfield will contain an integrated memory controller that
requires a new socket refresh called Socket B with 1366 contact pads.

lyon_wonder wrote:
> http://www.vr-zone.com/?i=4322
>
> The next generation Intel processor based on the Nehalem architecture
> is clearly exciting as VR-Zone has learned. Successor to quad core
> Yorkfield which forms part of the 45nm Penryn architecture, Bloomfield
> will come along and sit right on top of the 45nm Nehalem desktop
> processors in mid 2008. Bloomfield will have 4 cores and is capable of
> 8 threads like the old Hyper-Threading technology but only more
> advanced. Bloomfield will contain an integrated memory controller that
> requires a new socket refresh called Socket B with 1366 contact pads.

I'm guessing that this will be true hardware multithreading as opposed
to the "exploit the time between our various inefficiencies" type of
multithreading that was Hyperthreading.

Yousuf Khan

Yousuf Khan wrote:
> lyon_wonder wrote:
> I'm guessing that this will be true hardware multithreading as opposed
> to the "exploit the time between our various inefficiencies" type of
> multithreading that was Hyperthreading.

Perhaps you'd care to explain the difference between the two?

AFAIK, all multithreading relies on exploiting the time between our
various inefficiencies to improve performance...

DK

In article <(E-Mail Removed)>,
(E-Mail Removed) says...
>
> Yousuf Khan wrote:
> > lyon_wonder wrote:
> > I'm guessing that this will be true hardware multithreading as opposed
> > to the "exploit the time between our various inefficiencies" type of
> > multithreading that was Hyperthreading.
>
> Perhaps you'd care to explain the difference between the two?
>
> AFAIK, all multithreading relies on exploiting the time between our
> various inefficiencies to improve performance...

Can two threads be dispatched/completed simultaneously? Does one
thread have to wait for the other to flush? These are two
improvements on P4s implementation I can imagine.

--
Keith

krw wrote:
> In article <(E-Mail Removed)>,
> (E-Mail Removed) says...
> >
> > Yousuf Khan wrote:
> > > lyon_wonder wrote:
> > > I'm guessing that this will be true hardware multithreading as opposed
> > > to the "exploit the time between our various inefficiencies" type of
> > > multithreading that was Hyperthreading.
> >
> > Perhaps you'd care to explain the difference between the two?
> >
> > AFAIK, all multithreading relies on exploiting the time between our
> > various inefficiencies to improve performance...

> Can two threads be dispatched/completed simultaneously?

AFAIK, yes. The only hardware structures that cannot be used by both
threads simultaneously are the trace cache and decoder (see Tullsen's
PACT03 paper).

> Does one
> thread have to wait for the other to flush? These are two
> improvements on P4s implementation I can imagine.

I don't know the answer to that, however, I suspect only certain types
of flushes impact both threads. For instance, a TC flush would hit
both threads. However, flushing the ROB and RS should only impact one
thread, since they are statically partitioned.

Again, I'll ask what is this 'true' multithreading that Yousuf
mentions? The P4 uses simultaneous multithreading and it's just as
real as the POWER5/6, or the SoEMT used in Montecito, Niagara and the
older IBM systems (northstar or pulsar) and Tera's systems.
Multithreading fundamentally relies on exploiting the difference
between average IPC and peak IPC, i.e. making up for inefficiencies in
a design. Where's the beef?

DK

In article <(E-Mail Removed)>,
(E-Mail Removed) says...
>
> krw wrote:
> > In article <(E-Mail Removed)>,
> > (E-Mail Removed) says...
> > >
> > > Yousuf Khan wrote:
> > > > lyon_wonder wrote:
> > > > I'm guessing that this will be true hardware multithreading as opposed
> > > > to the "exploit the time between our various inefficiencies" type of
> > > > multithreading that was Hyperthreading.
> > >
> > > Perhaps you'd care to explain the difference between the two?
> > >
> > > AFAIK, all multithreading relies on exploiting the time between our
> > > various inefficiencies to improve performance...
>
> > Can two threads be dispatched/completed simultaneously?
>
> AFAIK, yes. The only hardware structures that cannot be used by both
> threads simultaneously are the trace cache and decoder (see Tullsen's
> PACT03 paper).
>
> > Does one
> > thread have to wait for the other to flush? These are two
> > improvements on P4s implementation I can imagine.
>
> I don't know the answer to that, however, I suspect only certain types
> of flushes impact both threads. For instance, a TC flush would hit
> both threads. However, flushing the ROB and RS should only impact one
> thread, since they are statically partitioned.
>
> Again, I'll ask what is this 'true' multithreading that Yousuf
> mentions? The P4 uses simultaneous multithreading and it's just as
> real as the POWER5/6, or the SoEMT used in Montecito, Niagara and the
> older IBM systems (northstar or pulsar) and Tera's systems.
> Multithreading fundamentally relies on exploiting the difference
> between average IPC and peak IPC, i.e. making up for inefficiencies in
> a design. Where's the beef?

The P4 cannot dispatch or complete two instructions from opposite
threads in the same cycle (I thought *star could). This may be
caused by the trace cache limitation you mention. I'm not sure
this is all that important and certainly adds complication.

--
Keith

krw wrote:

> The P4 cannot dispatch or complete two instructions from opposite
> threads in the same cycle (I thought *star could). This may be
> caused by the trace cache limitation you mention. I'm not sure
> this is all that important and certainly adds complication.

So you're claiming that the P4 SMT is not *real* because it does round
robin retirement?

Again, this discussion is in the context of Yousuf's ridiculous claim
(which I'd note he is too chicken, or unable to come out and back up).
I don't consider this evidence that hyperthreading is some sort of
half-assed or less than 'true' multithreading.

I'd also point out that by that criterion, the POWER5 is also not
*real* SMT; it can only dispatch instructions from one thread at a time
to form a group....

I guess according to Yousuf this means that the POWER5 doesn't have
*real* multithreading either.

DK

David Kanter <(E-Mail Removed)> wrote in part:
> krw wrote:
>> The P4 cannot dispatch or complete two instructions from opposite
>> threads in the same cycle (I thought *star could). This may be
>> caused by the trace cache limitation you mention. I'm not sure
>> this is all that important and certainly adds complication.
>
> So you're claiming that the P4 SMT is not *real* because
> it does round robin retirement?

Sorry to butt in, but strict RR would kill the main SMT
advantage: running another thread during the 200-300 clocks
that one is waiting for RAM fetch. RR would force all threads
to block because one couldn't retire.

This is why SMT isn't a universal win: it is highly app dependant.
If the app is reasonably optimized and doesn't suffer too many
memory stalls, there's not many scraps for a second thread.
Particularly not on a dispatch-limited arch like Pentium4.

> I'd also point out that by that criterion, the POWER5 is
> also not *real* SMT; it can only dispatch instructions from
> one thread at a time to form a group....

"Chunking" is not a problem so long as the CPU doesn't stall.

-- Robert

In article <(E-Mail Removed)>,
(E-Mail Removed) says...
> krw wrote:
>
> > The P4 cannot dispatch or complete two instructions from opposite
> > threads in the same cycle (I thought *star could). This may be
> > caused by the trace cache limitation you mention. I'm not sure
> > this is all that important and certainly adds complication.
>
> So you're claiming that the P4 SMT is not *real* because it does round
> robin retirement?

Cool your jets, Dave. Do you have to make *every* thread personal?
There is a reason I've been trying to ignore you, but I thought
this was a chance to discuss. I guess not.

It is not *I* who is claiming a DAMNED THING! No sense in
continuing...

--
Keith

David Kanter wrote:
> Again, this discussion is in the context of Yousuf's ridiculous claim
> (which I'd note he is too chicken, or unable to come out and back up).
> I don't consider this evidence that hyperthreading is some sort of
> half-assed or less than 'true' multithreading.

Whoa there buddy-boy, I'm just seeing this thread for the first time,
didn't even know there was a reply to my reply, until today. I just
don't have time to go through every thread and follow it up diligently.

Now I'll go ignore my sleep and read through this thread just to
continue this pointless debate. :-)

Yousuf Khan