[ILUG] Re: Number crunching

[Declan Moriarty]

Was it Niall O Broin who wrote on Friday 15 March 2002 17:27:
> On Fri, Mar 15, 2002 at 02:05:53PM +0000, Nick Murtagh wrote:
> > On Friday 15 March 2002 13:15, Ferren MacIntyre wrote:
> > > Given the difficulty of using dual processors efficiently, is there a
> > > low-overhead way of dedcating one to background number crunching, while
> > > the foreground one does the lesser tasks of word- and image-processing?
> > >  I've never had any problem keeping 2 computers gainfully employed in
> > > that mode.
> >
> > There's a CPU affinity patch floating around that lets you nail specific
> > processes to a CPU... in theory though a good scheduler should take care
> > of that sort of thing automatically.
>
> That was going to be my answer, but I think what Ferren would like to do
> (sorry if I'm putting words in your mouth here, Ferren) would be to have a
> dual processor machine (hence cutting down on what's on/around his desk)
> whereby he could DEDICATE one processor to his stonking big numerical
> problem, while the other processor was used for his day to day stuff i.e.
> so that he'd have effectively have a single processor machine with a second
> processor dedicated to his numerical problem. I don't think that there's
> any way of getting a normal scheduler to do that. Probably the best you
> could do would be to nice -20 the numerical process in conjunction with CPU
> affinity patches.

The answer to at least some of these problems was dreamt up for a different 
time (The time of 20Mhz z80s). Sinclair (of ZX81, & Spectrum fame) , 
envisioned and tried to develop with some British University a system which 
had a very fast internal core with its own code, multitasking to  several 
slower peripheral buses. They tried to use builtin microcode in their core 
cpu and failed to write it. The idea was that the internal bus was hopelessly 
faster than anything outside, but it had ram on one bus, video, hd, & printer 
on others with huge caches. It would keep them fed with data

Now we have linux, and Beowulf, and ASICs, and cheap motherboards and memory. 
In hardware, you could have the processor core of your choice, and use 
motherboards (complete with their own ram) as cheaply available 
caches/peripheral drivers. The central core processor(s) could use 
surprisingly conventional software, with a similar driver for each output. 
Add a fairly transparent ASIC to handle communication between the core cpu 
and the motherboards talking at 133 MHZ or more on the ram bus. Thinking 
about this, MAC PPC boards might well do better than PC ones - less hamstrung 
(A20 nonsense, etc) to work with, and scsi out.  It may even be possible to 
interconnect via the DIMM socket for the most part.

That arrangement would provide what you all are wishing for (Highly efficient 
core, rapid communications, at the expense of having processors in the cache 
stage doing no real work. The op system (Linux/Beowulf) is already there. 
Who's got a few million to fund all this and we can build it ;-)?
-- 
	Regards,


	Declan Moriarty




Applied Researches - Ireland's Foremost Electronic Hardware Genius

	A Slightly Serious(TM) Company

Experience is like a comb, 
that Life gives you - AFTER all your hair has fallen out!