From: Jan Vorbrüggen on
> The other is IDE/SATA disk queing:
>
> Even with a lot of memory, i.e. 4GB on my current laptop (of which XP-32
> can only use 3.4GB), Windows still insists on scheduling large write
> jobs to flush memory to swap disk, and if I do something that requires
> some substantial disk IO, like ISO burning, or starting/stopping a
> VMware image, all other windows can stop responding.

Oh, for the joys of the virus scanner starting its regular scan of all
files on the system! A lot of the people I know regularly kill that job
from the Task Manager when it starts. Sort of defeats the wholee purpose
of the thing, doesn't it?

To get this back on topic: design the system as a whole, not component
by component, or you'll end up with a whole that's at best semi-functional.

Jan
From: Nick Maclaren on

In article <fsvl34$l9d$1(a)s1.news.oleane.net>,
=?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <Jan.Vorbrueggen(a)not-thomson.net> writes:
|>
|> To get this back on topic: design the system as a whole, not component
|> by component, or you'll end up with a whole that's at best semi-functional.

Amen.


Regards,
Nick Maclaren.
From: David Kanter on
On Apr 1, 7:02 am, n...(a)cus.cam.ac.uk (Nick Maclaren) wrote:
> In article <36549a55-a1cc-4850-97ee-40867cb90...(a)s8g2000prg.googlegroups.com>,David Kanter <dkan...(a)gmail.com> writes:
>
> |>
> |> > Sigh. Firstly, that is wrong. The number of watts fluctuates a bit
> |> > but, even over the past decade, the trend is up.
> |>
> |> That's funny, because I'm pretty sure the TDP for Intel's chips went
> |> up to 150W and now is down to 120W and 80W for mainstream. It may
> |> rise in the future, as the northbridge is integrated, but it
> |> definitely peaked around 2005/6.
>
> The higher-wattage ones were SMT and the lower-power ones weren't,
> which rather argues against your point!

You are confusing correlation with causality. I agree that the P4 was
very power hungry and had SMT. However, I do not agree that there is
any relation between it's power consumption and SMT. In fact, SMT on
the P4 suffered from not so ideal performance due to the replay storms
it could trigger.

> |> SMT increases performance/watt, which is all I really care about.
>
> As I said, I have never seen any evidence for that claim,

OK, how about we measure the performance/watt for POWER4+ and POWER5.
Or Core 2 Duo and Nehalem?

> and I have
> seen evidence that it is the converse of the truth (Intel Netburst
> versus Core-2 being one example). I don't think that is makes any
> difference.

Notice how in my above examples I at least tried to compare:
1. Similar process technologies
2. Similar core microarchitectures

P4 versus Core 2 are radically different uarchs.

> Rather than just repeating your claim, why don't you provide evidence?

Because it should be obvious to anyone. You are simply conflating
unrelated issues (core uarch and SMT).

> |> Wrong. Sun uses a scalar pipeline with SOEMT, which is the same as
> |> SMT. See page 2 of this paper:http://www.cse.ucsd.edu/~rakumar/dasCMP05/pa=
> |> per01.pdf
>
> I got flamed in 2001 for saying that SMT was an ill-defined term, and
> asking for a precise definition. The claim was that EVERYBODY knew
> what it meant except me! Well, as I posted recently, its meaning
> seems to be expanding, and:

No. SMT is very precisely defined. Go read Joel Emer's presentations
on the topic, or read this article:
http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000

Coarse grain MT = SoEMT

If you can't tell the difference between the pictures, then I can't
really help you.

> I don't know what the CPU design of the year 2010 [ sorry, that was
> the date I meant ] will look like, but it will be called SMT :-)
>
> SOEMT is also what mainframes used to do with paging; when there was
> a page miss, they switched thread.

No, as Bill pointed out that is an OS technique, rather than a CPU
technique.

> You MIGHT be able to say that
> modern systems don't use SOEMT, because they do it in software, but
> many of the older ones did it in hardware. So, is THAT a subset of
> SMT?

No...

I agree with you that SoEMT is a fairly good idea. However, it's
clear to me that SMT is a better one. As Jim Laudon pointed out in
his paper, SMT and SoEMT are the same for single issue processors.
SMT is also very cheap if you have an OOO processor that you are
starting with. It's only in the case of in-order superscalar cores
that SoEMT could conceivably make any sense...yet IBM clearly has gone
with SMT for ALL of their in-order superscalar cores.

