On Tue, 2007-04-17 at 10:24 -0400, Chris King wrote:
> On 4/17/07, skaller <[EMAIL PROTECTED]> wrote:
> > An example: folds and STL style iterators are control
> > inverse. Iterators rock for users -- folds suck big time.
> > Folds rock for implementors -- iterators suck for implementors.
>
> Ah, I see what you're getting at; sorry, I thought you meant more on
> the level of component manipulation, not control flow.
What's the difference? A computer is like Einsteinian space/time:
you can't divorce space (where data/code lives) and time.
Action (execution, behaviour) is the sequence of spaces differentials
over time, aka event trace.
The key thing about the Felix microthreading model is that
components are ACTIVE: they're simultaneously data and
control packages.
Active means they're control masters not slaves like
functions, channels invert control, so two masters
can actually work together. The implementation however
is entirely passive/reactive: they're objects with callbacks.
but you can still write functions too. That's the key thing.
The design allows both, in fact you can use functional, procedural,
object oriented or chip oriented programming styles.
I hope to add better support for parallelism too -- rather hard
when my big machine is a dual core .. way too few cores to do
any real performance experiments.
> Well, O'Caml does have streams... but even then you're forced to route
> the control through a function,
yes, which means they're not real streams.
> I presume Python's generators meet your requirements? They were one
> of the few features I greatly missed when switching to O'Caml from
> Python.
Python generators (which Felix copied to some extent) do part
of the job.
A 'chips and wires' viewpoint makes generators sources.
Felix has them too .. it's a bit nasty, but there
is a
yield expr;
statement in Felix, same as return except the next
call through that closure resumes after the yield.
So generators are a hack: they're chips with ONE output,
namely the 'return value'. They don't do what fibres
and channels do: allows writing (or reading) any accessible
channel, that is, demultiplexing.
> I always thought though that there should be a way to multithread
> generators... i.e., allow the generator, after a yield, to continue
> running in parallel with the calling code, and buffer X values.
Stackless Python has been able to do that for ages. Generators
are based on it, but they didn't go the whole way for the
same reason Felix can't interleave function execution:
the C stack gets in the way.
Stackless Python throws out the machine stack, which destroys
C compatibility.
Felix procedures use heap stack frames to work around this.
> Disregarding the fact that Python has a global interpreter lock, you
> could achieve this by having one function which runs in a separate
> thread and continually fills a queue with values from the generator,
> and another function which is a generator that yields values from the
> queue (and blocks if the queue is empty).
Yes indeed: threads provide control inversion by making the
operating system swap machine stacks.
Felix fibres are a weaker (non-preemptive) version of this,
which are more lightweight and context switch faster.
The weakness -- non-pre-emption -- is what delivers the
performance, and should also be amenable to simple optimisations
which would be harder with genuinely concurrent code.
> Certainly you can do the same thing in Felix, and because Felix
> doesn't have a silly global lock the generator would actually run in
> parallel with the calling code; what's more, you could abstract this
> to run across the network...
>
> I think you're on to something good here :)
Erlang can already do the 'across the network' stuff.
Not perfect I'm told, but it exists.
It remains to be seen how much of the modelling can
be abstracted with typeclasses .. so for example
you can write process/message passing code which
works across network OR using pthread OR using
fibres OR using even plain procedures.
Systems that can do this level changing exist,
for example you can do it with MPI, but only
in a crude way. I think Erlang is actually much
better at this .. but it doesn't provide the
more specialised lower level model enriched
by shared memory.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
