|
From: Jan Vorbrüggen on 2 Apr 2008 06:31 > 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 2 Apr 2008 06:33 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 2 Apr 2008 06:56 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 2 Apr 2008 07:17 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 2 Apr 2008 08:26
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 |