Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Martin Brown on 8 Aug 2008 05:03 John Larkin wrote: > On Thu, 07 Aug 2008 14:51:57 GMT, Jan Panteltje > <pNaonStpealmtje(a)yahoo.com> wrote: > >> On a sunny day (Thu, 07 Aug 2008 07:08:52 -0700) it happened John Larkin >> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >> <d10m94d7etb6sfcem3hmdl3hk8qnels3kg(a)4ax.com>: >> >>>> Been there - done that :-) >>>> >>>> That is precisely how the early SMP systems worked, and it works >>>> for dinky little SMP systems of 4-8 cores. But the kernel becomes >>>> the bottleneck for many workloads even on those, and it doesn't >>>> scale to large numbers of cores. So you HAVE to multi-thread the >>>> kernel. >>> Why? All it has to do is grant run permissions and look at the big >>> picture. It certainly wouldn't do I/O or networking or file >>> management. If memory allocation becomes a burden, it can set up four >>> (or fourteen) memory-allocation cores and let them do the crunching. >>> Why multi-thread *anything* when hundreds or thousands of CPUs are >>> available? >>> >>> Using multicore properly will require undoing about 60 years of >>> thinking, 60 years of believing that CPUs are expensive. Thinking multicore properly might yield some advantages on certain types of problem. But these are not the sort of problems most domestic users of PCs actually have. It could be useful for 3D gaming, but even there it still makes sense to split the load across specialised dedicated video CPUs using fancy memory and generics doing the grunt work. >> Ah, and this all reminds me about when 'object oriented programming' was going to >> change everything. >> It did lead to such language disasters as C++ (and of course MS went for it), >> where the compiler writers at one time did not even know how to implement things. >> Now the next big thing is 'think an object for every core' LOL. >> Days of future wasted. >> All the little things have to communicate and deliver data at the right time to the right place. >> Sounds a bit like Intel made a bigger version of Cell. >> And Cell is a beast to program (for optimum speed). > > Then stop thinking about optimum speed. Start thinking about a > computer system that doesn't crash, can't get viruses or trojans, is > easy to understand and use, that not even a rogue device driver can > bring down. How exactly does your wonder architecture prevent the muppet at the keyboard clicking on the canonical Trojan that starts two new threads and grabs IO and memory resources at random? Oh it dies when the number of processes running N > 1024 (about 10x start process latency after he hits return). Fabulous! The only way your idea will satisfy your idealised goals is if it remains in fantasy land. Once you apply power it is vulnerable to all the usual human factors Trojan attacks no matter how robust the hardware. > > Think about how to manage a chip with 1024 CPUs. Hurry, because it > will be reality soon. We have two choices: make existing OS's > unspeakably more tangled, or start over and do something simple. There are tight robust OSs but Windows is not one of them. On the desktop Linux is a lot closer, and the Apples OS X is pretty good too. And IBM's ill fated OS/2 was good in its day (sadly 'Doze won). The PC world could easily have been different had technological superiority won the day (instead of glizty GUI froth and BSODs). When you have 1024 CPUs you have 1024x1023 (virtual) communications paths to other CPUs. Unless you are very careful it is easy to end up with interprocess communications that are like wading through treacle. You might find the following research article interesting. http://www2.lifl.fr/west/publi/MDL+07frontiers.pdf Connexion machine at MIT goes back to the early 80's and was influenced by Lisp in its early incarnations. http://en.wikipedia.org/wiki/Connection_Machine > > Speed will be a side effect, almost by accident. If you really think large numbers of CPUs will give some advantage in home computers why not write a program to emulate them using the latest Pentium virtualisation instructions. There may already be an academic implementation of this model - I haven't looked. It would be useful for teaching purposes if nothing else. And it might help disabuse you of some of your wilder notions on this subject. Regards, Martin Brown ** Posted from http://www.teranews.com **
From: Bernd Paysan on 8 Aug 2008 07:02 Nick Maclaren wrote: > In theory, the kernel doesn't have to do I/O or networking, but > have you ever used a system where they were outside it? I have. Actually, doing I/O or networking in a "main" CPU is waste of resources. Any sane architecture (CDC 6600, mainframes) has a bunch of multi-threaded IO processors, which you program so that the main CPU has little effort to deal with IO. This works well even when you do virtualization. The main CPU sends a pointer to an IO processor program ("high-level abstraction", not the device driver details) to the IO processor, which in turn runs the device driver to get the data in or out. In a VM, the VM monitor has to sanity-check the command, maybe rewrites it ("don't write to track 3 of disk 5, write it to the 16 sectors starting at sector 8819834 in disk 1, which is where the virtual volume of this VM sits"). The fact that in PCs the main CPU is doing IO (even down to the level of writing to individual IO ports) is a consequence of saving CPUs - no money for an IO processor, the 8088 can do that itself just fine. Why we'll soon have 32 x86 cores, but still no IO processor is beyond what I can understand. Basically all IO in a modern PC is sending fixed- or variable-sized packets over some sort of network - via SATA/SCSI, via USB, Firewire, or Ethernet, etc. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
From: Jan Panteltje on 8 Aug 2008 07:30 On a sunny day (Fri, 08 Aug 2008 13:02:15 +0200) it happened Bernd Paysan <bernd.paysan(a)gmx.de> wrote in <nmltm5-4hq.ln1(a)annette.zetex.de>: >Nick Maclaren wrote: >> In theory, the kernel doesn't have to do I/O or networking, but >> have you ever used a system where they were outside it? I have. > >Actually, doing I/O or networking in a "main" CPU is waste of resources. Any >sane architecture (CDC 6600, mainframes) has a bunch of multi-threaded IO >processors, which you program so that the main CPU has little effort to >deal with IO. > >This works well even when you do virtualization. The main CPU sends a >pointer to an IO processor program ("high-level abstraction", not the >device driver details) to the IO processor, which in turn runs the device >driver to get the data in or out. In a VM, the VM monitor has to >sanity-check the command, maybe rewrites it ("don't write to track 3 of >disk 5, write it to the 16 sectors starting at sector 8819834 in disk 1, >which is where the virtual volume of this VM sits"). > >The fact that in PCs the main CPU is doing IO (even down to the level of >writing to individual IO ports) is a consequence of saving CPUs - no money >for an IO processor, the 8088 can do that itself just fine. Why we'll soon >have 32 x86 cores, but still no IO processor is beyond what I can >understand. > >Basically all IO in a modern PC is sending fixed- or variable-sized packets >over some sort of network - via SATA/SCSI, via USB, Firewire, or Ethernet, >etc. Do not forget, since the days of 8088, and maybe CPUs running at about 13 MHz, we now run at 3.4 GHz, 3400 / 13 = 261 x faster. Also even faster because of better architectures. This leaves plenty of time for a CPU to do normal IO. And in fact the IO has been hardware supported always. For example, although you can poll a serial port bit by bit, there is a hardware shift register, hardware FIFO too. Although you can construct sectors for a floppy in software bit by bit, there is a floppy controller with write pre-compensation etc.. all in hardware. Although you could do graphics there is a graphics card with hardware acceleration. the first 2 are included in the chip set, maybe the graphics too. The same thing for Ethernet, it is a dedicated chip, or included in the chip set, taking the place of your 'IO processor'. Same thing for hard disks, and those may even have on board encryption, all you have to do is specify a sector number and send the sector data. So.. no real need for a separate IO processor, in fact you likely find a processor in all that dedicated hardware, or maybe a FPGA.
From: John Larkin on 8 Aug 2008 10:40 On Fri, 08 Aug 2008 11:30:04 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Fri, 08 Aug 2008 13:02:15 +0200) it happened Bernd Paysan ><bernd.paysan(a)gmx.de> wrote in <nmltm5-4hq.ln1(a)annette.zetex.de>: > >>Nick Maclaren wrote: >>> In theory, the kernel doesn't have to do I/O or networking, but >>> have you ever used a system where they were outside it? I have. >> >>Actually, doing I/O or networking in a "main" CPU is waste of resources. Any >>sane architecture (CDC 6600, mainframes) has a bunch of multi-threaded IO >>processors, which you program so that the main CPU has little effort to >>deal with IO. >> >>This works well even when you do virtualization. The main CPU sends a >>pointer to an IO processor program ("high-level abstraction", not the >>device driver details) to the IO processor, which in turn runs the device >>driver to get the data in or out. In a VM, the VM monitor has to >>sanity-check the command, maybe rewrites it ("don't write to track 3 of >>disk 5, write it to the 16 sectors starting at sector 8819834 in disk 1, >>which is where the virtual volume of this VM sits"). >> >>The fact that in PCs the main CPU is doing IO (even down to the level of >>writing to individual IO ports) is a consequence of saving CPUs - no money >>for an IO processor, the 8088 can do that itself just fine. Why we'll soon >>have 32 x86 cores, but still no IO processor is beyond what I can >>understand. >> >>Basically all IO in a modern PC is sending fixed- or variable-sized packets >>over some sort of network - via SATA/SCSI, via USB, Firewire, or Ethernet, >>etc. > >Do not forget, since the days of 8088, and maybe CPUs running at about 13 MHz, >we now run at 3.4 GHz, 3400 / 13 = 261 x faster. >Also even faster because of better architectures. >This leaves plenty of time for a CPU to do normal IO. >And in fact the IO has been hardware supported always. >For example, although you can poll a serial port bit by bit, there is a hardware shift register, >hardware FIFO too. >Although you can construct sectors for a floppy in software bit by bit, there is a floppy controller >with write pre-compensation etc.. all in hardware. >Although you could do graphics there is a graphics card with hardware acceleration. >the first 2 are included in the chip set, maybe the graphics too. >The same thing for Ethernet, it is a dedicated chip, or included in the chip set, >taking the place of your 'IO processor'. >Same thing for hard disks, and those may even have on board encryption, all you >have to do is specify a sector number and send the sector data. > >So.. no real need for a separate IO processor, in fact you likely find a processor >in all that dedicated hardware, or maybe a FPGA. > That's the IBM "channel controller" concept: add complexm specialized dma-based i/o controllers to take the load off the CPU. But if you have hundreds of CPU's, the strategy changes. John
From: Jan Panteltje on 8 Aug 2008 10:57
On a sunny day (Fri, 08 Aug 2008 07:40:53 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <bkmo94dhicn8ipk013mfn8cnf4u9rlm5uh(a)4ax.com>: >That's the IBM "channel controller" concept: add complexm specialized >dma-based i/o controllers to take the load off the CPU. But if you >have hundreds of CPU's, the strategy changes. > >John Ultimately you will have to move bytes, from one CPU to the other, or from dedicated IO to one CPU, and things have to happen at the right moment. Results will never be available before requests...... It is a bit like Usenet: (smile), there are many 'processors' (readers. posters, lurkers) here, some output some data at some time in response to some event, could be a question, others read it, later, much later perhaps, see the problem? Watched the Olympic opening, I must say the Chinese make a beautiful event. Never got boring, the previous one was ugly and not worth looking at, but anyways, so many LEDs? And some projection! Seems they are ahead in many a field. Would you not be scare to death if you were a little girl hanging 25 meters above the floor from some steel cables..... Chinese are brave too :-) |