Re: [Caml-list] using React for -- reactions

[Nils Becker <nils.becker@bioquant.uni-heidelberg.de>]

>> bottom line: can a React based simulation possibly compete with
>> manual, in-place update of arrays, let's say within a factor of 2?
>> if yes what do i need to pay attention to?
> 
> No idea. Basically you need to pay attention to the topology of your
> graph. 

one data point: i removed one linear dependency and saw 15% speedup, so
this seems to be the way to go.

the code was similar to this:

let signal_1 = S.merge f init_val {bunch of other signals} in
let signal_2 = S.map g signal_1

actually i'm not interested in signal_1 in itself. it is the result of a
list fold with f. its values are pairs that still contain an auxiliary
accumulator variable. in the second step i post-process this result to
give the meaningful signal_2. nothing else depends on signal_1.

i now got rid of signal_2 by putting the post-processing into the
downstream dependents of signal_1. this makes the structure of the
program a bit less nice since i now use the half-finished signals, but
it removes one trivial dependency. i think this is the cause of the speedup.

this is actually a general pattern i find myself using: a combinator
does not quite do all of the transformations i need, so i make another
signal/event directly downstream which completes the processing. another
example is

let evt_1 = E.select {bunch of events} (* not interested in evt_1 *)
let signal_2 = S.accum evt_1 init_val  (* except for making this *)

it now turns out this pattern is not really for free since it makes
dependency chains longer. it would be cool to have a way to 'contract'
these trivial links in the dependency graph. ie. to produce the result
of signal_2 directly, with only a single node in the graph. or to
'block' them together in the dependency resolution in some way. is there
already a way to do this that i missed?

n.