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