зеркало из https://github.com/mono/mail-archives.git
122 строки
4.4 KiB
HTML
122 строки
4.4 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [Mono-gc-list] Fast allocation vs lightweight collection
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="index.html" >
|
|
<LINK REL="made" HREF="mailto:patrik.torstensson%40intel.com">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
|
|
<LINK REL="Previous" HREF="000033.html">
|
|
<LINK REL="Next" HREF="000035.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[Mono-gc-list] Fast allocation vs lightweight collection
|
|
</H1>
|
|
<B>Torstensson, Patrik
|
|
</B>
|
|
<A HREF="mailto:patrik.torstensson%40intel.com"
|
|
TITLE="[Mono-gc-list] Fast allocation vs lightweight collection">patrik.torstensson@intel.com
|
|
</A><BR>
|
|
<I>Tue, 26 Aug 2003 08:59:02 +0100</I>
|
|
<P><UL>
|
|
<LI> Previous message: <A HREF="000033.html">[Mono-gc-list] Fast allocation vs lightweight collection
|
|
</A></li>
|
|
<LI> Next message: <A HREF="000035.html">[Mono-gc-list] Fast allocation vs lightweight collection
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#34">[ date ]</a>
|
|
<a href="thread.html#34">[ thread ]</a>
|
|
<a href="subject.html#34">[ subject ]</a>
|
|
<a href="author.html#34">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>Hello guys,=20
|
|
|
|
><i> It's pretty easy to avoid locking using the atomic test/set/exchange
|
|
</I>><i> operations of modern processors.
|
|
</I>><i> For example, x86 has "cmpxchg", the psudocode of this operation is:
|
|
</I>><i>=20
|
|
</I>><i> [ <A HREF="http://www.geocities.com/bkartheek/files/chap6.htm">http://www.geocities.com/bkartheek/files/chap6.htm</A> ]
|
|
</I>><i>=20
|
|
</I>><i> cmpxchg operand1, operand2 [ ax/al/eax =3D compare_to =
|
|
</I>]
|
|
><i>=20
|
|
</I>><i> if ({al/ax/eax} =3D operand1) then
|
|
</I>><i>=20
|
|
</I>><i> zero :=3D 1 ;Set the zero flag
|
|
</I>><i> operand1 :=3D operand2
|
|
</I>><i>=20
|
|
</I>><i> else
|
|
</I>><i>=20
|
|
</I>><i> zero :=3D 0 ;Clear the zero flag
|
|
</I>><i> {al/ax/eax} :=3D operand1
|
|
</I>><i>=20
|
|
</I>><i> endif
|
|
</I>><i>=20
|
|
</I>><i> Using this, you can do:
|
|
</I>><i>=20
|
|
</I>><i> try_again:
|
|
</I>><i> reg =3D mem(count)
|
|
</I>><i> compare_to =3D reg
|
|
</I>><i> reg =3D reg + 1 // or reg =3D reg -1
|
|
</I>><i> if (! cmpxchg mem(count),reg [ compare_to ] ) {
|
|
</I>><i> yeild(); // optional
|
|
</I>><i> goto try_again; =20
|
|
</I>><i> }=20
|
|
</I>><i>=20
|
|
</I>><i> When two threads collide, this looks like:
|
|
</I>><i> =20
|
|
</I>><i> thread1 thread2 mem(count)
|
|
</I>><i> reg =3D mem(count) reg =3D mem(count) 1
|
|
</I>><i> reg =3D reg+1 reg =3D reg+1 1
|
|
</I>><i> cmpxchg suceeds cmpxchg fails 2
|
|
</I>><i> ... reg =3D mem(count) 2
|
|
</I>><i> reg =3D reg+1 2
|
|
</I>><i> cmpxchg suceeds 3
|
|
</I>><i> ...
|
|
</I>><i>=20
|
|
</I>><i> No locking required.
|
|
</I>
|
|
Not really true. The cmpxchg (and other) will lock the CPU cache (or
|
|
cause a cache invalid signal to happen) on a x86. This causes serious
|
|
performance problems (it's better than a kernel lock but still..), the
|
|
CPU needs to refetch data into the cache again.
|
|
|
|
The biggest issue with the cache locking is that the performance hit
|
|
increases with the number of CPU:s. There is schemas to minimize the
|
|
locking for example building locks by using read and write operations
|
|
only (they are atomic on x86) and use a kernel lock when you need to
|
|
wait (spinning first).
|
|
|
|
Still, Paolo is right, reference counting is very expensive for
|
|
Multithreaded programs even if you use x86 specific helper functions.=20
|
|
|
|
(and another thing, the yield instruction is very important in that loop
|
|
if you want performance on a SMP box (use the PAUSE instruciton on the
|
|
new CPU:s))
|
|
|
|
Cheers,
|
|
Patrik Torstensson
|
|
=20
|
|
|
|
</PRE>
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI> Previous message: <A HREF="000033.html">[Mono-gc-list] Fast allocation vs lightweight collection
|
|
</A></li>
|
|
<LI> Next message: <A HREF="000035.html">[Mono-gc-list] Fast allocation vs lightweight collection
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#34">[ date ]</a>
|
|
<a href="thread.html#34">[ thread ]</a>
|
|
<a href="subject.html#34">[ subject ]</a>
|
|
<a href="author.html#34">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
</body></html>
|