On Thu, 10 Jun 1999, Joerg Beyer wrote:
> On Wed, Jun 09, 1999 at 09:53:19PM -0400, Eugene Kuznetsov wrote:
> > On Wednesday, June 09, 1999 9:15 PM, Robert M. Hyatt
> > I know, that was the point. You obviously view this as a plus. If one is
> > doing heavy-duty processing or data-crunching, this is often a good thing.
> > However, it is not *always* a good thing. If I want to spin a little logo
> > in the corner of an app's window, a thread is the simplest way of doing so.
> > Should this thread be running on the 2nd CPU, dragging the app's
> > instructions and data into its cache, too? It's no longer so
> > black-n-white, it starts getting complicated.
>
> does that mean that two threads working on the same data are thrashing each
> other out of the processor cache?
> I thought of something like this:
> pseudo code:
>
> thread 1 is doing this:
> for(int i=0;i<n;++n)
> sum[i] = a[i] + b[i];
>
> while thread 2 is doing this:
> for(int i=0;i<n;++n)
> diff[i] = a[i] - b[i];
>
> are these threads trashing a and b out of the processor cache or is the
> read only access OK?
>
> Joerg
> --
If you only have one cpu, that would be pointless. No reason to have two
threads doing computation like that... multiple threads on a single cpu
can simplify coding logic, and is a good thing. But if it doesn't
simplify something, it is a bad thing as it just produces unnecessary
context switches.
Of course, when you add that second cpu, this might make it run twice as
fast...
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
