Stjepan Rajko | 1 Mar 01:05
Picon
Favicon

Re: Bind + Function + Arguments

On Fri, Feb 29, 2008 at 6:08 AM, QbProg <tholag <at> gmail.com> wrote:
>
> [snip]
>
> function <void (int , int ) > FunctionOne;
> function < bool (int ) > FunctionTwo;
>
> class Implementor
> {
> public:
>      void ImplOne ( int , int );
>      bool ImplTwo ( int );
>  };
>
> void test ()
> {
>     Implementor i;
>
>     FunctionOne = bind ( &Implementor::ImplOne , &i , _1 , _ 2);
>     FunctionTwo = bind (&Implemenetor::ImplTwo, &i , _1);
>
>    /* I Would be nice to do something like this, with parameter "guessing"
> */
>      // FunctionOne = GenericBind ( &Implementor::ImplOne ,&i);
>     // FunctionTwo = GenericBind ( &Implementor::ImplTwo, &i);
>
>   /* This will greatly remove verbosity! */
>   /* Actually I do */
>   #define Bind0(A,B) bind(A,B)
>  #define Bind1(A,B) bind(A,B,_1)
(Continue reading)

Eloi Gaudry | 1 Mar 01:21
Picon

[boost::ublas] low level of performance with xlC


I'd like to get your point of view on the following topic: runtime
performance of binaries built against the IBM VisualAge c++ compilers.

I've been recently investigating (with a colleague) various performance
matters on a subset of platforms: Power 4 and Power 5 architecture
running on different flavors of the AIX operating system, using binaries
built with VisualAge C/C++ . We built and ran the boost::uBlas
regression tests using either the VisualAge C/C++ v.9 or the GCC 4.0
compilers. Using similar levels of optimization, we observed that the
GCC binaries were running much faster. The same tests were performed on
a Linux 64-bits machine using a standard Core2 processor and GCC-4.2 and
performance was again much much higher.

Are we missing something here, something that could allow us to get a
decent level of performance with the IBM compilers ?

Thanks,
Eloi

--

-- 

Eloi Gaudry

Free Field Technologies
Axis Park Louvain-la-Neuve
Rue Emile Francqui, 1
B-1435 Mont-Saint Guibert
BELGIUM

(Continue reading)

Tim Allison | 1 Mar 01:21

Re: A request for help using the Boost Unit Test Library


> 
> Tim Allison <tallison <at> meicompany.com> writes:
> 
>> I ran the -E option on the Gnu compiler.  Here is what I hope is the 
>> relevant output (at the end of the 38K resulting file!):
> 
> [...] 
> 
>> # 20 "/usr/include/boost/test/unit_test.hpp" 2 3 4
> 
> [...] 
> 
>> BOOST_AUTO_TEST_CASE( test1 )
> 
> Looks like this is Boost 1.33. You need 1.34 to build examples in new docs.
> 
> Gennadiy
> 
> 
Where do I find examples for Boost 1.33?  Based on your previous 
remarks, I used:
http://www.boost.org/libs/test/example/unit_test_example_01.cpp
It is copyrighted 2005.

Tim Allison
Sergei Politov | 1 Mar 05:25
Picon

Re: static assert

Hi,

I suggest the following solution:
============================================================
template<class F>
void testEnum(const F & f)
{
    BOOST_STATIC_ASSERT(!boost::is_enum<boost::function_traits<boost::remove_pointer<F>::type >::result_type >::value);
}

template <typename ContractType>
class C {
private:
    static void verify()
    {
        testEnum(&ContractType::st1);
        testEnum(&ContractType::st2);
    }
public:
    ~C() { verify(); }
};
============================================================

    The problem is "verify" function should be generated during compilation.
    If class "C" contains only static functions then you will have to invoke "verify" from all of them, to guarantie that verify will be generated.
    In other case it is enough to invoke "verify" from destructor.
   
Best Regards,
  Sergei

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sergei Politov | 1 Mar 05:46
Picon

Re: static assert

I've improved my solution by:
==============================================================
template<class F>
void testEnum(const F & f)
{
    BOOST_STATIC_ASSERT(!boost::is_enum<boost::function_traits<boost::remove_pointer<F>::type >::result_type >::value);
}

template<void (*)()>
struct Dummy {
    static const bool value = true;
};

template <typename ContractType>
class C {
private:
    static void verify()
    {
        testEnum(&ContractType::st1);
        testEnum(&ContractType::st2);
    }
    BOOST_STATIC_ASSERT(Dummy<&C::verify>::value);
};
==============================================================

So the problem I noticed is solved.

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Johan Råde | 1 Mar 09:16
Picon
Picon

Re: Ann: Floating Point Utilities Review starts today

Robert Kindred wrote:
>>> Just a quick reply: Is there any plans to include efficient comparison
>>> (equality) of floating point numbers? I could not find anything
>>> related in the library docs.
>>>
>>> Hermann O. Rodrigues
>> No.
>>
>> --Johan
> 
> I would like to second this motion, as there are many pitfalls in doing this 
> manually.  Here is a link I found on the pitfalls involved and ways to solve 
> them:
> 
> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
> 
> 
> Robert Kindred 

Why don't you write code for this and submit to Boost?

--Johan
Joel FALCOU | 1 Mar 12:28
Picon
Picon

Findign and replacing sub-expressions with boost::Proto

Hello,

I've started using boost::proto "prototype" to leverage the kernel code of
my expression templates based library and I wanted to know how the 
followign can be done.

Let's say such a statement is made :

matrix<float> a,b,c,r;
r = (a/b)+a+mul(b,c);

using Proto i was able to turn this into a SIMD aware code that use
SSE2 or Altivec (dependign on the platform) to operate.
However, in Altivec, the sub-expression a+mul(b,c) can be mapped to
a single, 3-ary vec_madd function that efficiently performs the mul-add 
operations.
This replacement leads to a 80-90% incrase of performacnes compared to 
chaining mul and add.

My question is : how can I use proto to detect such pattern (madd is an 
example, there is a lot of such pattern in SIMD code)
and build a new expression in which the a+mul(b,c) expression is 
replaced by the madd(a,b,c) expression ?

Thanks in advance.

PS : if this proto related question doesn't fit here, can someone 
redirect me to the correct list or people ?
Lothar May | 1 Mar 13:09
Picon

Re: boost exceptions on MacOS 10.5

Hi Daniel,

thank you very much for testing it. It's great that it works for you. 
Could you please tell me how you built boost? It seems you are using the 
i386 architecture. Is your boost build a universal build, i.e. will the 
programs run on PowerPC as well?

The problem for me is that I do not have a PowerPC based system, so I 
cannot build boost on a PowerPC and on an i386 system and copy them to a 
universal build - instead I need to compile both on the i386 system. The 
way I tried to do this, although as documented, seems to break the 
exception support. Maybe we can find a way to merge the way you are 
building boost with the additional options needed for a universal build.

Thanks again,

Lothar

Daniel Lord wrote:
> It worked fine for me:
> 
> [09:46:50] daniello <at> Mercury 
> ~/Documents/Development/Study/Xcode-Boost/BoostExceptionTest 
> $uname -a
> Darwin dhcp-2op9-2op10-east-130-35-99-215.usdhcp.oraclecorp.com 
> <http://dhcp-2op9-2op10-east-130-35-99-215.usdhcp.oraclecorp.com> 9.2.0 
> Darwin Kernel Version 9.2.0: Tue Feb  5 16:13:22 PST 2008; 
> root:xnu-1228.3.13~1/RELEASE_I386 i386
> [09:46:57] daniello <at> Mercury 
> ~/Documents/Development/Study/Xcode-Boost/BoostExceptionTest 
> $./BoostExceptionTest /fake
> This is never printed on MacOS 10.5.
> 
> 
> On 2/26/08, *Lothar May* <boost <at> lotharmay.de 
> <mailto:boost <at> lotharmay.de>> wrote:
> 
>     Hi Daniel,
> 
>     compiling boost is successful on my system, too. Are boost exceptions
>     caught using your build? Is your build universal?
> 
>       > I missed the thread on this, but I'll help you out if I can--just
>       > bring me up to speed.
> 
>     Sample test code is this:
> 
>     --cut here--
> 
>     #include <iostream>
>     #include <boost/filesystem.hpp>
> 
>     using namespace std;
>     using namespace boost::filesystem;
> 
>     int
>     main()
>     {
>          try
>          {
>              directory_iterator i("does_not_exist");
>          } catch(...)
>          {
>              cout << "This is never printed on MacOS 10.5." << endl;
>          }
>          return 0;
>     }
> 
>     --cut here--
> 
>     Best regards,
> 
>     Lothar
> 
> 
>     _______________________________________________
>     Boost-users mailing list
>     Boost-users <at> lists.boost.org <mailto:Boost-users <at> lists.boost.org>
>     http://lists.boost.org/mailman/listinfo.cgi/boost-users
> 
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hicham Mouline | 1 Mar 14:38

templates: parts of functions

Hi,

 

I have a function makeTree whose behavior depends on 3 different policies

typename T1

typename T2

int N

 

For performance reasons, I need to write the 2- and 3- specializations alongside the general N case. That is, the 2- and 3- default

instantiations generated from the N case by the compiler are not optimal.

 

As it is impossible to write function templates partial specializations, I encapsulate the

 

template< typename T1, typename T2, int N> void makeTree(Head<N>&, const T2&, const C&) ;

 

function in a class template

 

template< typename T1, typename T2, int N> class makeTree{

 void makeTree(Head<N>&, const T2&, const C&);

};

and write the partial specializations <T1,T2,2> and <T1,T2,3>.

 

 

Now, this makeTree function is quite large. It includes code that :

. doesn’t depend on any of the template arguments

. code that depends only T1

. code that depends only on T2

. code that depends only on N

. code that depends only on <T1,N>.

 

I am worried about code bloat, and the effect on overall performance of the actual code generated even if it is not run

(I noticed substantial effects depending on the size of object files and final shared library generated).

 

Besides this, I suppose it is a better design to have these segments of code put in template functions

with the right template arguments.

 

Is it MPL the library that I should look into for such work?

Perhaps nothing in Boost particularly facilitates this work, and std c++ templates are enough,

 

Thoughts, comments are appreciated,

 

Rds,

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hartmut Kaiser | 1 Mar 16:31
Picon
Gravatar

[Review] Proto review starts today, March 1st

Hi all,

The review of Eric Nieblers Proto library starts today, March 1st 2008, and
will end on March 14th. 
I really hope to see your vote and your participation in the discussions on
the Boost mailing lists!

---------------------------------------------------

About the library:

Proto is a framework for building Domain Specific Embedded Languages in C++.
It provides tools for constructing, type-checking, transforming and
executing expression templates. More specifically, Proto provides:
 * An expression tree data structure.
 * Operator overloads for building the tree from an expression.
 * Utilities for defining the grammar to which an expression must conform.
 * An extensible mechanism for immediately executing an expression template.
 * An extensible set of tree transformations to apply to expression trees.
 * A mechanism for giving expressions additional behaviors and members.

Documentation is here:
http://boost-sandbox.sourceforge.net/libs/proto

Download proto.zip from here:
http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapro
gramming

Proto is a very important infrastructure library, IHMO. It has been used as
the backbone for several other library writing efforts already, such as
Xpressive and the rewrite of Spirit (there it has been used for all three
parts: the parser, the lexer and the generator modules), and it is a key
enabling technology in the long-planned unification of Phoenix and the
Lambda Library.

---------------------------------------------------

Please always state in your review, whether you think the library should be
accepted as a Boost library!

Additionally please consider giving feedback on the following general
topics:

- What is your evaluation of the design?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library?
- Did you try to use the library?  With what compiler?  Did you have any
problems?
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
- Are you knowledgeable about the problem domain?

Regards Hartmut
Review Manager

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane