[Dce-users] Re: Other thoughts for areas of consideration

[Stephen T. <s....@la...>]

On Wed, 30 May 2001, Frank V. Castellucci wrote:

> Stephen,
>
> I went through your paper (but not with a critical eye as I am tired
> tonight) and a couple of things immediatley jumped out at me:
>
> 1. This is familiar in it's analogy to workload balancing concepts
> 2. This is familiar to work distribution systems (e.g. SETI)

Yes. The initial idea came from distributed.net. I looked at how they took
a large block of work and broke it into individual pieces that people
could work on.

> 3. A difficulty to overcome (hence an opportunity <grin>) is in knowing
> what granularity you can define as a work unit. Is it a source module?
> How do you resolve reference dependencies?

At present the system considers a work unit as an individual file to be
compiled. For example a slave might get the file called "main.c" and
compile that per the command given. If for example the slave get the
command for linking an object file (main.o) and main.o does not exist it
fails. There was no time in developing it to deal with this. I am sure its
a simple solution (grin) but will look it over.

> 4. Is this limited to GCC technology?

No. All commands that are sent are strings so anything could be written
in the string. I though of the following areas with a friend:

- Compiling (has been tried he said but his friend said they failed)
	- At present I only tried to compile C & C++ programs that
	  typically run on Linux. I am sure that if the compiler
	  logic or use of a cross-compiler other languages could be
	  dealt with by the system.
- Rendering (3D Movies, 3D graphics, etc.)
- Genetics (Protein folding)
- Cryptography (Distributed.net)

Anything that typically takes a long time and broken into bits was what I
was looking at here. Compiling was a "proof of concept".

> In other words, again with Facade
> in mind, can each of the "compiler" logical components be interchanged
> so that the front end token and parse can be language specific but the
> emitter and optimizing phases be input language independent?

I do not know. Personally I have never dealt with the actual compiler
internals. Sounds interesting. Could give me an example.

> Neat application of some of the familiar/similar concepts by the way.

Thanks. It encouraging to hear this. So far people have felt that either
it was not useful (a few) but others said is sounds great but not sure
where to use it. Where to use it is what I hope to answer.

Stephen