50 cores
in [Design]
|
From: MooseFET on 11 Jun 2010 23:15 On Jun 12, 10:23 am, "JosephKK"<quiettechb...(a)yahoo.com> wrote: > On Fri, 11 Jun 2010 06:59:35 -0700 (PDT), MooseFET <kensm...(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. > > >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. > > So you re-invented parts of merge sort, almost cool. No it wasn't the merge sort. It used the method as part of how it worked. The main thing it did was do a low amount of disk I/O while keeping the number of file handles low and not making more that 4 files. The latter requirement was because the directory system got very slow as the number of files created grew.
From: Paul Keinanen on 12 Jun 2010 02:16 On Fri, 11 Jun 2010 20:15:19 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On Jun 12, 10:23 am, "JosephKK"<quiettechb...(a)yahoo.com> wrote: >> On Fri, 11 Jun 2010 06:59:35 -0700 (PDT), MooseFET <kensm...(a)rahul.net> >> wrote: >> >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. >> >> So you re-invented parts of merge sort, almost cool. > >No it wasn't the merge sort. It used the method as part of how it >worked. The main thing it did was do a low amount of disk I/O >while keeping the number of file handles low and not making more >that 4 files. The latter requirement was because the directory >system got very slow as the number of files created grew. Replace "file handle" by "1/2 inch magnetic tape drive" and the description is quite similar to the early days of data processing. Typically magnetic tape drives were the only large mass storage devices and the core memory was so small that you could only afford one record buffer (typically the 80 column punched card image) for each tape drive. Algorithms were fine tuned based on the number of tape drives you had and how many operators were available to load new 2400 feet tape reals to the drives :-).
From: MooseFET on 12 Jun 2010 12:56 On Jun 12, 2:16 pm, Paul Keinanen <keina...(a)sci.fi> wrote: > On Fri, 11 Jun 2010 20:15:19 -0700 (PDT), MooseFET > > > > <kensm...(a)rahul.net> wrote: > >On Jun 12, 10:23 am, "JosephKK"<quiettechb...(a)yahoo.com> wrote: > >> On Fri, 11 Jun 2010 06:59:35 -0700 (PDT), MooseFET <kensm...(a)rahul.net> > >> wrote: > >> >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. > > >> So you re-invented parts of merge sort, almost cool. > > >No it wasn't the merge sort. It used the method as part of how it > >worked. The main thing it did was do a low amount of disk I/O > >while keeping the number of file handles low and not making more > >that 4 files. The latter requirement was because the directory > >system got very slow as the number of files created grew. > > Replace "file handle" by "1/2 inch magnetic tape drive" and the > description is quite similar to the early days of data processing. > Typically magnetic tape drives were the only large mass storage > devices and the core memory was so small that you could only afford > one record buffer (typically the 80 column punched card image) for > each tape drive. Algorithms were fine tuned based on the number of > tape drives you had and how many operators were available to load new > 2400 feet tape reals to the drives :-). I have a tape drive that dates from that era. 1200 BPI used to be considered a lot of data. The sort program is from well after that era. In some ways, the reel-to reel tape related programs had to be a lot simpler and smaller. With the disk one, the cost of a "rewind" was modest. This means that you would consider doing that. On the tape one, the logic was mostly about which tape to take the next record from. Way back in the tape drive days, seismic systems wrote their data onto tape. They servoed the speed of the drive so that the ADC output would be matched so that ony a very little buffering was needed. For marine surveys, the length of time a ship could stay at sea was set by the number of tapes the ship could carry a crew of perhaps 3 people would spend all day and night changing the tapes. The machine would cycle between 2 or 3 drives. When they got back to land, the tapes would be taken to the processing center where the giant computers lived.
From: Paul Keinanen on 12 Jun 2010 14:09 On Sat, 12 Jun 2010 09:56:27 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >Way back in the tape drive days, seismic systems wrote their data >onto tape. They servoed the speed of the drive so that the ADC >output would be matched so that ony a very little buffering was >needed. For marine surveys, the length of time a ship could stay >at sea was set by the number of tapes the ship could carry a crew >of perhaps 3 people would spend all day and night changing the >tapes. The machine would cycle between 2 or 3 drives. I have never used 1200 BPI tapes, but at least the 800 BPI systems were extremely picky about keeping the read/write heads perpendicular to the tape motion. With multiple writing drives, you really had to keep the heads aligned the same way on all drives, unless you wanted to realign the read head after each tape :-) At 1600 BPI, each tape channel was individually clocked, so there was not so much need to keep the R/W head aligned.
From: MooseFET on 13 Jun 2010 10:52
On Jun 13, 2:09 am, Paul Keinanen <keina...(a)sci.fi> wrote: > On Sat, 12 Jun 2010 09:56:27 -0700 (PDT), MooseFET > > <kensm...(a)rahul.net> wrote: > >Way back in the tape drive days, seismic systems wrote their data > >onto tape. They servoed the speed of the drive so that the ADC > >output would be matched so that ony a very little buffering was > >needed. For marine surveys, the length of time a ship could stay > >at sea was set by the number of tapes the ship could carry a crew > >of perhaps 3 people would spend all day and night changing the > >tapes. The machine would cycle between 2 or 3 drives. > > I have never used 1200 BPI tapes, but at least the 800 BPI systems > were extremely picky about keeping the read/write heads perpendicular > to the tape motion. > > With multiple writing drives, you really had to keep the heads aligned > the same way on all drives, unless you wanted to realign the read head > after each tape :-) > > At 1600 BPI, each tape channel was individually clocked, so there was > not so much need to keep the R/W head aligned. There were lots of odd sorts of drives in the early days: There were also the drives called "incremental" drives where the tape was moved by a stepper. Each bit group was recorded on command. There are "analog" drives that where basically audio tape recorders. Some of these were FM where the signal was modulated onto a carrier. Some used other modulations. There were tapes with strange numbers of tracks like 13 and 25. |