performance of hardware dynamic scheduling
|
From: Nick Maclaren on 2 Apr 2008 07:37 In article <995fac6b-3e01-472e-a47f-c9a789405dd5(a)u10g2000prn.googlegroups.com>, David Kanter <dkanter(a)gmail.com> writes: |> |> > |> 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 I was referring primarily to Intel's own technical publications, which I regard as more reliable. Let us assume that article's description of Silverthorne is accurate, and that it does count as SMT. The only evidence in that is the statement of a Silverthorne project manager that he estimates that one of Silverthorne's features (SMT) delivers a 15-25% gain in performance per watt. Well, there are two points: Firstly, would you expect a project manager to say anything different when speaking to the Tech Report? I remember some pretty similar statements made about the IA64, POWER4 memory system and other fiascos. Secondly, there was no information on what was meant by any of that - even power consumption isn't a simple measure, and performance can be virtually anything you like. As evidence, that is weak, to put it mildly. Thirdly, will Silverthorne trigger the same software problems that caused so many people to switch off SMT on the Pentium 4? We can't possibly tell until people run it on production code. Regards, Nick Maclaren.
From: Jan Vorbrüggen on 2 Apr 2008 10:59 > If you have more than a couple of threads seriously gulping down > processor cycles any large percentage of the time, I suspect that you're > a far-from-typical Windows user - though it's still always nice to have > a core (or at least a thread within a core) dedicated to interactive > responsiveness. That latter is the important point: Windows just has too stupid a task/process scheduler which isn't able to ensure interactive responsiveness. Dedicating, if you will, a core to each active task (no matter whether I care, at this moment, about its throughput or not) is a kludge of the worst kind to work around this misbehaviour; but we have seen similar kludges in the past. > That last almost sounds as if you're using a single-core processor. They > may soon start becoming difficult to find (save perhaps in embedded > applications). Well, sure - this is a three or four year old laptop. And even with a newer one I'd rather have a few slower, power-efficient cores than one power-hungry one. I also agree with Nick that it would be nice to have office versions that don't need a fan, even if single-thread performance were to suffer. Jan
From: Nick Maclaren on 2 Apr 2008 11:08 In article <ft04pl$s9o$1(a)s1.news.oleane.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <Jan.Vorbrueggen(a)not-thomson.net> writes: |> |> That latter is the important point: Windows just has too stupid a |> task/process scheduler which isn't able to ensure interactive |> responsiveness. Dedicating, if you will, a core to each active task (no |> matter whether I care, at this moment, about its throughput or not) is a |> kludge of the worst kind to work around this misbehaviour; but we have |> seen similar kludges in the past. Yes. But dedicating one to handle external interrupts and similar kernel activities is definitely worthwhile, and not unclean at all. Equally, having enough cores that a single key press or button click doesn't force the best part of a dozen context switches just to get to the application and display the change would be good. |> Well, sure - this is a three or four year old laptop. And even with a |> newer one I'd rather have a few slower, power-efficient cores than one |> power-hungry one. I also agree with Nick that it would be nice to have |> office versions that don't need a fan, even if single-thread performance |> were to suffer. Or even one that needed only one slow, quiet fan per box, and not the multiplicity of fans and even half-grown turbines that some systems need. Regards, Nick Maclaren.
From: Bill Todd on 2 Apr 2008 13:35 Jan Vorbr�ggen wrote: .... even with a > newer one I'd rather have a few slower, power-efficient cores than one > power-hungry one. Vendors appear to believe that most people would not - and I agree with that assessment. I also agree with Nick that it would be nice to have > office versions that don't need a fan, even if single-thread performance > were to suffer. In which case the first thing to go will likely be the multiple cores rather than single-core performance - again, assuming that the vendors' apparent assessment of what most people (including me) want is correct. For *any* given power drain, for most tasks in which I'm interested I'd rather have one fast, flexible SMT core than several dumb cores (even including highly parallel server-style processing, unless those dumb cores were SoeMT-enabled) - up to the point of seriously diminishing returns for effectively adding single-thread ILP to that single SMT core, at which point I'd prefer to start adding cores each of which was somewhere near the complexity level of the existing core (again, in preference to more but dumber cores). We have many decades of software experience in effectively multiplexing tasks onto a single core, and if Microsoft has still somehow managed to miss the boat sufficiently seriously in this area to be a real problem there are multiple credible alternatives readily available. - bill
From: Nick Maclaren on 2 Apr 2008 13:23
In article <P5SdnX8t4_MmKG7anZ2dnUVZ_rGhnZ2d(a)metrocastcablevision.com>, Bill Todd <billtodd(a)metrocast.net> writes: |> Jan Vorbr�ggen wrote: |> |> For *any* given power drain, for most tasks in which I'm interested I'd |> rather have one fast, flexible SMT core than several dumb cores (even |> including highly parallel server-style processing, unless those dumb |> cores were SoeMT-enabled) - up to the point of seriously diminishing |> returns for effectively adding single-thread ILP to that single SMT |> core, at which point I'd prefer to start adding cores each of which was |> somewhere near the complexity level of the existing core (again, in |> preference to more but dumber cores). |> |> We have many decades of software experience in effectively multiplexing |> tasks onto a single core, and if Microsoft has still somehow managed to |> miss the boat sufficiently seriously in this area to be a real problem |> there are multiple credible alternatives readily available. Doubtless you would want that, doubtless most people do want that, you are doubtless right that it is the simplest and generally best strategy and you are doubtless correct that it served the IT community well for many decades. Now, why are you still completely wrong? You don't seem to have realised that "not_Moore's Law" which said that serial speeds increase at 50% per annum stopped working some time back. You can't rely on single, serial cores becoming ever faster. End of story. And, obviously, that means that you can't rely on an SMT core becoming ever faster - because, if you could, you could run it in single thread mode and get an ever faster serial core. Let us assume that Silverthorne delivers what it is claimed to do: 15-25% more throughput for the watt. Fine. It is a 2-way design, and SMT does not scale. Eggers's main paper used the much simpler MIPS as a basis, and even THAT didn't scale beyond about 4-way. Don't take my word for it - go read it and see. I despair :-( Regards, Nick Maclaren. |