From: <me...@ho...> - 2005-10-26 17:12:59
|
The five minute work of optimizing WITH-RECURSIVE-LOCK for the case when=20 the current thread already has the lock quickly turned into confusion=20 (reading annotation 3 is enough): http://paste.lisp.org/display/12880#3 The executive summary is this: in the example, wrapping the same code in=20 a function makes the program faster if the function is not inlined. G=E1bor |
From: Florian W. <fw...@de...> - 2005-10-27 08:56:04
|
* G=E1bor Melis: > The executive summary is this: in the example, wrapping the same code in= =20 > a function makes the program faster if the function is not inlined. Maybe this is a branch prediction issue? |
From: Juho S. <js...@ik...> - 2005-10-27 14:52:18
|
<me...@ho...> wrote: > The five minute work of optimizing WITH-RECURSIVE-LOCK for the case when > the current thread already has the lock quickly turned into confusion > (reading annotation 3 is enough): > > http://paste.lisp.org/display/12880#3 > > The executive summary is this: in the example, wrapping the same code in > a function makes the program faster if the function is not inlined. Unless I'm grossly misunderstanding something, there's no inlining going on in your example regardless of which definition of FOO is used. The difference between the two cases is that one gets tail-call optimized, the other doesn't. Surprisingly the one that doesn't get optimized is the one where the compiler has access to more information. For some reason FLUSH-FULL-CALL-TAIL-TRANSFER explicitly forbids tail-calls to functions when the return convention isn't :UNKNOWN. -- Juho Snellman |