https://www.linusakesson.net/programming/pipelogic/index.php
Past HN post: https://news.ycombinator.com/item?id=15363029
https://www.linusakesson.net/programming/pipelogic/index.php
Past HN post: https://news.ycombinator.com/item?id=15363029
So I had this idea that you'd design code to be applied to a processing unit of specific capacity which would lead to execution flowing at a certain speed when applied a certain computation potential... and surprise surprise the relation would be uh, linear, and say you increase a loop's count and so the code would _resist_, or you'd increase computation potential to increase the flow.
So uh, yeah, Ohm's law but it's _code_ that's resistive.
And then I started to look for the pattern and find code with inductive properties, and code with capacitive properties, and some deeper properties emerged when you started modelling stuff with multiple processing units and data flowed around, split (map?), rejoined (reduce?).
And there was something strangely efficient about a way to see code that way and optimise using _laws_ describing the whole execution flow using familiar tools as a whole instead of thinking in gritty details barely higher-level than MOV AX... you "just" had to design code and the execution system so that it would operate in this kind of framework and allow that kind of analysis to identify bottlenecks and weird interplay actions across components.
And then I brought that up to my mentor and he said "well that's complete lunacy, stop thinking about that and focus on your current work" and, uh, case closed.
That was the young and naive me who thought that research labs were made to do think-outside-the-box connect-the-dots innovative stuff...
...because the typical setup assumes λ ≤ μ so all arriving jobs eventually get serviced.
I think there's a lot of unmet potential in design of interfaces for pipelines and services that really gets at the higher level you mention. There are some universal laws, and some differences between practice and theory.