Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 62649 invoked from network); 8 Jul 2008 01:22:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jul 2008 01:22:47 -0000 Received: (qmail 80700 invoked by uid 500); 8 Jul 2008 01:22:48 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 80684 invoked by uid 500); 8 Jul 2008 01:22:48 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 80673 invoked by uid 99); 8 Jul 2008 01:22:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2008 18:22:48 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jul 2008 01:21:56 +0000 Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com [10.22.129.22]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m681KHZ8017497 for ; Tue, 8 Jul 2008 01:20:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: implementation of Unary Traits Date: Mon, 7 Jul 2008 19:20:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: implementation of Unary Traits Thread-Index: Acjbj13oGdCfaxvXSqWYePIUeuEqgAFBuRTg References: <48642A07.4010201@roguewave.com> <486474F4.2050702@roguewave.com> <4869B7A1.3030004@roguewave.com> <486A4CC7.6030609@roguewave.com> From: "Travis Vitek" To: X-Virus-Checked: Checked by ClamAV on apache.org =20 Martin Sebor wrote: > >Eric Lemings wrote: >> =20 >>=20 >>> Martin Sebor wrote: >>> >>> Travis Vitek wrote: >>>> =20 >>> [...] >>>> 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,=20 >>> honestly, for >>>> me to care either way, I need to know that there actually a=20 >>> 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. >>=20 >> That's not unexpected: like everything in computing, it's a tradeoff. >>=20 >> 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 > struct is_void { typedef false_type type; }; > > template <> > struct is_void { typedef true_type type; }; > > template <> > struct is_void { typedef true_type type; }; > > template <> struct > struct is_void { typedef true_type type; }; > > template <> struct > struct is_void { typedef true_type type; }; > >to this code (which I called "template metaprogramming"): > > template > struct is_void_impl { typedef false_type type; }; > > template <> struct > struct is_void_impl { typedef true_type type; }; > > template > is_void: is_void_impl::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 struct is_cv_void { typedef false_type type; }; template <> struct struct is_cv_void { typedef true_type type; }; template is_void: is_cv_void { }; 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