On 09/02/1999 19:36 -0400, Vladimir Dergachev wrote:
>>=09
>> Not hard pushed at all. The problem is that both cpus have caches. So
>> suppose you have two static variables:
>>=09
>> static char A;
>> static char B;
>>=09
>> 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).
>>=09
>> 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, b=
ut
>> will do considerably worse when scheduled to two different cpus.
>>=09
>> 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.
>>=09
>> Note that the same behaviour will happen even when variables are declar=
ed
>> long. I would also imagine that on a system with only one cpu-intensive=
=20
>> 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).
>>=09
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 happe=
n.
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.
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
--=20
+------------------------------+--------------------------+
| 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 |
+------------------------------+--------------------------+
--xo44VMWPx7vlQ2+2
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: kzowZ8yLLD4g/l0xe0HR2P/eea6X/2wU
iQA/AwUBN8/dJ8PlnI9tqyVmEQKBuACgtnj7/buXFpVrSOuinhcgsnEAEX8AoMwJ
+8ED4qTk5knOePK4fqOLGLWp
=xRer
-----END PGP SIGNATURE-----
--xo44VMWPx7vlQ2+2--
-
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/