Re: Serial, concurrent, parallel

On 1/16/2025 9:27 AM, Martin Brown wrote:

On 16/01/2025 11:41, Don Y wrote:

On 1/16/2025 3:14 AM, Martin Brown wrote:

On 14/01/2025 18:10, Don Y wrote:

I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes.  I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!

>
Most people do think in a very linear fashion so I'm not too surprised at your finding. Good realtime programmers are as rare as hen's teeth.

>
When you think of a circuit diagram, do you "track" an electron through
the wiring?  Don't you conceptualize "this block does this WHILE this
other block is doing that"?
>
People seem to tolerate the notion of an ISR running WHILE their code
is running.  They don't seem to think of it as "my code is running and
THEN an interrupt comes along and does...".

 An ISR is sufficiently small and so mission critical that if it doesn't save and restore the registers it affects properly the OS dies PDQ.

My point being that people think of it as running WHILE their code
is running.  Even though the processor is technically single-threaded
and it is actually operating in series.

Yet, when they think of multitasking (and beyond), they seem to
intentionally serialize the actors' actions.  Why the difference
in mindsets?

 Most people can't imagine the various tasks running at different speeds either timesliced or by priority. There is always a tendency amongst programmer to think that their task is *the* most important one. The thing you learn quickly on truly massively parallel hardware is that the manager task that keeps all of the allocated workers busy is by far the highest priority.

Yes.  In my case, the workload manager has to also decide when to bring
additional resources on-line (power up other nodes) or shed surplus
resources (migrate tasks off of nodes so they can be powered DOWN)

It could be "solved" by the addition of suitable small delays here and there to prevent the race condition triggering. Heavy users went back to XL2003 which I recall was a particularly good vintage.

>
Dunno.  I've not used a spreadsheet since Quattro.  Never really saw the
appeal (if I need some set of values calculated, I'll just write a bit of
code to do it unambiguously -- instead of wondering what quirks the

 I like spreadsheets for making test data. The sort of mistakes you can make in a spreadsheet implementation are almost entirely orthogonal to those you can make in a conventional programming language. As such it makes a great scratch pad for developing tricky algorithms with all of the internal workings clearly visible on the screen.

Again, I rely on tables/relations.  Especially as I can just keep
adding to them AND can have their values "fed" to the UUT (with
results programmatically compared to the stored results).

spreadsheet imposes).  Especially as so many people seem to use spreadsheets
in lieu of (real) databases.  :<

 Sigh - yes I know they do :(
Up to a couple of thousand lines it isn't *too* bad but after that it goes downhill very quickly. Doesn't stop people - typically middle managers with very limited skills having silly sized ones though.

I just fail to see the appeal.  How does seeing row after row of data
make ANYTHING "better"?
I like RDBMSs because I can keep building on what I've already got.
E.g., if I knew Bob's wife's name BEFORE his divorce, I can still
keep a record of it AFTER their divorce!   AND, accommodate his
potential to remarry.
E.g., my address book started off with tables for city names and state
names to allow each to be reduced to an integer "ID" and ensure I never
had to worry about someone entering "Lnodon" as city name.  Then, I opted
to build a "localities" table that enumerated all of the possible, valid
(CityID, StateID) combinations, replacing them with a LocalityID (and
eliminating the need for CityID and StateID in actual address book entries.
Once I had localities, I could create a ZIPcode-to-Locality relation
so if you indicated you were in (Chicago, IL), I knew which subset
of ZIP codes would be valid for that locality.
And, which time zone.
And, whether or not "summer time" was observed.
etc.
So, the chance of entering "bad data" was greatly reduced as well as
giving me a "live" reference to consult:   Who might I have called
in area code 212?  What time is it at Bob's house, now?  What's his
NEW wife's name?  And, the names of his kids by his first wife?
All of these things can reside in separate tables yet be called on
("joined") to suit specific needs.