DK
From: David Kanter on
On Apr 1, 7:02 am, n...(a)cus.cam.ac.uk (Nick Maclaren) wrote:
> In article <36549a55-a1cc-4850-97ee-40867cb90...(a)s8g2000prg.googlegroups.com>,David Kanter <dkan...(a)gmail.com> writes:

> |> That's funny, because I'm pretty sure the TDP for Intel's chips went
> |> up to 150W and now is down to 120W and 80W for mainstream. It may
> |> rise in the future, as the northbridge is integrated, but it
> |> definitely peaked around 2005/6.
>
> The higher-wattage ones were SMT and the lower-power ones weren't,
> which rather argues against your point!

Ooops:

http://techreport.com/articles.x/14458/3

> |> Wrong. Sun uses a scalar pipeline with SOEMT, which is the same as
> |> SMT. See page 2 of this paper:http://www.cse.ucsd.edu/~rakumar/dasCMP05/pa=
> |> per01.pdf
>
> I got flamed in 2001 for saying that SMT was an ill-defined term, and
> asking for a precise definition. The claim was that EVERYBODY knew
> what it meant except me! Well, as I posted recently, its meaning
> seems to be expanding, and:
>
> I don't know what the CPU design of the year 2010 [ sorry, that was
> the date I meant ] will look like, but it will be called SMT :-)
>
> SOEMT is also what mainframes used to do with paging; when there was
> a page miss, they switched thread. You MIGHT be able to say that
> modern systems don't use SOEMT, because they do it in software, but
> many of the older ones did it in hardware. So, is THAT a subset of
> SMT?
>
> |> Intel has both SMT and SOEMT designs. And I don't think there is
> |> enough information in public on intel's plans for me to really be
> |> comfortable discussing them.
>
> Actually, there is, but you may not have found it. I haven't kept
> all of the references.

Ah, here's a good one for you:
http://techreport.com/articles.x/14458/3

That would be Intel's silverthorne design, specifically for low power,
using SMT.

DK
From: Bill Todd on
Nick Maclaren wrote:
> This is getting ridiculous, and it will probably be my last attempt to
> correct misrepresentations.

Just as well, since you don't appear to be able to differentiate them
from legitimate criticism.

I make no apologies for using capitals.
>
>
> In article <P4mdneDzj49MUG_anZ2dnUVZ_o3inZ2d(a)metrocastcablevision.com>,
> Bill Todd <billtodd(a)metrocast.net> writes:
> |> Nick Maclaren wrote:
> |> > In article <36549a55-a1cc-4850-97ee-40867cb900b0(a)s8g2000prg.googlegroups.com>,
> |> > David Kanter <dkanter(a)gmail.com> writes:
> |> > |>
> |> > |> > Sigh. Firstly, that is wrong. The number of watts fluctuates a bit
> |> > |> > but, even over the past decade, the trend is up.
> |> > |>
> |> > |> That's funny, because I'm pretty sure the TDP for Intel's chips went
> |> > |> up to 150W and now is down to 120W and 80W for mainstream. It may
> |> > |> rise in the future, as the northbridge is integrated, but it
> |> > |> definitely peaked around 2005/6.
> |> >
> |> > The higher-wattage ones were SMT and the lower-power ones weren't,
> |> > which rather argues against your point!
> |>
> |> Not at all, Nick: it simply reflects the fact that the newer,
> |> lower-power processors used significantly more efficient designs (in
> |> part due to their return to a better balance between clock-rate and ILP
> |> goals - though as things turned out clock rates didn't suffer too much
> |> after all). An apples-to-apples comparison of the kind that you're
> |> suggesting would have to compare SMT with non-SMT products using much
> |> more similar designs.
>
> Oh, for heaven's sake! Yes, of course I know that. That is PRECISELY
> why I made no claim, in that posting or elsewhere, that that difference
> showed that SMT is more power-hungry than non-SMT.

From (at least presumably) a native English speaker your comment above
can only be construed as being deliberately disingenuous. Your
observation that the fact that the SMT Netburst consumed more power than
the non-SMT Core 'argued against David's point' was either completely
incompetent (because in fact the two architectures had far more
important power-related differences than any alleged SMT effect - as you
seem to be admitting now) or did, in fact, constitute an implicit claim
that that difference showed (or at least suggested) that SMT was more
power-hungry than non-SMT.

