[HN Gopher] The Scalar Select Anti-Pattern
___________________________________________________________________
The Scalar Select Anti-Pattern
Author : goranmoomin
Score : 28 points
Date : 2025-05-14 20:19 UTC (1 days ago)
(HTM) web link (matklad.github.io)
(TXT) w3m dump (matklad.github.io)
| castratikron wrote:
| As long as processing one event does not affect any of the other
| events in the batch. E.g. events are file IO, and processing one
| event causes another event's descriptor to get closed before that
| event can be processed.
| taeric wrote:
| I'm not entirely clear on what the proposal is at the end? Seems
| that the long term answer as to "which of these implications to
| pursue" is "all of them?" Simply taking in a batch of
| instructions doesn't immediately change much? You still have to
| be able to do each of the other things. And you will still expect
| some dependencies between batches that could possibly interact in
| the same ways.
|
| In a sense, this is no different than how your processor is
| dealing with instructions coming in. You will have some
| instructions that can be run without waiting on previous ones.
| You will have some that can complete quickly. You will have some
| that are stalled on other parts of the system. (I'm sure I could
| keep wording an instruction to match each of the implications.)
|
| To that end, part of your program has to deal with taking off
| "whats next" and finding how to prepare that to pass to the
| execution portion of your program. You can make that only take in
| batches, but you are almost certainly responsible for how you
| chunk them moreso than whatever process is sending the
| instructions to you? Even if you are handed clear batches, it is
| incumbent on you to batch them as they go off to the rest of the
| system.
| malkia wrote:
| in CPU's - pipelining!
___________________________________________________________________
(page generated 2025-05-15 23:00 UTC)