←back to thread

587 points swills | 2 comments | | HN request time: 0.51s | source
Show context
jihadjihad ◴[] No.45689668[source]
In a similar vein, this is one of the most interesting things I’ve come across on HN over the years:

https://www.linusakesson.net/programming/pipelogic/index.php

Past HN post: https://news.ycombinator.com/item?id=15363029

replies(6): >>45691212 #>>45693238 #>>45695694 #>>45695783 #>>45695973 #>>45698756 #
1. lloeki ◴[] No.45695694[source]
Around 2004-2005 during some research at the end of my curriculum I happened to be doing with some specific jobs that were parallelised and data flowing as it was processed along a component diagram for visualisation, and it looked very familiar....

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...

replies(1): >>45698233 #
2. kevindamm ◴[] No.45698233[source]
It's never too late to learn queueing theory

...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.