The future of CPU based computing, mini clusters.
|
Prev: Maximum ammount of local variables in cg shaders ?
Next: Online Exams for Certification, Free Practice Exams, Study Material, Dumps
From: ChrisQ on 30 Oct 2009 07:55 nmm1(a)cam.ac.uk wrote: > > It depends slightly on what you mean by "embedded". Some people > classify the CPUs that go in printers and control aircraft as that. That's correct and embedded devices are already far more powerfull than 486 class x86 in terms of throughput. They have on chip ram, flash and moderately high speed comms as well as other peripherals. Assume an array of such devices, assigned a single thread each, there would be no need for cache and interrupt requirements would be minimal. How usefull would this be, assuming future developments could put enough code space on chip and the comms problem between an allocation cpu and the array could be solved ?... Regards, Chris
From: nmm1 on 30 Oct 2009 08:05 In article <wuAGm.13862$1i2.8738(a)newsfe07.ams2>, ChrisQ <meru(a)devnull.com> wrote: > >> It depends slightly on what you mean by "embedded". Some people >> classify the CPUs that go in printers and control aircraft as that. > >That's correct and embedded devices are already far more powerfull than >486 class x86 in terms of throughput. They have on chip ram, flash and >moderately high speed comms as well as other peripherals. > >Assume an array of such devices, assigned a single thread each, there >would be no need for cache and interrupt requirements would be minimal. >How usefull would this be, assuming future developments could put enough >code space on chip and the comms problem between an allocation cpu and >the array could be solved ?... Very, for suitable applications. But most existing ones would need redesigning :-( Regards, Nick Maclaren.
From: Mayan Moudgill on 30 Oct 2009 08:56 ChrisQ wrote: > nmm1(a)cam.ac.uk wrote: > >> >> It depends slightly on what you mean by "embedded". Some people >> classify the CPUs that go in printers and control aircraft as that. > > > That's correct and embedded devices are already far more powerfull than > 486 class x86 in terms of throughput. They have on chip ram, flash and > moderately high speed comms as well as other peripherals. > > Assume an array of such devices, assigned a single thread each, there > would be no need for cache and interrupt requirements would be minimal. > How usefull would this be, assuming future developments could put enough > code space on chip and the comms problem between an allocation cpu and > the array could be solved ?... > > Regards, > > Chris Think transputer (on a chip, of course)
From: "Andy "Krazy" Glew" on 30 Oct 2009 23:20 ChrisQ wrote: > nmm1(a)cam.ac.uk wrote: > >> >> It depends slightly on what you mean by "embedded". Some people >> classify the CPUs that go in printers and control aircraft as that. > > That's correct and embedded devices are already far more powerfull than > 486 class x86 in terms of throughput. They have on chip ram, flash and > moderately high speed comms as well as other peripherals. > > Assume an array of such devices, assigned a single thread each, there > would be no need for cache and interrupt requirements would be minimal. > How usefull would this be, assuming future developments could put enough > code space on chip and the comms problem between an allocation cpu and > the array could be solved ?... The way to get enough code space for meaningful programs is... to have an I$. Nick will probably say otherwise, from his massive experience, but guys at the world's largest supercomputer customers contain this for me. It's easier to deal with limited dates many than it is with codesize lustrations and overlays, where line change can blow you out. Although... I'm not so sure that data cache may not be worthwhile. Perhaps not coherent caches; perhaps not strong memory ordering.
From: "Andy "Krazy" Glew" on 30 Oct 2009 23:25
nmm1(a)cam.ac.uk wrote: > In article <wuAGm.13862$1i2.8738(a)newsfe07.ams2>, > ChrisQ <meru(a)devnull.com> wrote: >> How usefull would this be, assuming future developments could put enough >> code space on chip and the comms problem between an allocation cpu and >> the array could be solved ?... > > Very, for suitable applications. But most existing ones would need > redesigning :-( And since programmer productivity is more after the battered, how likely is this to happen? Perhaps it will hopper as programmer pay falls , because of globalization and the recession. |