How Many Processor Cores Are Enough?
|
From: Nick Maclaren on 17 Oct 2006 08:37 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. .. 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. But I predict that you will deny those :-) Regards, Nick Maclaren.
From: already5chosen on 17 Oct 2006 08:39 Nick Maclaren wrote: > In article <1160970636.656420(a)nnrp1.phx1.gblx.net>, > "Dennis M. O'Connor" <dmoc(a)primenet.com> writes: > |> "Terje Mathisen" <terje.mathisen(a)hda.hydro.com> wrote ... > |> > Dennis M. O'Connor wrote: > |> > |> >> Architecture is, in general, what the programmers see, and > |> >> doesn't change too much from, say, a Pentium III to a Pentium IV > |> >> (except the new stuff (WNI) added to P4). > |> >> > |> >> Microarchitecture is the highest-level of the processor design. > |> >> The P3 and P4 micro-architoectures are very different; you'd > |> >> hardly know that they were the same ISA to look at them. > |> > > |> > Even for a (semi-)regular programmer microarchitecture can become very > |> > important! > |> > |> For performance, yes. But if the architects and micro-architects > |> have done their jobs right, then program correctness will not > |> be affected by micro-architecture. I think we agree on that. > > Er, no. The boundary of the architecture normally leaves some important > aspects unspecified, and that is precisely where the correctness of a > program DOES get affected by micro-architecture. Areas where this is > important include: > > Interrupt handling - my pet hobby-horse! > > Thread control, communication, memory affinity etc. > > The precise memory model, atomicity, barriers etc. > > I/O support. > > Booting, shutdown, virtualisation etc. > > Theoretically, all of those could be specified in the architecture up > to a level of detail that would allow even kernels and drivers to be > written without knowing about the micro-architecture, but it has rarely > even been attempted. > > In general, the authors of unprivileged applications don't need to know > about those, but that assumes that their language, compiler and run-time > system hide the differences from the programmer. That is more common, > but not normally done very well :-( > > > Regards, > Nick Maclaren. I would like to see an example of microarchitectural change in processors from the following list (PIII, K7, K8, P4, PM, Merom) that broke working PII application program, library, device driver or any other SW component that was written with full conformance to PII variant of IA-32 architecture. Of course, performance monituring tools doesn't count, because w.r.t. performance monitoring all this processors have different architectures. Same sort of examples for zArch and for SPARC V9 would be wellcome too.
From: Nick Maclaren on 17 Oct 2006 09:14 In article <1161088788.071516.69900(a)f16g2000cwb.googlegroups.com>, already5chosen(a)yahoo.com writes: |> |> > Er, no. The boundary of the architecture normally leaves some important |> > aspects unspecified, and that is precisely where the correctness of a |> > program DOES get affected by micro-architecture. Areas where this is |> > important include: ... |> |> I would like to see an example of microarchitectural change in |> processors from the following list (PIII, K7, K8, P4, PM, Merom) that |> broke working PII application program, library, device driver or any |> other SW component that was written with full conformance to PII |> variant of IA-32 architecture. I haven't a clue whether that has happened, or whether the cases where kernels etc. had to be modified were all the developers's fault. It isn't relevant, for three reasons: 1) My posting was pointing out that there ARE places where a correct program DOES need to worry about more than just the architecture, and I gave a partial list. 2) In several of those areas, it is not possible to write fully functional code while sticking to the architecture's guaranteed safe subset, because there is not enough that is completely specified. 3) Micro-architects are heavily leant on to maintain upwards compatibility, precisely to avoid such breakages. |> Of course, performance monituring tools doesn't count, because w.r.t. |> performance monitoring all this processors have different |> architectures. Why not? I didn't include performance monitoring, but that is another example. |> Same sort of examples for zArch and for SPARC V9 would be wellcome too. In all cases, look at the areas I gave. A couple of simple examples: The set of cases where floating-point is handled by emulation is unspecified, and (clearly) the handler has to handle such cases. This also applies to integer multiplication and division on some architectures. Much of the load/store atomicity is unspecified, especially with regard to multiple cores and data objects which need a lower alignment than their size. That is a common source of problem. Regards, Nick Maclaren.
From: Eric P. on 17 Oct 2006 10:24 Nick Maclaren wrote: > > In article <1161088788.071516.69900(a)f16g2000cwb.googlegroups.com>, > already5chosen(a)yahoo.com writes: > |> > |> > Er, no. The boundary of the architecture normally leaves some important > |> > aspects unspecified, and that is precisely where the correctness of a > |> > program DOES get affected by micro-architecture. Areas where this is > |> > important include: ... > |> > |> I would like to see an example of microarchitectural change in > |> processors from the following list (PIII, K7, K8, P4, PM, Merom) that > |> broke working PII application program, library, device driver or any > |> other SW component that was written with full conformance to PII > |> variant of IA-32 architecture. > > I haven't a clue whether that has happened, or whether the cases where > kernels etc. had to be modified were all the developers's fault. It > isn't relevant, for three reasons: > > 1) My posting was pointing out that there ARE places where a correct > program DOES need to worry about more than just the architecture, and I > gave a partial list. > > 2) In several of those areas, it is not possible to write fully > functional code while sticking to the architecture's guaranteed safe > subset, because there is not enough that is completely specified. > > 3) Micro-architects are heavily leant on to maintain upwards > compatibility, precisely to avoid such breakages. Your argument is an unwarranted generalization. Some men have beards; Socrates is a man therefore Socrates has a beard. Some processors have bugs; this is a processor therefore it has bugs. That is why you cannot provide examples. When pressed on your point, you fall back the truth of the original premise and gloss over the unwarrented generalization. Eric
From: Joe Seigh on 17 Oct 2006 10:35
Nick Maclaren wrote: > > Much of the load/store atomicity is unspecified, especially with regard > to multiple cores and data objects which need a lower alignment than > their size. That is a common source of problem. > Case in point, the complete and utter lack of a clear and unambiguous publically documented memory model for Intel architecture. We've had comments from Andy Glew to that effect here on c.a. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. |