stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: implementation of Unary Traits
Date Tue, 08 Jul 2008 01:20:23 GMT
 

Martin Sebor wrote:
>
>Eric Lemings wrote:
>>  
>> 
>>> Martin Sebor wrote:
>>>
>>> Travis Vitek wrote:
>>>>  
>>> [...]
>>>> If you ask what I prefer, I'm going to tell you I prefer the second
>>>> option (that is essentially what I wrote originally). But, 
>>> honestly, for
>>>> me to care either way, I need to know that there actually a 
>>> noticeable
>>>> performance difference between the two techniques.
>>> FYI: I used gcc 4.3 and EDG eccp to measure the difference between
>>> the compilation times of each of the two approaches (i.e., using
>>> specialization vs using remove_cv).
>>>
>>> In a program involving 10,000 invocations of is_void on distinct
>>> types, the specialization approach was 5 and 10 times faster than
>>> the one using remove_cv when using gcc and eccp, respectively. In
>>> the same program using only 1000 types, the specialization solution
>>> compiled 2 and 3 times faster, respectively.
>>>
>>> With gcc, the compiler also required about half the amount of system
>>> memory to compile the specialization-based solution than the other
>>> one. (I didn't measure eccp memory usage).
>>>
>>> This confirms that template metaprogramming is significantly more
>>> costly in terms of system resources than alternative approaches,
>>> at least in the gcc and eccp implementations. We should re-run the
>>> same tests with other compilers to get a complete picture.
>> 
>> That's not unexpected: like everything in computing, it's a tradeoff.
>> 
>> To get a really complete picture, you'd have to compare the
>> metaprogramming approach to the run-time alternatives.
>
>There are no runtime alternatives to the Unary Traits. We are
>discussing the pros and cons of one kind of a generic program
>vs another.
>
>To illustrate on an example, I was comparing the compilation
>efficiency of this code (I called it the "alternative approach"
>in my comment):
>
>   template <class T>
>   struct is_void { typedef false_type type; };
>
>   template <>
>   struct is_void<void> { typedef true_type type; };
>
>   template <>
>   struct is_void<const void> { typedef true_type type; };
>
>   template <> struct
>   struct is_void<volatile void> { typedef true_type type; };
>
>   template <> struct
>   struct is_void<const volatile void> { typedef true_type type; };
>
>to this code (which I called "template metaprogramming"):
>
>   template <class T>
>   struct is_void_impl { typedef false_type type; };
>
>   template <> struct
>   struct is_void_impl<void> { typedef true_type type; };
>
>   template <class T>
>   is_void: is_void_impl<typename remove_cv<T>::type { };
>
>Martin
>
>

Here is one alternative that we might want to consider. Instead of
stripping cv qualifiers, we add them and then provide a specialization
for the cv-qualified type.

  template <class T>
  struct is_cv_void { typedef false_type type; };

  template <> struct
  struct is_cv_void<const volatile void> { typedef true_type type; };

  template <class T>
  is_void: is_cv_void<const volatile T> { };

It is a bit of a compromise between the two implementations shown above.
This has the advantage over the "alternative approach" that it reduces
the number of templates to parse. It also eliminates the need to
instantiate remove_cv that is used in the template metaprogramming case.

Martin, if you still have your performance numbers, could you compare
this to the previously proposed options?

Travis

Mime
View raw message