How Many Processor Cores Are Enough?
|
From: Nick Maclaren on 17 Oct 2006 10:41 In article <apSdnSC3XseEd6nYnZ2dnUVZ_sydnZ2d(a)comcast.com>, Joe Seigh <jseigh_01(a)xemaps.com> writes: |> > |> > 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. Precisely. I am glad that someone seems to understand the issue. Regards, Nick Maclaren.
From: Nick Maclaren on 17 Oct 2006 10:46 In article <4534e9db$0$1354$834e42db(a)reader.greatnowhere.com>, "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> writes: |> |> That is why you cannot provide examples. I did. I provided two that apply to all of x86, IA64, MIPS, SPARC (probably even restricted to v9, but I haven't checked) and zArch. I have encountered both of them (including differences between CPU implementations) on all of those. Go and read those architectures, CAREFULLY, and you will see that. Also, if you had relevant experience, you will know that there have been quite a lot of changes in those areas. Look at the Linux and other kernels for evidence. Regards, Nick Maclaren.
From: Eric P. on 17 Oct 2006 12:24 Nick Maclaren wrote: > > In article <4534e9db$0$1354$834e42db(a)reader.greatnowhere.com>, > "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> writes: > |> > |> That is why you cannot provide examples. > > I did. I provided two that apply to all of x86, IA64, MIPS, SPARC > (probably even restricted to v9, but I haven't checked) and zArch. > I have encountered both of them (including differences between CPU > implementations) on all of those. No, you said: > 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. I see, so your point is the totally vacuous and useless observation that some processors have some problems. Some asteroids hit the earth. There, see how helpful that was? > Go and read those architectures, CAREFULLY, and you will see that. > Also, if you had relevant experience, you will know that there have > been quite a lot of changes in those areas. Look at the Linux and > other kernels for evidence. If you had even one concrete example, you would have provided it. Those with the relevant experience deal with specific issues on specific processors and don't listen to people whose sole contibution is vague warnings that the sky might someday fall. So to the extent that I have, in the past, had to sit through meetings while such persons blither on, I also have 'relevant experience'. Eric
From: Eric P. on 17 Oct 2006 12:26 Nick Maclaren wrote: > > In article <apSdnSC3XseEd6nYnZ2dnUVZ_sydnZ2d(a)comcast.com>, > Joe Seigh <jseigh_01(a)xemaps.com> writes: > |> > > |> > 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. > > Precisely. I am glad that someone seems to understand the issue. No. Apparently you don't understand your own point (or maybe are trying to change it on the fly again). The fact that the specs are unclear and ambiguous does not support your assertion that on all systems a correctly implemented micro architecture has visible implications that require code changes to compensate for. What are those code changes, on which Intel x86 makes and models? Eric
From: kenney on 17 Oct 2006 13:15
In article <eh2l0a$t90$1(a)gemini.csx.cam.ac.uk>, nmm1(a)cus.cam.ac.uk (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. Are you talking solely about factors that affect program optimisation? I ask this because most high level languages isolate the programmer from the architecture anyway. Come to that so do operating systems with the HAL. Presumably this is most important for compiler writers. Ken Young |