How Many Processor Cores Are Enough?
|
From: Bill Todd on 17 Oct 2006 19:10 Nick Maclaren wrote: > In article <1161087948.387424(a)nnrp2.phx1.gblx.net>, > "Dennis M. O'Connor" <dmoc(a)primenet.com> writes: > |> > |> > What you are saying is that the Intel and AMD architects (x86 and IA64), > |> > the IBM architects (zOS and POWER), the MIPS and SPARC architects and > |> > others have done their jobs wrong. > |> > |> No, Nick, I was saying that they haven't been perfect. > |> No one is, you know, you less than most in fact. > > Wriggle as you like, you cannot avoid admitting that you said > > ... But if the architects and micro-architects > have done their jobs right, then program correctness will not > be affected by micro-architecture. .. An unbiased observer might suspect that the main disagreement between you two is over the definition of program 'correctness': Dennis seems to think it means adhering to the defined architecture (and in particular eschewing use of any behavior not specified in the architecture), while you seem to think otherwise (perhaps nothing quite as loose as "If it works reliably on a given instance of the architecture then it's correct", but rather "If it adheres to the defined architecture *as extended by the micro-architectural release notes* then it's correct"). If that's the case, then you're just talking past each other. > > and that all of the architecture I mentioned (and others) deliberately > leave some details unspecified in the architecture, even when they are > essential for writing correct parallel or interrupt-handling code. Your earlier examples (as did Terje's) seemed to be talking about *optimization*-related issues rather than about functional ones, but your statement above does not. So that's more interesting: are there in fact architectural gaps that make it impossible to implement certain facilities (such as the ones you mentioned above) at the *functional* level, independent of any adverse performance impact which sticking strictly to the defined architecture might have? If there are, then I'd be inclined to agree with Dennis that this represents a deficiency in the architecture definition rather than a useful loophole (since I'd expect that the architecture really should cover functional needs, even if it also elects to leave loopholes for additional optimization). If there aren't, then I'd be inclined to agree with Dennis that a program which deviates from the defined architecture purely for purposes of performance optimization should not be considered 'correct' in the context of this discussion (even though it may be perfectly 'correct' in some other context, as long as it is clearly documented which instances of the architecture it is allowed to run on). But it's certainly possible that there are additional aspects not yet clearly exposed which would further complicate the issue. - bill
From: Del Cecchi on 17 Oct 2006 23:22 "Bill Todd" <billtodd(a)metrocast.net> wrote in message news:5tWdnSAoYJZq_6jYnZ2dnUVZ_oCdnZ2d(a)metrocastcablevision.com... > Nick Maclaren wrote: >> In article <1161087948.387424(a)nnrp2.phx1.gblx.net>, >> "Dennis M. O'Connor" <dmoc(a)primenet.com> writes: >> |> >> |> > What you are saying is that the Intel and AMD architects (x86 and >> IA64), >> |> > the IBM architects (zOS and POWER), the MIPS and SPARC architects >> and >> |> > others have done their jobs wrong. >> |> |> No, Nick, I was saying that they haven't been perfect. >> |> No one is, you know, you less than most in fact. >> >> Wriggle as you like, you cannot avoid admitting that you said >> >> ... But if the architects and micro-architects >> have done their jobs right, then program correctness will not >> be affected by micro-architecture. .. > > An unbiased observer might suspect that the main disagreement between > you two is over the definition of program 'correctness': Dennis seems > to think it means adhering to the defined architecture (and in > particular eschewing use of any behavior not specified in the > architecture), while you seem to think otherwise (perhaps nothing quite > as loose as "If it works reliably on a given instance of the > architecture then it's correct", but rather "If it adheres to the > defined architecture *as extended by the micro-architectural release > notes* then it's correct"). > > If that's the case, then you're just talking past each other. > >> >> and that all of the architecture I mentioned (and others) deliberately >> leave some details unspecified in the architecture, even when they are >> essential for writing correct parallel or interrupt-handling code. > > Your earlier examples (as did Terje's) seemed to be talking about > *optimization*-related issues rather than about functional ones, but > your statement above does not. So that's more interesting: are there > in fact architectural gaps that make it impossible to implement certain > facilities (such as the ones you mentioned above) at the *functional* > level, independent of any adverse performance impact which sticking > strictly to the defined architecture might have? > > If there are, then I'd be inclined to agree with Dennis that this > represents a deficiency in the architecture definition rather than a > useful loophole (since I'd expect that the architecture really should > cover functional needs, even if it also elects to leave loopholes for > additional optimization). If there aren't, then I'd be inclined to > agree with Dennis that a program which deviates from the defined > architecture purely for purposes of performance optimization should not > be considered 'correct' in the context of this discussion (even though > it may be perfectly 'correct' in some other context, as long as it is > clearly documented which instances of the architecture it is allowed to > run on). > > But it's certainly possible that there are additional aspects not yet > clearly exposed which would further complicate the issue. > > - bill I would guess that, like some of the internal architecture documents I have glanced at, some behavior is described as "implementation dependent", so it is reasonable to infer that indeed different implementations might have different results for programs that depend on that behavior. In a specification for interconnect that I am familiar with, there are behaviours which use the term "may" as opposed to "must". So that sort of thing is not uncommon. And of course there is the classic account of writing the 7094 emulator in "the mythical man month" which I'm sure you all have read. del
From: Dennis M. O'Connor on 18 Oct 2006 01:28 <rohit.nadig(a)gmail.com> wrote [ ... blah blah blah ...] > Architect, micro-architect, I could care less. Then shut the f*ck up. There's enough noise on USENET already without ever pissant Gmail user puking up onto a thread just to tell everyone they don't care about it. -- Dennis M. O'Connor dmoc(a)primenet.com
From: Nick Maclaren on 18 Oct 2006 04:04 In article <5tWdnSAoYJZq_6jYnZ2dnUVZ_oCdnZ2d(a)metrocastcablevision.com>, Bill Todd <billtodd(a)metrocast.net> writes: |> > |> > ... But if the architects and micro-architects |> > have done their jobs right, then program correctness will not |> > be affected by micro-architecture. .. |> |> An unbiased observer might suspect that the main disagreement between |> you two is over the definition of program 'correctness': Dennis seems |> to think it means adhering to the defined architecture (and in |> particular eschewing use of any behavior not specified in the |> architecture), while you seem to think otherwise (perhaps nothing quite |> as loose as "If it works reliably on a given instance of the |> architecture then it's correct", but rather "If it adheres to the |> defined architecture *as extended by the micro-architectural release |> notes* then it's correct"). |> |> If that's the case, then you're just talking past each other. Which is normal. But he clearly doesn't understand the area. As I said, and will explain a bit more below, it is not POSSIBLE to write within the strictly defined (portable) subset of the architecture, and that therefore program correctness will necessarily depend on the micro-architectural extensions to the specification. And that is NOT because the architects have not "done their jobs right", but is the result of a reasoned decision. ALL architectures I have seen, from System/360 onwards, have been structured like that. That certainly includes MIPS, PA-RISC, SPARC, POWER and x86 - ARM charges for its specification, and I haven't needed to use it at work. |> Your earlier examples (as did Terje's) seemed to be talking about |> *optimization*-related issues rather than about functional ones, but |> your statement above does not. So that's more interesting: are there |> in fact architectural gaps that make it impossible to implement certain |> facilities (such as the ones you mentioned above) at the *functional* |> level, independent of any adverse performance impact which sticking |> strictly to the defined architecture might have? In my experience, invariably. As someone mentioned, performance monitoring is almost always unspecified (for bad reasons, but that is another matter), but so is booting, power control, shutdown etc. However, it is also normal for some of the details left unspecified (or "implementation dependent") to affect parallel APPLICATIONS code. I won't go into that one in any detail, as Andy Glew has posted much more authoritative details than I could, but I will give examples from interrupt handling. To achieve even tolerable efficiencies, most modern CPUs do not drain the pipeline on interrupt, let alone stop the whole system, but they require the interrupt handler to do that when necessary. But the architectures don't usually specify how to do either, or the exact details of instruction completion (e.g. when and in what context). For example, a pipelined store might take an ECC or TLB miss after having made a system call. Also, few of them specify the exact contents of the data block passed to the FLIH, which is obviously critical when attempting to do a fixup (e.g. ECC, TLB or floating-point emulation). All of that is specified in the implementation notes or whatever, but is essential to writing correct FLIHs. |> If there are, then I'd be inclined to agree with Dennis that this |> represents a deficiency in the architecture definition rather than a |> useful loophole (since I'd expect that the architecture really should |> cover functional needs, even if it also elects to leave loopholes for |> additional optimization). If there aren't, then I'd be inclined to |> agree with Dennis that a program which deviates from the defined |> architecture purely for purposes of performance optimization should not |> be considered 'correct' in the context of this discussion (even though |> it may be perfectly 'correct' in some other context, as long as it is |> clearly documented which instances of the architecture it is allowed to |> run on). That is not what he said - he accused the architects of not doing their jobs, which is very different. But let that pass, as it is what he SHOULD have said. However, it is probably unavoidable. Some of those areas are so nasty that specifying them precisely in an architecture would handicap the CPU designers unreasonably. Look at all the trouble they have had to support single CPU semantics in SMP designs! However, I agree that others are shoddy design. Performance counters are almost invariably designed for the hardware designers' use, and are made available (or not) to the programmer as an afterthought. With a decent design, they could be architected. For example, what is needed is NOT counts of the raw hardware events, but the proportion of clocks spent in interrupts, restoring after a branch miss, waiting for cache, waiting for memory etc. |> But it's certainly possible that there are additional aspects not yet |> clearly exposed which would further complicate the issue. There are. I know some of them, but I know that I don't know all of them. Regards, Nick Maclaren.
From: Peter Dickerson on 18 Oct 2006 05:52
"Dennis M. O'Connor" <dmoc(a)primenet.com> wrote in message news:1161149308.244560(a)nnrp2.phx1.gblx.net... > <rohit.nadig(a)gmail.com> wrote > [ ... blah blah blah ...] > > Architect, micro-architect, I could care less. > > Then shut the f*ck up. There's enough noise on USENET > already without ever pissant Gmail user puking up onto > a thread just to tell everyone they don't care about it. Dennis, calm down please. It doesn't help the image of comp.arch . Yes, Nick can be bloody infuriating. He really ought to be citing references for the points he makes (=existance proof) - he works (or goes round) in academic circles, so he should know the form. Peter |