50 cores
in [Design]
|
From: MooseFET on 11 Jun 2010 10:19 On Jun 11, 10:01 pm, John Larkin <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > On Fri, 11 Jun 2010 08:46:27 +0300, Paul Keinanen <keina...(a)sci.fi> > wrote: > > > > >On Thu, 10 Jun 2010 21:15:45 +0100, Martin Brown > ><|||newspam...(a)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. If you keep some virtual addressing, you can make the code in each core not need to know where its address space actually lives in the grand scheme of things. Instead of an address map per task, you'd have one per core. This would only need to apply to the portion of memory that is shared. The private memory would not be virtual. when you do a fork(), a big bunch of stuff needs to fly from one core's private space to the new one. > > John
From: Jan Panteltje on 11 Jun 2010 10:46 On a sunny day (Fri, 11 Jun 2010 07:01:41 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <ubg416h3aaikphlokuu98mqte8pvnmvhn3(a)4ax.com>: > >Right. And if you dump virtual addressing, you don't need a gigantic >number of mapping registers. Are you referring to 'virtual memory"? http://en.wikipedia.org/wiki/Virtual_memory But then you are back to the stone age MSDOS. It is virtual memory that makes 'unlimited' (say 'limited by disk space only' computing possible. the reason I moved from MSDOS (or DRDOS rather) to Linux!
From: John Larkin on 11 Jun 2010 11:15 On Fri, 11 Jun 2010 14:46:36 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Fri, 11 Jun 2010 07:01:41 -0700) it happened John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in ><ubg416h3aaikphlokuu98mqte8pvnmvhn3(a)4ax.com>: >> >>Right. And if you dump virtual addressing, you don't need a gigantic >>number of mapping registers. > >Are you referring to 'virtual memory"? > http://en.wikipedia.org/wiki/Virtual_memory >But then you are back to the stone age MSDOS. >It is virtual memory that makes 'unlimited' (say 'limited by disk space only' computing possible. >the reason I moved from MSDOS (or DRDOS rather) to Linux! Virtual is the prime cause of code bloat. And it lets people ignore elegant design of data structures in favor of mindless thrashing. When IBM announced virtual for the s/360, they predicted paging ratios of 200:1. A survey done a few years later found a typical value of 1.2. John
From: John Larkin on 11 Jun 2010 11:21 On Fri, 11 Jun 2010 06:59:35 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On Jun 10, 11:52 pm, John Larkin ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> On Thu, 10 Jun 2010 06:56:56 -0700 (PDT), MooseFET >> >> <kensm...(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? >> >> >> >> >> >> >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. > >Multiple cores will be able to do all of those things and more. >There will be a large shared memory space to allow great >gobs of data to be handed back and forth. This will be where >one CPU can step on the output of another as it is being handed >off to the 3rd and 4th. When running the multi-core version of >Windows-9, there will still be crashes and the computer will still >be just fast enough to run Freecell. Windows will always crash, and will always be slow, no matter how much technology is available. PDP-11 and VAX timeshare systems ran, with a good fraction of hostile users, for months between power fails. We have a Linux server that's been up for something like 9 months now. > > >Thinking about doing something like a sort on a multicore machine >with caches on each core has started me thinking about a bit of >code I wrote a long time ago. It was a sort of files up in the >megabyte size range when RAM was restricted to 48K of free >space. The trick to making it go fast is to sort chunks that will >fit into memory and then do a merge operation on the sorted >chunks. I nested the merge operation partly within the sort to >save one level of read-process-write. 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. John
From: Jeroen Belleman on 11 Jun 2010 11:29
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 |