Performance and Scalable FRP

[jmatsushita]

Hi @turion

Hope you're doing well. I've been reading this paper on FRP performance which has a scalable-frp gitlab repo and was wondering if you're aware of it, and if you had thoughts about how some of the techniques could be applied and if they're relevant in the context of Rhine. For instance it seems that:

• Rhine's Clock types could be mapped onto the C S and D signal kinds in the paper.
• Clock trees map to the paper's binary tree of signal descriptors

I wonder if it would then be possible to introduce define a route function of ClSFs over IORefs for optiimising stateful Rhines.

It feels to me that going this route possibly opens the door to interpret FRP into a somehow more ECS-ish approach, where we get to think both about pure signals in continuous time, type-safe synchronisation but also about efficient memory representations.

I also wonder if some of the benchmarks from the scalable-frp repo could be adapted to Rhine?

Cheers,

Jun

[turion]

I had read that article a longer while ago, and already forgotten about it. A couple of comments:

• It might in principle be applicable to rhine, although you might raise the question rather in the https://github.com/ivanperez-keera/dunai repository (upon which rhine is based), or rather even in https://github.com/turion/essence-of-live-coding (upon which rhine might eventually be based, https://github.com/turion/rhine/pull/143).
• I don't fully see the connection between clocks and the C, S, D kinds. In rhine, all clocks are discrete, and continuity is recovered as clock polymorphism.
• The article is mainly about performance as far as I understand, and this is not the main aim of rhine. Instead, rhine's most important points are correctness (no clocking/resampling errors), flexibility (all kinds of backends & monads), and simplicity. This scalable-frp idea is orthogonal to the kind of correctness rhine offers, and it goes against ts flexibility and simplicity: It suggests using IORefs, which are inherently tied to the IO monad, whereas rhine is polymorphic in the monad (which is important in situations when IO is not available, and for testing/reproducibility/...). Also, it introduces a lot of new concepts which need to be runtime-compiled into something else, and rhine already has a complicated runtime-compilation step (clock erasure).
• It is interesting that the idea is called "scalable FRP". I never found that performance is the bottleneck in FRP scalability. When looking at real-life applications of Yampa, the real problem was that there were:
  1. beautiful pure FRP parts and ugly non-FRP IO parts, and these ugly parts kept growing the more "real-lifeish" the project was
  2. signal processing, resampling, clocking, scheduling (which are needed in bigger projects interacting with different components at different speeds) were always ad-hoc and a source of huge bugs.

So my point is that for scalability, we actually need to improve large-scale composability. And that's what rhine tries. In summary it's always interesting to see at what other points in the design space people improve something, but it's not an improvement that I see necessary for rhine.

this route possibly opens the door to interpret FRP into a somehow more ECS-ish approach

Ah, how is that?

also wonder if some of the benchmarks from the scalable-frp repo could be adapted to Rhine?

Yes, benchmarks and tests would be a great addition to rhine!