std.variant benchmark

[Dmitry Olshansky]

On 29-Jul-12 22:59, Andrei Alexandrescu wrote:
> On 7/29/12 10:43 AM, Dmitry Olshansky wrote:
>> I'm horrified. Who was working on std.variant enhancements? Please chime
>> in.
>
> I guess you just volunteered! When I looked at it this morning I noticed
> a few signs of bit rot, e.g. opAssign returns by value and such. (Only
> planting a "ref" there improves performance a good amount.)
>
Strange, but numbers stay the same for me.

> Variant has a simple design with (in case of int) an int and a pointer
> to a function. Many of its operations incur an indirect call through
> that pointer. This makes operations slower than the time-honored design
> of using an integral tag and switching on it, but offers in return the
> ability to hold any type without needing to enumerate all types explicitly.
>

Well obviously integers do not take lightly when they are copied around 
with memcpy like some pompous arrays that alone incurs *some* penalty.

In fact memcpy could and should be replaced with word by word copy for 
almost all of struct sizes up to ~32 bytes (as size is known in advance 
for this particular function pointer i.e. handler!int).

I've found something far more evil:

@property bool convertsTo(T)() const
     {
         TypeInfo info = typeid(T);
         return fptr(OpID.testConversion, null, &info) == 0;
     }

Okay... now let me pull off another piece of rag:

private VariantN opArithmetic(T, string op)(T other)
     {
         VariantN result;
         static if (is(T == VariantN))
         {
             if (convertsTo!(uint) && other.convertsTo!(uint))
                 result = mixin("get!(uint) " ~ op ~ " other.get!(uint)");
             else if (convertsTo!(int) && other.convertsTo!(int))
                 result = mixin("get!(int) " ~ op ~ " other.get!(int)");
             else if (convertsTo!(ulong) && other.convertsTo!(ulong))
                 result = mixin("get!(ulong) " ~ op ~ " other.get!(ulong)");
             else if (convertsTo!(long) && other.convertsTo!(long))
                 result = mixin("get!(long) " ~ op ~ " other.get!(long)");
             else if (convertsTo!(double) && other.convertsTo!(double))
                 result = mixin("get!(double) " ~ op ~ " 
other.get!(double)");
             else
                 result = mixin("get!(real) " ~ op ~ " other.get!(real)");
         }
         else
         {
             if (is(typeof(T.max) : uint) && T.min == 0 && 
convertsTo!(uint))
                 result = mixin("get!(uint) " ~ op ~ " other");
             else if (is(typeof(T.max) : int) && T.min < 0 && 
convertsTo!(int))
                 result = mixin("get!(int) " ~ op ~ " other");
             else if (is(typeof(T.max) : ulong) && T.min == 0
                      && convertsTo!(ulong))
                 result = mixin("get!(ulong) " ~ op ~ " other");
             else if (is(typeof(T.max) : long) && T.min < 0 && 
convertsTo!(long))
                 result = mixin("get!(long) " ~ op ~ " other");
             else if (is(T : double) && convertsTo!(double))
                 result = mixin("get!(double) " ~ op ~ " other");
             else
                 result = mixin("get!(real) " ~ op ~ " other");
         }
         return result;
     }


So to boot in order to get to int + int _detected_ it needs 4 calls to
  fptr(OpID.testConversion, null, &info) == 0 and acquire TypeInfo each 
time. Not counting 2 gets to obtain result. It's just madness.

Plain hardcoded Type to integer switch seems so much better now.

> We can use the pointer to function as a tag for improving performance on
> primitive types.
>

Indeed we can though it won't be as fast as simple tag - pointers
have quite big and sparse addresses giving us the same as:

if(ptr == handler!int)
...
else if(ptr == handler!uint)
...
else
...

Another way to go is make 2-d function table for all built-ins and all 
operations on them. It's in fact a bunch of tables:
Type1 x Type2 for all of important basic operations. Tables are static 
so it won't be much of a problem. At least int + int then would be
1 memory read, 1 call, 2 (casted as needed) reads & 1 store.

-- 
Dmitry Olshansky