Re: [Sbcl-devel] struct vs aref runtimes

[james a. <ja...@dy...>]

good morning;

> On 2015-07-22, at 02:56, Jon Buller <jo...@bu...> wrote:
> 
> Thank you very much. One of the joys of working with a large
> language/library and using a small brain to do it with is that I didn't
> know about svref. That is just what I was wanting, and doubt I will ever
> forget about it now.  The real code did have some declarations, just not
> anywhere near enough to overcome using aref instead of svref. Now for a
> search/replace job on that code (or a few simplistic defmacros)...
> 
> On Wed, 2015-07-22 at 01:54 +0200, Pascal Costanza wrote:
>>> On 19 Jul 2015, at 20:49, Jon Buller <jo...@bu...> wrote:
>>> 
>>> I was writing some code to do computer graphics, so I needed some 3
>>> element vectors.  I discovered this:  (please note that these are just a
>>> couple of quick examples to duplicate the actual work I really did a
>>> while ago.)
>> 
>> […]
>> 
>>> Since the two should be mostly identical, functionally at least, but one
>>> always runs 5 or 10 times slower than the other... it would seem that
>>> some more optimization could be done on calls to aref with a constant
>>> index.  
>> 
>> Try svref instead of aref. Also, you don’t declare types and optimization qualities, so there is still a lot of noise in your measurements (like checking for overflow whenever the dotimes variable is incremented; looking up a dynamic variable instead of a lexical one; etc.) aref adds the “noise” that it first has to figure out the rank of the array, etc., which is something that svref can avoid. However, when declaring types, things may turn out better for aref. You have to go more low level if you really care about performance…

if you would like to see examples of how far to take this, there are two in https://github.com/lisp: one for graphics[1] and one for framed data protocols[2].

once you start down the road of optimizing declarations, disassemble is your friend.

when you get to the point, that un/boxing turns into a large portion of the time, watch carefully what ends up on the stack for values passed from unboxed contexts _and_ check for returned value leakage.

best regards, from berlin
—
[1] https://github.com/lisp/de.setf.graphics
[2] https://github.com/lisp/de.setf.amqp
---



---
james anderson | ja...@dy... | http://dydra.com