From: Nick Maclaren on

In article <50149c47-4667-4f9c-b933-4c6181e9208b(a)o1g2000pra.googlegroups.com>,
David Kanter <dkanter(a)gmail.com> writes:
|>
|> Nick - I provided you a link to a paper that very clearly articulated
|> why SMT and SOEMT on a scalar (or single issue for the terminology
|> impaired) CPU are the same.

I do not remember that, but I have lost track of the number of
semi-technical Web pages you have pointed me at. In every case that
I can remember, I have had to deduce what the authors meant by the
terms they used from the way they used them. And, PLEASE NOTE, that
I said "what the authors meant by the terms they used", not "what
the terms they used meant".

Distinguish that from something published by a serious academic like
Eggers, who at least describes clearly what she means by her terms.

|> > Many mainframes (IBM 370s among them) had several hardware contexts,
|> > and switched between them on certain classes of event. Were THEY
|> > also SMT? If not, WHY not?
|>
|> Nick, someone already explained that to you, to quote bill todd's
|> post:
|>
|> "SoeMT is a mechanism that
|> supports multiple *hardware* thread contexts within a *single core*
|> aimed at keeping *that core* busy rather than idling it while a single
|> thread is waiting for a memory access. Thread-switch-on-page-miss is
|> a mechanism that supports multiple *software* thread contexts within
|> the *operating system* aimed at keeping the *system* busy rather than
|> idling it while a single thread is waiting for a disk access.

You really DON'T understand, do you? I am not and have NEVER been
talking the incredibly restrictive domain of a small handful of current
chip implementations, but about the METHODOLOGY. And I wasn't talking
about just page misses, incidentally - think about FPU/vector pipelines
for something that matches that description precisely.

Saying that two functionally identical methodologies should be called
by different names because they are intended for different purposes
makes no mathematical or engineering sense.

I also find it bizarre that you distinguish the cases of having more
hardware contexts than cores, with the intention of keeping the cores
busy, according to whether the hardware contexts are "within the
cores" or not. What DO you mean by "within the cores" in that case?


For the Nth time, I am NOT interested in arguing about terminology,
and who "owns" the right to define it, because I have the experience
and expertise to know how much its meaning varies with domain and over
time. Almost ALL of my postings about about METHODOLOGY, which is
supposed to be one of the things this newsgroup is for.

Dammit, even the term "threads" is used with WILDLY different meanings
in the SAME context by different people! You doubtless won't remember
the incredible flame wars of 20 years back over the terms "task",
"process" and "thread", but I do :-(


Regards,
Nick Maclaren.
First  |  Prev  | 
Pages: 1 2
Prev: Testing Flash Memory Question
Next: Intel Atom vs ARM