Re: a dozen cpu's on a chip

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
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. You are clearly doing something pretty bad to the virtual memory if it stalls for seconds at a time. What do you see if you run performance monitor?

XP is fairly robust. Not perfect, but it should not be forever falling over unless there is some dodgy device driver, malware or other root cause.

Your imaginary solution would only work if all the CPUs were absolutely protected from each other. There are other ways to do this with a single CPU and a decent time sharing OS - the fact that MS implementations of Windows fall way short of this ideal does not mean that it cannot be done.

That is the issue.
Many of those processes use very few resources, tha twas th point I
was trying to make.

So idle them when they're lightly loaded. Transistors are free.

Silicon real estate is never free, and they use power. Having thread level context switching support might make good sense though.

And if that is so, it is no use to assign those to their own cores.

Of course there is. It keeps them from trashing other processes.

Only if every CPU has its own dedicated memory. In flat linear addressed memory any CPU core can hit any address unless you take steps to prevent it in the OS.

This is *going* to happen. Core count is only going up, and even an os
as stupid as Windows 7 will be able to scatter processes amongst
CPU's. So it might be evolutionary, so that we can take advantage of
multicore but preserve our investment in bugs and bloat.

Bloatware is where it is at. I doubt we will ever get rid of it now :(
The importance of form over content is well known to salesmen.

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

Relevant Pages

  • Next July 27: boot failure(hang) on x86_64 box.
    ... Freeing unused kernel memory: 1360k freed ... ACPI: PM-Timer IO Port: 0x488 ... CPU: L2 Cache: 1024K ... # AX.25 network device drivers ...
    (Linux-Kernel)
  • [PATCH] Document Linuxs memory barriers [try #3]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
    ... Bios 1.04beta did show correct memory sizing in dmidecode, ... I hope this is as simple as me doing something glaringly wrong in the kernel ... DMI present. ... CPU: L2 cache: 6144K ...
    (Linux-Kernel)
  • Re: read vs. mmap (or io vs. page faults)
    ... not fit in main memory, and there are overheads related to the heuristics ... But because the CPU is underutilized, ... reasonably sized user buffer). ... You have to measure the actual overhead to see what the actual cost is. ...
    (freebsd-questions)
  • Sun Fire v440 hardware problem (cant get ok>)
    ... 0>Init CPU ... 1>Set JBUS config reg ... 0>Probe and Setup Memory ... Could not read diag-level from NVRAM! ...
    (SunManagers)