<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
Dear Ian,<BR>
Since your doing all the work I'm a little hesitant to suggest a solution, but it seems to me <BR>
the best solution is to use an all-lisp buffer pool, and use portable locking to atomically associate<BR>
a serializing thread with a buffer. (This is very similar to solution #1 you propose, I think.)<BR>
I'm actually not sure how your doing portable locking now; I just stuck some SBCL mutexes <BR>
in there, but that is makes my personal branch SBCL dependent.)<BR>
In the previous version (approximately v. 1.6 of the file serializer.lisp) the circularity hash <BR>
is implemented as a hash-table. It's not clear to me why one couldn't just allocate this <BR>
hashtable on every invocation, (perhpas lazily, when the first non-atomic type which might <BR>
lead to a circularity is serialized.) Perhaps this allocation cost would dominate the serialization<BR>
cost; but I would personally not be sure of that until a profiler gave such information.<BR>
<BR>
(However, I'm starting to worry that I might simply be terribly lazy, and covering up<BR>
for the fact by chanting the mantra: no premature optimization. I trust your instincts and <BR>
knowledge more than my own on this matter.)<BR>
<BR>
I'd like to stay away from any C-coding as much as possible; just as a matter of principle<BR>
I can't imagine that that makes us more robust.<BR>
<BR>
Thanks for your work Ian ---- a better serializer will be a big performance boost for the <BR>
whole project.<BR>
<BR>
<BR>
On Mon, 2006-11-20 at 09:56 -0500, Ian Eslick wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Elephant users and developers,</FONT>
<FONT COLOR="#000000">I've made the serializer thread safe for 0.6.1, but face an design</FONT>
<FONT COLOR="#000000">tradeoff. The serializer is a critical bottleneck for Elephant's</FONT>
<FONT COLOR="#000000">throughput and by adding locking into the equation I significantly slow</FONT>
<FONT COLOR="#000000">down the calls to serialize that operate on a small amount of data (all</FONT>
<FONT COLOR="#000000">symbols, integers and short strings which are typical slot values). </FONT>
<FONT COLOR="#000000">There are several possible solutions, in rough order of performance from</FONT>
<FONT COLOR="#000000">fastest to slowest:</FONT>
<FONT COLOR="#000000">1) Special start-elephant-thread macro which creates dynamic bindings</FONT>
<FONT COLOR="#000000">for the new process of a global special variable that maintains the</FONT>
<FONT COLOR="#000000">circularity buffer; this will allow us to be very efficient but requires</FONT>
<FONT COLOR="#000000">elephant-specific code on thread creation for safe threading</FONT>
<FONT COLOR="#000000">2) Bind a C-library which provides a CPU independent compare-and-swap</FONT>
<FONT COLOR="#000000">instruction and/or a lock-free queue so we can share a pool of</FONT>
<FONT COLOR="#000000">circularity buffers among processes in a lock-free way</FONT>
<FONT COLOR="#000000">3) It occurs to me that most lisps do not allow C code to be run</FONT>
<FONT COLOR="#000000">concurrently from multiple threads - perhaps just implementing a mutex</FONT>
<FONT COLOR="#000000">in C would be enough to provide a cheap way of updating head and tail</FONT>
<FONT COLOR="#000000">pointers in the queue. Capturing and releasing would be atomic. Is</FONT>
<FONT COLOR="#000000">this true for all lisps? I know it's true for Allegro. It would be a</FONT>
<FONT COLOR="#000000">hack, but a fairly harmless one given our existing dependence on the</FONT>
<FONT COLOR="#000000">memutil library.</FONT>
<FONT COLOR="#000000">4) Stick with the portable locking approach already implemented</FONT>
<FONT COLOR="#000000">Thoughts?</FONT>
<FONT COLOR="#000000">Ian</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">elephant-devel site list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</A></FONT>
<FONT COLOR="#000000"><A HREF="http://common-lisp.net/mailman/listinfo/elephant-devel">http://common-lisp.net/mailman/listinfo/elephant-devel</A></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>