Re: a dozen cpu's on a chip

On Tue, 13 May 2008 08:32:28 -0700 (PDT), panteltje@xxxxxxxxx wrote:

On 13 mei, 17:13, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 13 May 2008 08:05:12 -0700 (PDT), pantel...@xxxxxxxxx wrote:
On 8 mei, 04:48, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CESEX...

I bet we'll see 256 one of these days.

John

It is of course completely of-topic, but jus tto contribute for
test :-) to
the noise, I am sure I have seen a 512 core chip several years ago.

The problem is what to do with > 6 cores.
As you al probably know Sony PS3 has a Cell processor
with one big and 6? small 'helper' processors.
Now in a multimedia application, or networking, two ways,
say signal processsing decryption decoding graphics that
will maybe use 4 cores.
It is not easy to slit a program over more then one core.
Even if threaded, it makes not always sense,
I have written threaded programs where some threads use very few
resources,
running those on a separate core woul make little sense,
Some multi media stuff uses no threads at all (Linux mplayer IIRC),
while others, xine media player for example _is_ threaded.
And this is from the POV of embedded.
Now sure, you could run some FPGA synthesize on one core,
PCB routing on the other, SPICE on a third.. however how often
do you use it at the same time.
So, and I am not even thinking Microsoft, they only have binaries for
X86 of
their OS, but the software that takes full advantage of so many cores
for a _general purpose_ OS, has, as far as I know, not been invented
yet.
And are sequential cores always the best solution? Not sure,
in the above example the decryption could be done faster by FPGA (1
clock) perhaps.

So, unless they come up with a software solution that makes full use
of those cores, perhaps the only other option is to try to up the
clock speed,
new techniques to reduce power consumption are mentioned here and
there.

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.


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.

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.


Look at the below list of this Linux system (ps av):
Most of the proceses do nothing, there runs a h246 encode in the
background,
name server, mail server, ftp server, htttp server, and processor use
is
Cpu(s): 2.7% us, 5.4% sy, 41.8% ni, 48.5% id, 0.7% wa, 0.3% hi,
0.7% s

Load factor nicely balances around 1.0

~ # ps avx
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1 ? Ss 0:06 17 29 1878 648 0.1 init [2]
2 ? SN 0:00 0 0 0 0 0.0 [ksoftirqd/0]
3 ? S 0:00 0 0 0 0 0.0 [watchdog/0]
4 ? S< 0:00 0 0 0 0 0.0 [events/0]
5 ? S< 0:00 0 0 0 0 0.0 [khelper]
6 ? S< 0:00 0 0 0 0 0.0 [kthread]
29 ? S< 0:00 0 0 0 0 0.0 [kblockd/0]
30 ? S< 0:00 0 0 0 0 0.0 [kacpid]
93 ? S< 0:00 0 0 0 0 0.0 [kseriod]
115 ? S< 0:44 0 0 0 0 0.0 [kswapd0]
116 ? S< 0:00 0 0 0 0 0.0 [aio/0]
117 ? S< 0:00 0 0 0 0 0.0 [jfsIO]
118 ? S< 0:00 0 0 0 0 0.0 [jfsCommit]
119 ? S< 0:00 0 0 0 0 0.0 [jfsSync]
120 ? S< 0:00 0 0 0 0 0.0 [xfslogd/0]
121 ? S< 0:00 0 0 0 0 0.0 [xfsdatad/0]
288 ? S< 0:00 0 0 0 0 0.0 [kpsmoused]
292 ? S< 0:00 0 0 0 0 0.0 [reiserfs/0]
367 ? S<s 0:01 0 52 2043 844 0.2 udevd --
daemon
662 pts/7 S+ 0:01 1 44 2183 1116 0.2 top
775 ? S< 0:00 0 0 0 0 0.0 [kgameportd]
786 ? S< 0:00 0 0 0 0 0.0
[ksuspend_usbd]
787 ? S< 0:00 0 0 0 0 0.0 [khubd]
812 pts/1 SN 0:45 0 467 4408 1404 0.3 sh /usr/local/
sbin/temp_to_lcd
2022 ? S 0:00 0 11 1548 396 0.1 sleep 60
2087 ? Ss 0:00 0 284 4547 1148 0.2 /usr/sbin/
sshd
2167 pts/1 S 0:00 0 11 3604 464 0.1 sleep 55
2269 pts/1 SN 0:00 0 11 3604 468 0.1 sleep 10
2274 ? S 0:00 0 11 1548 396 0.1 sleep 1
2275 pts/6 R+ 0:00 0 63 3992 756 0.1 ps avx
2540 ? Ss 0:00 0 16 1563 592 0.1 /usr/sbin/
acpid -c /etc/acpi/events -s /var/run/acpid.socket
2822 ? SNs 0:00 1 86 1973 760 0.1 /sbin/syslog-
ng -p /var/run/syslog-ng.pid
2830 ? Ss 0:00 0 25 2126 732 0.1 /usr/sbin/
cron
2838 tty1 Ss 0:00 1 27 2588 1304 0.3 /bin/login


Fine. Run each on its own CPU and let the idle ones sleep.

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.

John

.