Re: a dozen cpu's on a chip

On Wed, 14 May 2008 09:17:16 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

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.


http://www.news.com/2100-1006_3-6119618.html

http://blogs.computerworld.com/node/6072

http://www.efluxmedia.com/news_Tilera_Unveils_64_core_CPU_07885.html


Dvorak has vague inklings as to what's going on:

http://www.pcmag.com/article2/0,1895,2129596,00.asp


John

.

Relevant Pages

  • VB6.exe - Projects beyond a certain size may result in compiler cr
    ... This is related to another thread, "vb6.exe crash while debugging" by Process ... Then at least we may know the limits of VB6 as it is, ... memory could not be "written". ... Neither uses a HyperThreading CPU, and both are using AMD Athlon CPU's (2.5+ ...
    (microsoft.public.vb.bugs)
  • 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: Crashing E220R(s)
    ... but some indications were that either a memory module or CPU module was ... My guess would be to replace CPU0, if you can accept another crash, open ...
    (comp.unix.solaris)
  • 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)