[Mesa-dev] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.

[Eric Anholt]

Ian Romanick <idr at freedesktop.org> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/21/2013 11:41 AM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>> 
>>> Premature "send" strikes again...
>>> 
>>> On 09/19/2013 05:26 PM, Ian Romanick wrote:
>>>> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
>>>>> Previously, almost all classes didn't actually call their
>>>>> destructors, which is non-intuitive for C++ code.  Setting
>>>>> them up to be called was somewhat of a pain, since it
>>>>> required defining a helper function.
>>>>> 
>>>>> With the new macros, we can easily encapsulate this
>>>>> complexity, making destructors just happen automatically.
>>>>> 
>>>>> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org> --- 
>>>>> src/glsl/ralloc.h | 8 ++++++++ 1 file changed, 8
>>>>> insertions(+)
>>>>> 
>>>>> diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h index
>>>>> 799d3a9..82a3daa 100644 --- a/src/glsl/ralloc.h +++
>>>>> b/src/glsl/ralloc.h @@ -405,15 +405,23 @@ bool
>>>>> ralloc_vasprintf_append(char **str, const char *fmt, va_list
>>>>> args); #endif
>>>>> 
>>>>> #define _RALLOC_OPS(ALLOC, TYPE)
>>>>> \ +private:
>>>>> \ +   static void _ralloc_##TYPE##_destructor_callback(void
>>>>> *p)             \ +   {
>>>>> \ +      reinterpret_cast<TYPE *>(p)->~TYPE();
>>>>> \ +   }
>>>>> \ +public:
>>>>> \ static void* operator new(size_t size, void *mem_ctx)
>>>>> \ {
>>>>> \ void *p = ALLOC(mem_ctx, size);
>>>>> \ assert(p != NULL);
>>>>> \ +      ralloc_set_destructor(p,
>>>>> _ralloc_##TYPE##_destructor_callback);    \
>>> 
>>> All of the IR objects share the ir_instruction destructor:
>>> 
>>> virtual ~ir_instruction() { }
>>> 
>>> Doing this universally will add two indirect function calls when
>>> every object is released.  I wish we had a compiler benchmark so
>>> that we could know whether this is going to hurt app start up
>>> time on apps with lots of large shaders. :(
>> 
>> You can test this easily, thanks to shader_runner, "time", and 
>> shader-db.
>> 
>> For a large l4d2 shader: N           Min           Max
>> Median           Avg        Stddev x 1088      0.012401
>> 0.024984      0.017926   0.017903518  0.0018709739 + 1088
>> 0.012483      0.028997      0.017919   0.017883756  0.0019610448 No
>> difference proven at 95.0% confidence
>
> Does shader-db compile all the shaders in a single GL context?  If it
> doesn't there's probably a lot of other overhead that could mask the
> issue.  Still, this definitely means that compile times won't skyrocket...

I've used this many times to show overhead in compiling, I didn't see
any reason things would be different this time.

Of course, this time I happened to run the wrong version of the script,
which wasn't successfully compiling.  Updated numbers:

x 4636      0.029608      0.057734       0.04657   0.044289073  0.0049689317
+ 4636      0.029798      0.057689      0.046927   0.044643953  0.0049795278
Difference at 95.0% confidence
	0.00035488 +/- 0.0002025
	0.801281% +/- 0.457224%
	(Student's t, pooled s = 0.00497423)

So, yeah, there's a bit of a loss here, much more than I expected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130922/5abbd64a/attachment.pgp>