Fare's response on threads

[Francois-Rene Rideau]

Dear Tunesers,
   my previous message spread some doubt among you, and
it looks like I haven't been clear enough. Let me expound.

On Sat, Sep 16, 2000 at 10:19:04PM -0700, Lynn H. Maxson wrote:
> the system and what is does is not independent of the
> telling thereof.
Sure. But this doesn't mean we have to always have precise understanding
of all the details of what the system will do about what we tell it.
Just like we have compilers precisely so that we do not have to understand
the precise register scheduling and memory spilling constraints.
Just like we can program genetic algorithms
without knowing the outcome in advance:
the ultimate behaviour of the system emerge from the way we program it,
within the specifications we declare.

In the case of threading mechanisms, this means
that we can expect the system, _once it grows elaborate enough_,
to automatically select threading tactics depending upon
a wide body of information about all the threads:
are there many threads? how often do they switch?
do they share a lot of state? do they have the same calling conventions?
do they trust each other to respect resource access conventions?
Won't such or such task predictably finish in finite time?
Is there a lot of frequently-accessed thread-specific state?
Does the hardware allow fast page map or segment switching?
How much does it cost to modify code in an individual function?
How big are instruction and data caches?
Are calling stacks deep? etc.

Depending on these criteria (and many others), threads can be grouped,
and individually implemented using appropriate tactics. Selecting
the right tactic can be done much faster by the machine than by the human;
with a decent heuristics, in most case, the results of such a dynamic choice
would outperform any static choice done by even the best programmer
with a lot of time. And if perchance the machine errs, the human can help it,
with simple or elaborate hints, so that, to anti-phrase the Assembly-HOWTO,
	"The computer should always win, because it can use the human".

Jacques Pitrat and his disciples, with whom I spent half of last week,
have been developing a lot of such systems with behaviour
emerging from monitoring with meta-rules. Unhappily,
J.-L. Laurière has stopped developing ALICE (or anything) for years,
while J. Pitrat's MACISTE is kind of an autistic reflective system;
we still have T. Cazenave's go player, but it's purely compile-time
metametaprogrammed, not runtime monitored.
[BTW, one of the people I met there has an interesting page at dormoy.org].

Anyway, the fundamental theorem of reflective systems,
their raison d'être, applies:
	"In a reflective system, any repetitive task can be automated."
So the question is: "is there anything repetitive
about selecting thread implementation for a given program?".
If there is, as I believe, then some metaprogram may help choose.
Oh, and of course, turning knobs and doing lots of testing until
the optimal parameters are found, IS a repetitive task,
best achieved during the night by some kind of genetic algorithm or
simulated annealing.

> [...] cross the line from deterministic to free will [...]
There is a lot of things to do that are
beyond human-deterministic (i.e. something a human can actually determine)
and before free will (i.e. something that a human will admit matches him).

> I may have missed it,
> but so far I have seen no example of software capable of producing
> higher-level abstractions on its own nor of finding reusable
> patterns of logical equivalent objects.
You have missed it.
People like Jacques Pitrat or Doug Lenat have experimentally shown
such pattern generation in expert systems with meta^n rules.
In another field, some have also successfully devised theoretical
and practical applications of Kolmogorov Complexity to extract patterns
out of large bodies of data, which have been used in data-mining.
Also, genetic algorithms have allowed many computer scientists to generate
unexpected practical solutions to many problems from lower-level noise.

All in all, I don't pretend that TUNES will have much "intelligence" in it;
at least, for the few beginning years.
Until it is bootstrapped, stabilized, and grown quite a bit,
it will show no sign of intelligence whatsoever.
But I do envision TUNES as a framework to enable subsequent AI works.
And even in the early years, things will be done in declarative ways
that favor metaprogramming and allow it
to grow more elaborate as needs arise,
without disrupting service.

Yours freely,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
"Actually a person does not _really_ understand something until teaching
it to a _computer_, i.e. expressing it as an algorithm." D.E. Knuth.