|
Prev: Testing Flash Memory Question
Next: Intel Atom vs ARM
From: Nick Maclaren on 5 Apr 2008 06:53 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. |