←back to thread

529 points swills | 7 comments | | HN request time: 0.748s | source | bottom
1. 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(5): >>45691212 #>>45693238 #>>45695694 #>>45695783 #>>45695973 #
2. jmux ◴[] No.45691212[source]
I hadn’t seen this before, this is sick! thanks for posting it here :)
3. wging ◴[] No.45693238[source]
And fastjson is an extremely fast json parser: https://github.com/qntm/fastjson
4. 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...

5. Sharlin ◴[] No.45695783[source]
This is probably old news to people interested in nonstandard methods of computation, but it just occurred to me that the fluid-based analogy to transistors is straightforward to construct:

              S
            |   |
     -------|   |
   G  \/\/|##|  |
     -------|   |
            |   |
              D
This is essentially a pressure regulator, except that the pressure is controlled by an independent signal. Pressure in G pushes a spring-loaded piston to block flow from S to D (a slightly different construction instead allows flow when G has pressure). Modulating the pressure in G can also used to modulate the flow, based on F = -kx. This simple construction has some issues, such as the fact that the pressure needed to move the piston depends on the pressure in S-D.
replies(1): >>45695837 #
6. duped ◴[] No.45695837[source]
This analogy goes pretty deep.

Fun fact, in British English the term for a vacuum tube triode is "valve" precisely because it operates like a valve. FETs (particularly JFETs) follow the same analogy (which is why FET and triode amplifier circuits look basically the same) using the field effect instead of thermionic emission.

7. stefanfisk ◴[] No.45695973[source]
That vaguely reminds me of https://en.wikipedia.org/wiki/Inerter_(mechanical_networks)