You're sloppy in your wording and/or in your thinking, Nick: don't
expect to get a pass on either when you presume to contradict someone
whose command of both is better.

I don't believe it
> makes a damn of difference.
>
> I was SIMPLY pointing out that David Kanter's OWN example showed a
> power-hungry SMT being replaced by a less power-hungry non-SMT, which
> arues against his point.

Not unless you believe that comparing two such dissimilar architectures
has any relevance to that point, Nick. Unlike you, he didn't make a
sweeping generalization: he made a specific claim about the effect of
SMT on power efficiency, all other things presumably being kept equal
(which in the case of Netburst vs. Core they most decidedly are not).

>
> |> What David's comment *does* address is your debatable generalization
> |> about power trends, despite your attempt to change the subject. In
> |> particular, Netburst was a power-hungry anomaly reflecting marketing
> |> considerations: if you leave Netburst out of the picture your
> |> generalization might have at least some merit in the PC space (Core
> |> processors dissipating more power then Pentium III IIRC), but when
> |> Netburst is included there's a definite peak (as David observed) - plus
> |> some indication that even within just the Core/Core2 lines peak power
> |> levels may be slowly declining now.
>
> Again, for heaven's sake! I was pointing out that it addresses HIS
> debatable generalisation that SMT is a power-saving technique.

I'll say it once again, Nick: his generalization (unlike yours about
power consumption) did not implicitly span dissimilar architectures: it
was an assertion about the potential for SMT to save power other things
being equal.

>
> Firstly, READ what I said.

I read very well, Nick: you should try it yourself sometime.

I was talking about medium-term trends,
> and specifically mentioned that there were contrary fluctuations.

Fluctuations sufficient to make any solid determination of 'trend' to be
debatable at best. In fact, for multiple reasons (improving processes,
increasing concern with power & cooling costs) there's probably some
reason to suspect that for the past couple of years we've been in a
somewhat downward power trend that's likely to continue for a while
(unless AMD starts throwing the fear of God back into Intel again) - but
that as well would be difficult to state with any certainty.

....

> 1) I have never seen any decent comparisons for throughput versus
> a well-designed, highly multi-core CPU, and believe that it would do
> a lot less well than its fanatics claim.

A straw man, Nick: no one I know ever claimed that SMT could beat a lot
of small, simple cores at their own game - they just claim it can do
well enough to be competitive, while its far superior performance on
less parallelizable tasks gives it the overall win.

>
> 2) I have never seen any good evidence that it provides ANY real
> benefit in performance/watt - what evidence there is, is mixed, and
> can equally well be used to argue that it is WORSE.

Horseshit - especially if you discount the effects of turning off unused
execution units, as you claim you're willing to do.

The evidence is in the fact that a processor like POWER5 can increase
throughput by 35% - 40% for a range of commercially-significant
applications simply by enabling SMT, without increasing its power
consumption by anything like that amount. Don't babble on about how
some different approach might in some (highly parallelizable) cases be
just as efficient or even more so: the reality is that many people want
the flexibility to run unparallelizable tasks fast too, and thus choose
a processor that can do so and *then* look to improve its throughput
efficiency (and SMT does precisely that).

....

> |> Then you haven't been paying attention - as in fact you admit elsewhere
> |> with regard to recent POWER implementations, since the best evidence
> |> that immediately springs to mind is that of POWER5, where SMT
> |> purportedly provides up to 40% increased TPC-C throughput per core. The
> |> EV8 simulations predicted even higher increases for their
> |> implementation, but of course we'll never know. And even poor old
> |> Itanic (Montecito) appears to gain something like a 20% benefit from SMT
> |> in TPC-C (though if you mean to exclude SoeMT from your definition of
> |> 'SMT' that may not be relevant to you).
>
> On the contrary, you are ignoring what was well known about the POWER
> series. Yes, OF COURSE, the POWER5 did massively better than the
> POWER4

Learn to read, Nick: I wasn't comparing POWER5 to POWER4 - I was
comparing POWER5 with SMT enabled to POWER5 without SMT enabled (and the
same for EV8 and Montecito).

- bill