50 cores
in [Design]
|
From: Paul Keinanen on 11 Jun 2010 13:50 On Fri, 11 Jun 2010 07:01:41 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Fri, 11 Jun 2010 08:46:27 +0300, Paul Keinanen <keinanen(a)sci.fi> >wrote: > >>On Thu, 10 Jun 2010 21:15:45 +0100, Martin Brown >><|||newspam|||@nezumi.demon.co.uk> wrote: >> >>>Absolute hardware protection can be done on one CPU with segmented >>>architecture and a viciously defensive TLB. Even better if you use >>>Harvard architecture which for obvious reasons prevents data execution. >>> >>>If your multi-CPUs share a common flat address space as is currently in >>>vogue any protection your separate physical cores offer is largely >>>illusory. You would be better off with virtual CPUs and a tiny >>>hypervisor with slightly paranoid behaviour watching over them. >> >>If you are sharing the same RAM chips between multiple cores, you are >>still going to end up with a single (physical) address space. >> >>Execution prevention as well as read only data pages has been done by >>TLBs in mid 1970's minicomputers, so this is not really anything new. >> >>Of course, in a multi core system each core must have their own TLBs >>and must have a trusted method to set up these TLBs. >> >>Having separate TLBs for each core is not so bad, since even now, some >>architectures have the TaskId as part of the virtual address, thus, a >>full TLB reload is not required during task switching. >> > >Right. And if you dump virtual addressing, you don't need a gigantic >number of mapping registers. In a virtual memory system, the disk space (exe files and page file) _is_ the actual memory. Think about the main memory RAM just as one level of cache between the disk and the internal CPU caches.
From: Jan Panteltje on 11 Jun 2010 14:53 On a sunny day (Fri, 11 Jun 2010 17:29:58 +0200) it happened Jeroen Belleman <jeroen(a)nospam.please> wrote in <hutkpk$e6o$1(a)speranza.aioe.org>: >John Larkin wrote: >> If you think of multicore as a way to get speed through parallelism, >> it will always be tough. If you are willing to waste flipflops to make >> a system brutally reliable, multicore is the way to go. >> >> I don't want more speed. I want reliability. > >Aye! And stability! > >Sick and tired of upgrading, >Jeroen Belleman Just run Linux, I am still running the first grml on the server. Only reason to upgrade packages is for example a new flash player or browser that 'closes security holes'. Not that anyone ever made it into this system that I know about. I have upgraded kernel a few times because of new hardware and drivers. But if you use the system 'as is' then there is no reason to ever change software. And Linud uses all those things J.L. is so against, while he confirms his Linux PC has an uptime of 9 month,. So I fail to see his arguments.
From: John Larkin on 11 Jun 2010 15:25 On Fri, 11 Jun 2010 18:53:04 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Fri, 11 Jun 2010 17:29:58 +0200) it happened Jeroen Belleman ><jeroen(a)nospam.please> wrote in <hutkpk$e6o$1(a)speranza.aioe.org>: > >>John Larkin wrote: >>> If you think of multicore as a way to get speed through parallelism, >>> it will always be tough. If you are willing to waste flipflops to make >>> a system brutally reliable, multicore is the way to go. >>> >>> I don't want more speed. I want reliability. >> >>Aye! And stability! >> >>Sick and tired of upgrading, >>Jeroen Belleman > >Just run Linux, I am still running the first grml on the server. >Only reason to upgrade packages is for example a new flash player or browser that >'closes security holes'. >Not that anyone ever made it into this system that I know about. >I have upgraded kernel a few times because of new hardware and drivers. >But if you use the system 'as is' then there is no reason to ever change software. >And Linud uses all those things J.L. is so against, while he confirms his Linux >PC has an uptime of 9 month,. >So I fail to see his arguments. Silicon realities are going to give us chips with lots of, maybe hundreds or thousands, of cores. We might reconsider OS design when cores are cheap and plentiful. It will certainly change embedded systems when we have lots of cores. No RTOS as currently defined. John
From: Jeroen Belleman on 11 Jun 2010 17:35 On 06/11/2010 08:53 PM, Jan Panteltje wrote: > On a sunny day (Fri, 11 Jun 2010 17:29:58 +0200) it happened Jeroen Belleman > <jeroen(a)nospam.please> wrote in<hutkpk$e6o$1(a)speranza.aioe.org>: > >> [...] Sick and tired of upgrading, >> Jeroen Belleman > > Just run Linux,[...] But I do! Obligatory upgrades are the rule of the house here. Every upgrade is for security reasons, so we are told. Every login dialog here has a phrase saying "Logging in means you agree with the computing rules", which spell this out. I'm a heretic. I contest. But I'm only me. Granted, these rules have been drawn up by users of Micro$oft's products, for whom this is the stark truth. Jeroen Belleman
From: Jan Panteltje on 11 Jun 2010 18:23
On a sunny day (Fri, 11 Jun 2010 12:25:45 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <l93516ts97a3a6qpqjgpr2ejrn9mg8vv19(a)4ax.com>: >On Fri, 11 Jun 2010 18:53:04 GMT, Jan Panteltje ><pNaonStpealmtje(a)yahoo.com> wrote: > >>On a sunny day (Fri, 11 Jun 2010 17:29:58 +0200) it happened Jeroen Belleman >><jeroen(a)nospam.please> wrote in <hutkpk$e6o$1(a)speranza.aioe.org>: >> >>>John Larkin wrote: >>>> If you think of multicore as a way to get speed through parallelism, >>>> it will always be tough. If you are willing to waste flipflops to make >>>> a system brutally reliable, multicore is the way to go. >>>> >>>> I don't want more speed. I want reliability. >>> >>>Aye! And stability! >>> >>>Sick and tired of upgrading, >>>Jeroen Belleman >> >>Just run Linux, I am still running the first grml on the server. >>Only reason to upgrade packages is for example a new flash player or browser that >>'closes security holes'. >>Not that anyone ever made it into this system that I know about. >>I have upgraded kernel a few times because of new hardware and drivers. >>But if you use the system 'as is' then there is no reason to ever change software. >>And Linud uses all those things J.L. is so against, while he confirms his Linux >>PC has an uptime of 9 month,. >>So I fail to see his arguments. > >Silicon realities are going to give us chips with lots of, maybe >hundreds or thousands, of cores. We might reconsider OS design when >cores are cheap and plentiful. > >It will certainly change embedded systems when we have lots of cores. >No RTOS as currently defined. > >John OK :-) I guess we can argue for years about this. Let's just wait and see. I wait for the 300 GHz singe core :-) x86 compatible, so I do not have to change anything :-) |