> On 09/02/1999 19:36 -0400, Vladimir Dergachev wrote:
> >>
> >> Not hard pushed at all. The problem is that both cpus have caches. So
> >> suppose you have two static variables:
> >>
> >> static char A;
> >> static char B;
> >>
> >> variable A is accessed often by thread 1, variable B is accessed often by
> >> thread 2. (if you want something more tangible, imagine that each thread
> >> is computing a checksum of it's own array and these variables keep the
> >> result - this is just for the sake of the argument).
> >>
> >> Now on UP system each thread will take approximately half the cycles
> >> available. On SMP system threads will do same if scheduled to one cpu, but
> >> will do considerably worse when scheduled to two different cpus.
> >>
> >> As pointed by Mark Hans to me ia32 has 32byte cache lines. Thus if the
> >> above example gets compiled so that variables A and B are further than 32
> >> bytes apart all is ok and no perfomance loss is expected. However if they
> >> are close (as they should be) each time the threads run on two different
> >> cpus making you are limited to FSB speed.
> >>
> >> Note that the same behaviour will happen even when variables are declared
> >> long. I would also imagine that on a system with only one cpu-intensive
> >> multi-threaded program running you'll get a slowdown as opposed to the
> >> case when you start any other program that will take that cpu from you.
> >> (say a while(1) loop).
> >>
>
>
> Of course, the argument can be made (and has been many a time in many
> different forums) that using global variables (especially unprotected
> by mutexes or other such mechanisms) is a **bad thing** in MT programming.
> In many many ways, global variables are a big bad accident waiting to happen.
> Better to make A (from your example) local to the thread that uses it,
> and the same with B. If the variable needs to be shared between threads,
> then make it global, but serialize access to it. If it doesn't need to
> be visible to both threads, don't make it visible to both threads.
The thing is that there is _no_ contention in the example. I.e. I'll say
that access to these variables is serialized - it will not change the
example. The problem is that there is an implicit dependency between
variables because of the way they were placed in the file.
Vladimir Dergachev
PS I do agree that making A local would be better in the example. However
this is just an example..
PSS Does anyone know of any kind of computationally intensive
multithreaded software package/benchmark to test out whether this is
noticable or not ?
>
> IMHO, that's just good programming practice. Granted, your example is
> valid as far as the expected effects are stated, but that doesn't mean
> it's good code.
>
>
> tw
>
>
>
>
> --
> +------------------------------+--------------------------+
> | Tim Walberg | Phone: 847-782-2472 |
> | TERAbridge Technologies Corp | FAX: 847-623-1717 |
> | 1375 Tri-State Parkway | twalberg@terabridge.com |
> | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 |
> +------------------------------+--------------------------+
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/