[LLVMdev] Re: idea 10

["?=Valery A.Khamenya=?koi8-r?Q?"]

> Interesting email address there :)
> On Thu, 2004-01-08 at 01:18, =?koi8-r?Q?=22?=Valery
> A.Khamenya=?koi8-r?Q?=22=20?= wrote:

unfortunally some email parsers and email clients deny to work correctly with international conventions :(
follow this URL for more details:
http://www.python.org/doc/current/lib/module-email.Header.html
 
> On the same machine, LLVM definitely needs to support both symmetric and
> asymmetric multi-processing. I believe some primitives to support this
> are being worked on now by Misha. However, I don't really consider this
> "distributed systems" because distribution by a few inches doesn't
> really amount to much. In my way of thinking distributed computing
> *always* involves a network.

you are right, but bigger steps after smaller ones?
let's agree with a simple things and then we could 
proceed (and probably die) with networking case.
 
> Okay, this kind of "distribution" (what I call parallel computing)

(see above)

> should also definitely be supported by LLVM. There are several
> primitives that could be added to LLVM to enable compiler writers to
> more easily write parallel programs. However, I don't think LLVM should
> get involved in parallel programs that run on multiple computers, only a
> single computer (possibly with multiple CPUs).

Oh, we agreed to a single host so soon? :)


> > Is it OK up to here and I could continue using this 
> > model example?
> 
> Yes, but I think the confusion was simply one of terminology. What
> you're talking about is what I call parallel computing or
> multi-processing (symmetric or asymetric). 

(see above again).

> This isn't really distributed computing although 
> one could think of the operations being "distributed"
> across several CPUs on the _same_ computer.

(people speaking about distributed computations even in 
more boring context: "one has transfered stand-alone 
application to a remote PC, executed it, and this already 
mean distributed computation").

My idea was to consider Fib example for a single PC with several CPUs and when you are agreed that it makes sense to bring notion of CPU in LLVM layer, i should ask you: "Raid, why should we restrict ourselves with _single_ PC only ?!"

> 
> Okay, now you're talking about "hosts" which I take to mean separate
> physical computers with the only way for the "hosts" to communicate is
> via a network. Is this what you mean by "host"?

We could restrict ourselves to notion of host as in http://www.faqs.org/rfcs/rfc1.html and later RFCs for 
TCP/IP.

> No, we don't. Distributed computing would be built on top of LLVM (in my
> opinion). But, we _do_ need support for parallel or multi-processing
> computation as you described above (again, on a single physical
> computer).

wait, let's fix your elrier statement. As far as I understood 
you do agree that case of multiple CPUs on a _single_ host 
should be supported at LLVM layer. Right?

as I see from here:

> okay .. again, this isn't "distributed", just "parallel", and I agree
> its needed.

you call this case just "parallel" and agree.

> I would tend to agree. I fully expect LLVM to fill the mission that Java
> started: ubiquitous computing. I would expect to see LLVM programs
> running on everything from gameboy to supercomputer, possibly with
> kernel support.

"possibly with kernel support" is kind of crutch to get supercomputer with networking architecture ;)

Reid, couldn't you agree that networking is only a particular interface to get an access to others CPUs? 

why should then LLVM be abstracted from suppercomputers with 
CPU distributed over network?

All benefits, what one could obtain from "LLVM supporting multiple CPU at single host", one might obtaine from "LLVM supporting multiple CPU at multiple hosts". Isn't that logical?


> I've toyed with the idea of a Linux kernel module for
> LLVM already. [...]

then even easier to speak :) 
 
> Nothing at this point. I think I realize where you're coming from now
> and agree that _parallel_ computing is a very important next step for
> LLVM.  Let's see what happens with the current work on synchronization
> and threading primitives. These things will be needed to support the
> kind of parallelization you're talking about.

Right.

...I almost hear the thoughts from Chris: 
"guys, instead of trolling about cool things make something cool!"
;)

--
Valery