Re: a dozen cpu's on a chip

John Larkin wrote:
On Tue, 13 May 2008 17:31:21 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Tue, 13 May 2008 08:32:28 -0700 (PDT), panteltje@xxxxxxxxx wrote:
John Larkin wrote:
My XP, not doing much right now, claims to be running 31 processes.
Add in maybe another 30 device drivers, tcp/ip stacks, and file
managers, and it would keep a 64-core cpu mostly employed.

Yes, but would it run faster?

Since it wouldn't spend a lot of time context switching, and since it
wouldn't crash and require reboots, and since it wouldn't leak memory

Leaking memory and IO handles has to do with untidy application programmers failing to free resources correctly. It has absolutely nothing to do having separate CPUs. I have even seen a VAX die that way, the last thing on its system console was a failure by the supervisor to open a channel to report that it had run out of IO channels.

and require reboots, and since it wouldn't trash virtual page files,
and since everything would keep running (as opposed to everything
pausing for 10 seconds now and then), yes, for me I'd come out ahead.
You really should investigate *why* your PCs are so unreliable rather than blathering on about how the world would be all sweetness and light if only Intel would make a 256 core CPU.

XP isn't bad, especially to people whose standards were lowered by '95
and '98. To people who used to run DEC timeshare systems, or who do
hard realtime stuff that may not have bugs, it's still pretty bad.

I have worked on plenty of PDP11 and VAX in my time. DEC-10 was kind of cute too. However, the VAX could very occassionally crash even so. The mechanical disk drives were its weakest component.

Remind me. Just how many CPUs did a VAX 11/780 have?
Hint: I know how many a 782 and 784 (exceedingly rare) had.
Google "VAX 784 problems field rework" shows a relevant summary as top hit although the actual page cached and pointed to has been sanitised. DEc had a lot of bother with the 784 and 785 was a faster single CPU.
Do you begin to see the fallacy of your argument?

It is nothing to do with how many CPUs there are and everything to do with a protected memory OS and process priviledge environment where threads are given only the resources they strictly need to do their job.

And the ultimately priviledged kernel is kept as small as possible. Memory ownership is way more important to system integrity than putting every thread on its own CPU whatever you may think.

Windows is hobbled by the backwards compatibility with badly behaved games and other programs that peek and poke directly at hardware.

If you really hanker after the old VAX environment you could try:
http://hoffmanlabs.org/openvms/hwvax.shtml
Hardware emulators exist and hobbyist licences are apparently available.

Blathering? Do you think that computer architectures are perfected,
and will never change? Do you think that all the multicore CPU's being
introduced will only be used to make things more complex and less
reliable?

For N>4 basically yes, unless very special circumstances apply that allow some of the CPUs to be dedicated to specific CPU intensive tasks or the problem has extremely high symmetry or is divisible in some other way that lends itself to spreading the load across many CPUs.

It will simply waste power and silicon to no good end in a general purpose PC. This doesn't mean it won't happen, but it will most likely be done to make some meaningless benchmark run faster.

Sure, pile OS virtualization on top of a heap of the
gigabyte dogs we're running now, and use the extra cpu's to run
multiple threads of Adobe products.

I use mine to run very CPU intensive things in the background whilst still having more than enough horsepower to do normal work.

On the whole, this newsgroup should be renamed
sci.electronics.tradition. It's practically impossible to get anyone
to riff on ideas; these guys mostly want to defend current and
comfortable practice. I shouldn't complain... I make a lot of money
taking business away from people who refuse to think.

Your idea is so bad and misguided as to be risible. If you cannot understand this then there is no point in continuing.

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

Relevant Pages

  • Re: MOSAIC and DECW$SCN_CLIPLIST_AREA message
    ... > allowing the graphics hardware to clip the drawing output. ... > less CPU intensive - and the VAX was a weak CPU. ... By offscreen memory, do you mean memory on the graphics card, or memory ...
    (comp.os.vms)
  • Re: VAX Spare Parts
    ... > Does anyone know what how many VAX sites are still out there? ... and some which speciallize in DEC CPU Upgrades... ... Digitask Consultants, Inc. - online store - USA ... Digital Surplus - Alphaserver CPU Upgrades - USA ...
    (comp.os.vms)
  • Re: Why was VAX abandonned ?
    ... >> As far as I know, DEC never rented VAX or Alpha that way. ... > can't charge by cpu runtime. ... This is due to the VMS ... They had been used to charging usage out to other ...
    (comp.os.vms)
  • Re: Part 1 of 3: Micro economics 101 (was: Code density ...)
    ... Ok, both companies were not just in the CPU business, so they could ... fabs have to be financed from revenue. ... AMD could afford ... But that was long after the VAX. ...
    (comp.arch)
  • Re: a dozen cpus on a chip
    ... and it would keep a 64-core cpu mostly employed. ... Leaking memory and IO handles has to do with untidy application ... I have worked on plenty of PDP11 and VAX in my time. ... the VAX could very occassionally crash even so. ...
    (sci.electronics.design)