Re: Matrix

From: jlecomte1972_at_[hidden]
Date: 2001-03-13 11:39:54

--- In boost_at_y..., Ronald Garcia <rgarcia4_at_c...> wrote:
>     JL> That's where I don't quiet follow. Isn't the best way to
>     JL> achieve Fortran speed, to call Fortran ??? I don't see the
>     JL> point in pushing further the expression template trend
> In order to get both mathematical notation and performance in 
> C++, you
> need to have expression templates.  The reason is that use of
> operators leads to a  proliferation of temporaries as each
> operator is called. 

Yeeeaaah. I don't know it's a tradeoff. You can go for total 
mercyless optimization alla Blitz (very hard to build and to 
maintain, lengthy build when you use it even in debug mode), or you 
can optimize the most comon operation like Ax+B (easier but granted 
that you are unlikely to satisfy everyone) and allow some copies.

The thing is we are not talking about iostream<> here. The compiler 
is really pushed to the limits with template meta programming; and 
the programmer too: I tried to use Blitz a year or 2 ago and I just 
choke. Maybe that explains my concerns.

>     JL> ... This is a nice concept, and something to develop for the
>     JL> future (when compilers better support export keyword) but
>     JL> right now, I would support something along the line of
>     JL> lapack++ (commercial by RogueWave) where the C++ is actually
>     JL> just an interface to Fortran code.
> I'm not quite sure what would be gained by the use of the export
> keyword in this case.  Writing good libraries often involves 
pursuing
> some hard work, but the expected benefit is that the library is then
> easy to use practically (ie. with expected good performance) out of
> the box.  That's one of the great benefits of the C++ standard
> library.  
> 
> Another benefit of ditching Fortran is the possibility of a portable
> tunable library.  I'd highly recommend taking a look at the MTL and
> Jeremy Siek's M.S. thesis. Many of these issues have been considered
> therein.

I will. I promise.

> I don't like the road this is going down.  I find it very sensible
> that Boost.Python would require the availability of Python on an
> architecture, but requiring Fortran and a Fortran library for a C++
> library seems far less than ideal.  We can do much better than this.
> 
> ron