Intel Core 2 duo - Suse
This is a discussion on Intel Core 2 duo - Suse ; On Wed, 29 Oct 2008 19:49:15 +0700, Bruce in Bangkok wrote:
....
>True, but the thing that seems to be unspoken is that nearly all, if
>not all, common Linux stuff and particularly the core programs all are
>designed for ...
-
Re: Intel Core 2 duo
On Wed, 29 Oct 2008 19:49:15 +0700, Bruce in Bangkok wrote:
....
>True, but the thing that seems to be unspoken is that nearly all, if
>not all, common Linux stuff and particularly the core programs all are
>designed for a single CPU and, while I admit I'm not positive, I
>believe that without software specifically designed to run on multi
>core processors little advantage can be gained.
Look at 'top' on a lightly loaded box, what state are most of the
processes in?
Now exercise that box by say compiling linux-kernel with 'make -j100',
see how it runs...
>
>For example:
>
>read location x;
> if something there
> do something with it;
> if not
> loop for 10 milliseconds;
>go back to read;
Nah, most programs block, waiting for input. What you've described
above is a naive polling loop. Real programs only go to polling to
relieve interrupt rate pressure, for example interrupt mitigation on
a fast network card which receiving at a high peak data rate.
>
>And that simple routine is the basis of one hell of a lot of software.
Not really. Check 'top', learn about sleeping processes.
Grant.
--
http://bugsplatter.id.au
-
Re: Intel Core 2 duo
On Thu, 30 Oct 2008 01:42:14 +1100, Grant
wrote:
>On Wed, 29 Oct 2008 19:49:15 +0700, Bruce in Bangkok wrote:
>...
>>True, but the thing that seems to be unspoken is that nearly all, if
>>not all, common Linux stuff and particularly the core programs all are
>>designed for a single CPU and, while I admit I'm not positive, I
>>believe that without software specifically designed to run on multi
>>core processors little advantage can be gained.
>
>Look at 'top' on a lightly loaded box, what state are most of the
>processes in?
>
>Now exercise that box by say compiling linux-kernel with 'make -j100',
>see how it runs...
>>
>>For example:
>>
>>read location x;
>> if something there
>> do something with it;
>> if not
>> loop for 10 milliseconds;
>>go back to read;
>
>Nah, most programs block, waiting for input. What you've described
>above is a naive polling loop. Real programs only go to polling to
>relieve interrupt rate pressure, for example interrupt mitigation on
>a fast network card which receiving at a high peak data rate.
>>
>>And that simple routine is the basis of one hell of a lot of software.
>
>Not really. Check 'top', learn about sleeping processes.
>
>Grant.
I don't really have to check on sleeping processes, at least I haven't
had to for the past 40 years, or so.
However, take any search program and whether it is read location X or
read next in file it is the same. Even a compiler works that way --
read file until you see a pattern and then do something with it.
Certainly interrupts are used when looking at a separate devise, say a
keyboard, but it is still a similar function except instead of
running a timing loop the CPU sits around waiting for a nudge from
someone. Another point is that every time you fork off another process
there is a certain amount of overhead involved.
Now, I have said that I am not really up to the minute on these new
dual core processors but unless each core can run independent of the
other with its own data and memory buss the way the old main frames
did I can't see how it can be more then a sort of assistant like the
old math co-processor.
But... I'm prepared to be educated if you have some specific data.
Bruce-in-Bangkok
(correct Address is bpaige125atgmaildotcom)
-
Re: Intel Core 2 duo
On Thu, 30 Oct 2008, Bruce in Bangkok wrote:-
>Now, I have said that I am not really up to the minute on these new
>dual core processors but unless each core can run independent of the
>other with its own data and memory buss the way the old main frames
>did I can't see how it can be more then a sort of assistant like the
>old math co-processor.
AFAIK, the AMD X2's and Phenom chips have a single external data and
memory bus. Internally, both/all the cores are independent of each
other. They have their own L1 and L2 caches, and share a L3 cache. They
a connected to the built-in North bridge, and through that to the main
memory.
As for the Intel Core 2 Duo's, and their other multi-cored chips, I have
no idea. I'd guess that they'd work in a similar manner, although they
have differing policies regarding L1, L2, and L3 caches, and the North
bridge on Intel systems is a separate chip.
>But... I'm prepared to be educated if you have some specific data.
Have a look at both Intel and AMD sites. They should have quite a lot of
useful information about how their multi-cored chips work.
Regards,
David Bolt
--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
| openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11