Hi Dale,
You are right, that's a mistake in the paper. You should switch
start-0 and start-1 on the top branch. Believe it or not, I did not
write this section :) It's not really about Nile, but about dataflow
in Nothing.
In fact, beware of the sentences The way the Nile runtime works was
generalized. Instead of expecting each kernel to run only when all of
its input is ready, then run to completion and die, the Nothing
version keeps running any kernel that has anything to do until they
have all stopped [1]. It makes it sound like Nile runtimes in general
wait for all the input to be ready before running a process. This is
only true of the Squeak and Javascript versions of the Nile runtime.
The C-based multithreaded one does not. Sorry I didn't catch this
before publication.
Regardless, the Nothing work strayed a bit from the Nile model of
computation, and not in directions I would take it, so don't take too
much about Nile from that section. Also, I wouldn't advocate writing
Fibonacci like this in Nile. Nile was designed for coarse-grained
dataflow, not fine-grained dataflow.
The main reason for this was my opinion that 1) mathematical
statements are often more readable than their visual, fine-grained
dataflow equivalents* and 2) coarse-grained dataflow can be quite
readable due to fewer communication paths, and thus easier
composition, and in many cases they contain only a simple
left-to-right flow.
On top of that, is it easier to efficiently parallelize coarse-grained
dataflow because the communication between components is much less,
allowing parallel hardware to operate more independently.
[1] For very simple statements, this may not be so true, but when
scaling up to more practical examples, I think fine-grained dataflow
gets messy fast.
Regards,
Dan
On Wed, Nov 9, 2011 at 6:45 AM, Dale Schumacher
dale.schumac...@gmail.com wrote:
Thanks for disseminating the latest report. It is, as always, an
inspiration to see all the fine work being done. I can hardly wait to
play with the final system, and perhaps extend and build on it.
One of the first things I did was re-create (in Humus) the Fibonacci
Machine from the Nile data-flow model. I think that the start-0 and
start-1 processes in the upper branch (b1, b2, b3) should be
reversed. It seems that the add process should first receive 0
(from b3) and 1 (from b5), then the 1 from b2 can be forwarded
and combined with the 1 from the feedback loop (b7). I like how the
pair of forwarders in the upper branch form a kind of delay-line
effect to stagger the previous and next results.
I appreciate the opportunity to explore and experiment with the ideas
here. It will be even better when I can do it in the same environment
that you do, rather than translating into my own system.
On Mon, Nov 7, 2011 at 5:08 PM, karl ramberg karlramb...@gmail.com wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
Karl
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
