a few queries

[Francois-Rene Rideau]

>>: Fare Rideau
>: Ben Lindstrom

>> 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)
>
Uh? You mean when dumbly running coarse-grained sequential programs
on SMPs, like Unices do?
Sure. To take advantage of a parallel architecture,
you shouldn't just have it emulate sequential architecture.
You should compile specifically for your parallel target.
This again mean that code generation should not be done statically,
and that code interchange formats should be high-level, not low-level.

> 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.
>
Special hardware designed is only required to emulate
transparent shared memory.
Again, this is the same kind of bloat
as seen when emulating Von Neumann architecture:
they start from a theory that does not fit reality,
and have reality emulate it at high cost.
For the price of a shmem board,
you could have a much more powerful connection-machine-like board,
with processors much faster that could pipe data faster
than the shared memory processors would read from shared mem.

>> 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.
>
Post-processing precompiled code, specializing it
for a particular target is NOT a second way.
That's precisely what I say,
only most people don't do it in a reflective way:
you can't efficiently control the way code is split,
just having their hardwired way;
if that does suit you, so far so good;
else, you must do it yourself from scratch.
   BTW, I think the SGI stuff you're seen
is the assembly-code scheduler for the MIPS architecture,
that reorders assembly code (also inserting NOPs when needed)
to take advantage of the internal parallelism
of their various multi-pipelined CPUs.
The MIPS acronym means that it is not the hardware that
schedules the pipeline, but the software.

> 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.
Uh? How that worse than C?
It has a much more regular syntax.
I'm sure the OCAML grammar is much shorter than a C grammar.
And OCAML is more expressive, too!

> I've only
> been through some of it, and the OO part of it looks a lot like C++ =).
>
Look like. The difference is that OCAML has a clean type system,
whereas the C++ stuff is just a hack.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"