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
