Deutsch   English   Français   Italiano  
<v0p5gg$20atc$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Anticipating processor architectural evolution
Date: Mon, 29 Apr 2024 15:03:57 -0700
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <v0p5gg$20atc$1@dont-email.me>
References: <v0k0ng$kiku$1@dont-email.me>
 <j4er2j5lsole1pb5ekp79rqspf67j7qc86@4ax.com>
 <nksv2jlg7g3nrl59biemldd2r768315k19@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 30 Apr 2024 00:04:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e1ea15408df0f080738bcaf936512f55";
	logging-data="2108332"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX182lTP4OaIIIJt/O93AMIBb"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:UCyg0MByc5n9XsnXL1pv+Gx1K3Q=
In-Reply-To: <nksv2jlg7g3nrl59biemldd2r768315k19@4ax.com>
Content-Language: en-US
Bytes: 4236

On 4/29/2024 12:19 PM, boB wrote:
> Isn't this what Waferscale is, kinda ?

WSI has proven to be a dead-end (for all but specific niche markets
and folks with deep pockets).  "Here lie The Connection Machine,
The Transputer, etc."

Until recently, there haven't really been any mainstream uses for
massively parallel architectures (GPUs being the first real use and
their preemption for use in AI and Expert Systems)

To exploit an array of identical processors you typically need a
problem that can be decomposed into many "roughly comparable" (in
terms of complexity) tasks that have few interdependencies.

Most problems are inherently serial and/or have lots of dependencies
that limit the amount of true parallelism that can be attained.
Or, have widely differing resource needs/complexity to make them
ill suited to being shoe-horned into a one-size-fits-all processor
model.  E.g., controlling a motor and recognizing faces have
vastly different computational requirements.

Communication is always the bottleneck in a processing application;
whether it be CPU to memory, task to task, thread to thread, etc.
It's also one of the ripest areas for bugs to creep into a design;
designing good "seams" (interfaces) is the biggest predictor of
success in any project of significance (that's why we have protection
domains, preach small modules, well defined interfaces, "contract"
programming style).

Sadly, few folks are formally taught about these interrelationships
(when was the last time you saw a Petri net?) so we have lots of
monolithic designs that are brittle due to having broken all the
Best Practices rules.

The smarter way of tackling increasingly complex problems is better
partitioning of hardware resources (with similarly architected
software atop) using FIFTY YEAR OLD protection mechanisms to enforce
the boundaries between "virtual processors".

This allows a processor having the capabilities required by the most
demanding "component" to be leveraged to, also, handle the needs of
those of lesser complexity.  It also gives you a speedy way of exchanging
information between those processors without requiring specialize
fabric for that task.

And, that SHARED mechanism is easily snooped to see who is talking to
whom (as well as prohibiting interactions that *shouldn't* occur!)

E.g., I effectively allow for the creation of virtual processors of
specific capabilities and resource allocations AS IF they were discrete
hardware units interconnected by <something>.  This lets me dole out
the fixed resources (memory, MIPS, time, watts) in the box to specific
uses and have "extra" for uses that require them.

(I can set a virtual processor to only have access to 64KB! -- or 16K
or 16MB -- of memory, only allow it to execute a million opcode fetches
per second, etc. and effectively have a tiny 8b CPU emulated within a
much more capable framework.  And, not be limited to moving data via
a serial port to other such processors!)