Re: a dozen cpu's on a chip

John Larkin wrote:
On Fri, 09 May 2008 15:48:22 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Fri, 09 May 2008 11:18:39 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

You seem to be assuming that one program will be run on multiple cores
for performance.

No. I was actually thinking of hardware problems related to shared common memory, bus arbitration, bandwidth and cache coherency.

Yes, that's difficult. But it's unnecessary, since
the average user doesn't do FFTs all day; he edits, browses, prints.
All of which are easily done by timeslicing a single CPU.

If it's easy, why are "home pc" OS's flakey gigabyte monsters that
even professionals don't understand and struggle to maintain? And why
would *any* OS be subject to acquiring a virus by just viewing a web
page? And why does doing routine operations sometimes hang all tasks
for tens of seconds?

It is well known how to do it right.

There are perfectly good OS's out there and for that matter quite plausible virtual machine PC software that will allow you to run guest operating systems independently on the latest P4s. Hardware support for virtual CPU is present in the newer chips so you can test your hypothesis.

OS/2 was very impressive for its day - it was perfectly possible to write a device driver to simulate the buffered 16550 serial IO chip on that. The world chose Windows glitz over reliability and performance...

Having a linear address space that anything can trample on is about the most dangerous architecture for security. Terminating a process the moment it tries to read or write something that it doesn't own makes for robustness and instills discipline in the programmers.

I'm just not seeing the "easily done" part; the Mac OS's come closest,
I guess.

That is a problem with the rush to market rather than a pure technical problem. Given the time and expense a robust OS for the PC was possible, but businesses decided they wanted whizzy graphics much more than robustness. First mover advantage is too great to get software right :(

If one cpu is allocated to each process, everything becomes simple,
and we avoid context switching and, with a decent system design, a
crash-proof OS can be easily designed.

Dream on. It isn't the context switching that is the problem it is bad or no design, sloppy programming languages and sloppy programmers.

Yes. But the only thing that will break the paradigm is a totally new
hardware architecture. The multiple cpu's could be virtual (ie, a
register that selects the "current cpu", and all of its contexts,
instantly) but multiple cores with true concurrent execution is
probably a better use of silicon and a better way to manage resources,
especially the most difficult resource: time [1]. The point is that
new hardware is needed to constrain bad programmers (ie, most
programmers) from trying to do complex, clever things that they rarely
do right. A cpu is a tiny spec of silicon these days.

You will still get nasty deadlock situations when these CPUs try to interact with the real world via peripherals. It will be the supervisor that is hard to write in this sort of approach. That is also true for the high performance computing game the highest priority task is the one which keeps all the other CPUs busy and loaded with data to work on.

John

[1] Could it be that programmers tend to look at programs as linearly
executed screens of text, and realtime things - task switching,
interrupts, async events - don't fit into their way of thinking?

No not at all. Some of us do understand realtime and asynchronous events. I will grant you that a frightening number do not and are programming in an environment like Windows where this can leave them dangerously exposed to unwelcome surprises.

Maybe
that's why the best programmers are people who were never educated as
programmers.

Depends what you mean by this. One of the best programmers I have known trained as a classicist. Self taught ones can be good but are often unaware of the importance of a good algorithm and data structure.

A prototype electronics rats nest of unreliable bodging is pretty obvious on the bench, unfortunately with dodgy software it is harder for the lay observer to judge the quality from the outside.

Regards,
Martin Brown
** Posted from http://www.teranews.com **
.

Relevant Pages

  • Re: Rene cant handle AoAs Success
    ... Which is the majority of programmers out there. ... Though I've actually gone through the process of CPU design myself, ... OTPs for a batch of keyboards and discover a bug in the software. ...
    (alt.lang.asm)
  • Re: A chip too far? Where is your solution Mr Larkin?
    ... Blowing in the wind, ... But wasting performance for reliablity though is never going to fly - not least because most times it would not have the desired effect. ... Hardware enforced memory protection for threads on a timesliced CPU can be made every bit as reliable as giving each one a physical CPU just a SMOP. ... hardware control over the things that programmers tend to screw up. ...
    (sci.electronics.design)
  • Re: OT Dual core CPUs versus faster single core CPUs?
    ... Then one core could be assigned to each application process ... The OS cpu will assign it a task, create its memory image, set up its ... "Most people fail to consider that good programmers are very ...
    (sci.electronics.design)
  • Re: a dozen cpus on a chip
    ... Multiple CPUs are hard to manage efficiently for general purpose ... All of which are easily done by timeslicing a single CPU. ... of executable files as my whimsy dictates. ... sloppy programming languages and sloppy programmers. ...
    (sci.electronics.design)
  • Re: Multi-threaded app behaviour question
    ... Process A is also at priority 59 but not on a CPU. ... The programmers goofed and got the thread synchronisation wrong. ... Probably a timer in the process. ... Solaris does both multi-threading ...
    (comp.sys.sun.admin)