a few queries

[Ben Lindstrom]

On Mon, 2 Dec 1996, Francois-Rene Rideau wrote:

[removed non-required information]

> > as far as parallelism goes, exactly what parallel model do you support?  it
> > sounds like you advocate something like a connection machine style model. .
> >
> If you mean about the size of
> If you're talking about network geometry,
> Anyway, I don't have any certain off-hand answer about that.
> What I'm sure is that it is much more worth to invest in
> better parallel software than in more bloated sequential hardware.
> 
Problem that has been proven again and again with software-based parallelism
only for multiply processors is you hit the max possiable useage of 
processors very quick.  (Not, I don't claim MS/Linus/Solaris is the greatest
but without SMP standard hardwar implementation they would be less effecent)

You are required to do some special hardware design to support multiply 
CPUs.  Granted our current SMP designs for Intel are major hacks, but on most
multiply processor based systems (non-Intel) have some special 
motherboard/CPU designs.


> > . in any event, using large-scale parallelism well is another hard problem.
> > . . especially given that these days the speed of the processor is vastly
> > faster than the speed of the routing network.  sure, it would appear that
> > parallel processing is a winner, but there are a lot of problems for which
> > it is not at all clear how to split the problem up. . .
> >
> Most of the problems we know are easily parallelizable:
> number crunching, database management, expert systems,
> robot control.
> As for it not being clear how to split up problems,
> this precisely calls for languages where you can tweak
> the way the implementation splits things up
> without changing the behavioral semantics of your program.
> Hence, cleanly reflective high-level language
> using formal verification methods.
Actually..There is a second way..I believe it's SGI (please correct my if
I'm wrong) has a post-processors  that takes low-level code from any compiler
and breaks it into better threading for there CPUs.  It might not the best 
solution, but it can be partial proven in most cases.  


 >    What's the use of a faster sequential machine
> when you'll be using it to run multiple tasks in parallel?
> Surely, there are intrinsically sequential problems,
> for which there will ever remain the need for faster specialized
> sequential processors (even then, bloat does not mean speed gain);
> but this should stay the small niche it is.
> 
> > i'm not trying to attack you so much as point out my uneasiness with your
> > rather glib discussions of issues that don't appear to me to be at all
> > trivial.
>    I'm not saying that implementing Tunes is trivial.
> I'm saying that choosing to invest in Tunes ideas
> rather than traditional ideas is a trivial choice,
> once you know these ideas.
>    Well, at least, I'm yet to find a valid opposite argument to that,
> which will be most welcome. Up to now, the arguments I've faced
> would help me make my theories cleaner and remove bugs from them.
> 
BTW, I started looking into OCML...And I have to admit that is worse for 
syntax then C and is more confusing then C in a lot of respects.  I've only
been through some of it, and the OO part of it looks a lot like C++ =).