50 cores
in [Design]
|
From: John Larkin on 10 Jun 2010 12:27 On Thu, 10 Jun 2010 11:03:07 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >John Larkin wrote: > > >> Eventually we'll have a CPU as every device driver, and a CPU for >> every program thread, with real execution protection. No more buffer >> overflow exploits, no more crashed OSs, no more memory leaks. > >Instead we will have racing, deadlocks, data coherency issues, state >save/restore problems, unpredictable arbitration and a version hell. That would be different somehow? John
From: Vladimir Vassilevsky on 10 Jun 2010 12:37 John Larkin wrote: > On Thu, 10 Jun 2010 11:03:07 -0500, Vladimir Vassilevsky > <nospam(a)nowhere.com> wrote: > > >> >>John Larkin wrote: >> >> >> >>>Eventually we'll have a CPU as every device driver, and a CPU for >>>every program thread, with real execution protection. No more buffer >>>overflow exploits, no more crashed OSs, no more memory leaks. >> >>Instead we will have racing, deadlocks, data coherency issues, state >>save/restore problems, unpredictable arbitration and a version hell. > > > That would be different somehow? Every new core or master on the bus adds a dimension to the problems. VLV
From: Martin Brown on 10 Jun 2010 13:16 On 10/06/2010 16:52, John Larkin wrote: > On Thu, 10 Jun 2010 06:56:56 -0700 (PDT), MooseFET > <kensmith(a)rahul.net> wrote: > >> On Jun 1, 11:07 am, John Larkin >> <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >>> http://online.wsj.com/article/SB1000142405274870340660457527867166190... >>> >>> John >> >> 50 seems an odd number. I would expect a power of 2 or a power of 3 >> number of cores. > > Maybe they did 64 and only get 50 to work? From what limited technical info has leaked out it seems the chips are 32 core so heaven knows where this 50 core number comes from. Perhaps a pair of the prototype 32 core chips have 50 working cores between them. The whole thing appears to be PR fluff for Wall Street and investors to drool over - there is very little about it on their website. > >> >> The power of 2 number is just because things tend to be doubled and >> doubled etc. >> >> The power of 3 number is because if you imagine a hypercube >> like arrangement where each side is a bus for communication >> directly between cores, it makes sense to have 3 processors >> on a bus because while A and B are talking, C can't be having >> a conversation with either. This would allow the array or cores >> to get information quickly between themselves. It assumes >> that they each have a cache that the transfer works to sync. >> >> At some point, adding more of the same cores stops working >> as well as adding some special purpose hardware to a fraction >> of the cores. >> >> Not every core needs to be able to do a floating point at all. >> Some would be able to profit from a complex number ALU >> or perhaps a 3D alu. >> >> Chances are, one core would get stuck with the disk I/O etc >> that core would profit from having fast interrupt times. The >> others less so. > > Eventually we'll have a CPU as every device driver, and a CPU for > every program thread, with real execution protection. No more buffer > overflow exploits, no more crashed OSs, no more memory leaks. And replace them with horrendous memory contention and cache coherency problems - great! Mickeysoft can barely cope with programming on 4 cores. I see plenty of "interesting* race condition faults in XL2007. The easiest to provoke is programatically drawing moderately large graphs and altering the axes. It is quite easy for the code that modifies the axis to run before the axis object had been instantiated on a multicore box. Regards, Martin Brown
From: John Larkin on 10 Jun 2010 14:28 On Thu, 10 Jun 2010 11:37:43 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >John Larkin wrote: > >> On Thu, 10 Jun 2010 11:03:07 -0500, Vladimir Vassilevsky >> <nospam(a)nowhere.com> wrote: >> >> >>> >>>John Larkin wrote: >>> >>> >>> >>>>Eventually we'll have a CPU as every device driver, and a CPU for >>>>every program thread, with real execution protection. No more buffer >>>>overflow exploits, no more crashed OSs, no more memory leaks. >>> >>>Instead we will have racing, deadlocks, data coherency issues, state >>>save/restore problems, unpredictable arbitration and a version hell. >> >> >> That would be different somehow? > >Every new core or master on the bus adds a dimension to the problems. > >VLV The trend seems to be to have a bunch of cores around a shared L2 cache. The usual hardware cache coherency stuff can be done, easier than in lots of other situations. Add a pile of bulletproof hardware semaphores. All single-clock synchronous logic. Paradise. It's obvious by now that the software boys are never going to get it right. It's time for multitasking to be managed by hardware. John
From: John Larkin on 10 Jun 2010 14:32
On Thu, 10 Jun 2010 18:16:59 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >On 10/06/2010 16:52, John Larkin wrote: >> On Thu, 10 Jun 2010 06:56:56 -0700 (PDT), MooseFET >> <kensmith(a)rahul.net> wrote: >> >>> On Jun 1, 11:07 am, John Larkin >>> <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> http://online.wsj.com/article/SB1000142405274870340660457527867166190... >>>> >>>> John >>> >>> 50 seems an odd number. I would expect a power of 2 or a power of 3 >>> number of cores. >> >> Maybe they did 64 and only get 50 to work? > > From what limited technical info has leaked out it seems the chips are >32 core so heaven knows where this 50 core number comes from. Perhaps a >pair of the prototype 32 core chips have 50 working cores between them. > >The whole thing appears to be PR fluff for Wall Street and investors to >drool over - there is very little about it on their website. >> >>> >>> The power of 2 number is just because things tend to be doubled and >>> doubled etc. >>> >>> The power of 3 number is because if you imagine a hypercube >>> like arrangement where each side is a bus for communication >>> directly between cores, it makes sense to have 3 processors >>> on a bus because while A and B are talking, C can't be having >>> a conversation with either. This would allow the array or cores >>> to get information quickly between themselves. It assumes >>> that they each have a cache that the transfer works to sync. >>> >>> At some point, adding more of the same cores stops working >>> as well as adding some special purpose hardware to a fraction >>> of the cores. >>> >>> Not every core needs to be able to do a floating point at all. >>> Some would be able to profit from a complex number ALU >>> or perhaps a 3D alu. >>> >>> Chances are, one core would get stuck with the disk I/O etc >>> that core would profit from having fast interrupt times. The >>> others less so. >> >> Eventually we'll have a CPU as every device driver, and a CPU for >> every program thread, with real execution protection. No more buffer >> overflow exploits, no more crashed OSs, no more memory leaks. > >And replace them with horrendous memory contention and cache coherency >problems - great! Synchronous logic. Hardware semaphores. Absolute hardware protections. OS that shares nothing with apps. Bulletproof. > >Mickeysoft can barely cope with programming on 4 cores. That's because they are trying to run Windows on more cores, and worse, often trying to distribute one computational problem among multiple cores. That is insane. John |