[boost] Re: Boost Mathematicians

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-04 11:48:34

"Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:

> --- David Abrahams <dave_at_[hidden]> wrote:
>> > You are hitting the nail on the head. Experience with my own
>> > reference-counted array type tells me that the issue of
>> > immutability/constness needs extreme care. My own solution has the
>> > glaring shortcoming of not providing a const-reference-counted array
>> > type (excuses available on request :-). But having said that, I found
>> > it a lot worse not to be able to write a function that returns a new
>> > array without incurring a deep copy. 
>> 
>> It seems quite a few compilers implement one or another form of RVO.l
>
> Sorry, I don't know what RVO.l is. Is it portable? Does code exploiting RVO.l
> to achieve move semantics look intuitive?

Sorry, the "l" was a typo.  I meant Return Value Optimization, where
values can be returned from functions without actually invoking the
copy ctor.

>> I guess you haven't read the MTL concept breakdown:
>
> Right. When I started with my array library (two years ago) it was clear that
> MTL is too specialized for my purposes.
>
>>   - Shape
>>   - Storage (I think this is what you're calling memory management)
>>   - Orientation (row-major, column-major, diagonal-major...)
>
> Is "Orientation" a specialization of "Shape". Couldn't both be viewed as
> "Indexing models?"

No, shape is separate.  No point in me trying to explain here when
you can google for a good explanation from the MTL authors, though ;-)

>> > 1. I found the following memory management models for arrays to
>> >    be essential in practical applications (i.e. I implemented
>> >    them all, and make heavy use of all):
>> >
>> >        stack, fixed size
>> >        stack, variable size, fixed capacity
>> >        heap, variable capacity, one owner (e.g. std::vector)
>> >        heap, variable capacity, shared ownership
>> >        reference to any of these (i.e. "no management")
>> 
>> That's storage.
>
> Right. Which of these are you going to support?

Whatever you like.  There will be well-formed concepts, so you can
build any storage policy you like if it isn't directly supplied.

>> > 4. Array algebras (unary and binary operators, functions) are a third
>> >    property that is ideally separated from memory models and, if
>> >    applicable, indexing models. This could lead to:

HilbertSpace, BanachSpace, VectorSpace, LinearAlgebra, RModule, Field,
Ring, AbelianGroup, LinearOperator, TransposableLinearOperator were
the algebraic concepts we had in mind.  I don't think these things
should neccessarily be part of the array type though.

> Does my generic array design look too daunting? 

Not neccessarily... but I doubt I'm going to implement your design.
We have specific needs ;-).

> Do we have to wait for another language before array libraries can
> be implemented in such a generic way?

I don't know what you mean.  We do intend to make the MTL rewrite very
generic.

>> > 5. Expression templates are an optimization on top of all this and
>> >    in my practical experience the least important of all the points
>> >    mentioned here. In all likelihood the 5-10% of code that matter for
>> >    runtime performance have to be hand-optimized anyway, usually
>> >    leading to distortions of the original, intuitive code beyond
>> >    recognition. 
>> 
>> The aim is to make the library smart enough to do those optimizations
>> correctly so you don't have to do it by hand.
>
> A case of "premature optimization?" 

No, one of the main _goals_ of this project (from a CS/research
point-of-view) is to demonstrate that it can be done.

> I am still waiting for an example of real-world code where the
> critical section is so large that the reduction in code size/gain in
> maintainability due to the availability of expression templates
> would justify the cost of implementing the ET library and the
> increased compile times. 

I think iterative solvers are a good example.  But expression
templates shouldn't be hard to implement given modern TMP knowledge
and I can see no reason they need to induce long compile times either.

> -- Maybe I am just too spoiled by Python. :-) I am constantly taking
> a performance hit of about two orders of magnitude, writing only the
> critical code in C++, and it turns out to be very practical because
> the old 90-10 rule is true!  

Of course it is.  If you're taking a performance hit of about two
orders of magnitude in your linear algebra code, and you can still
afford it, you're simply not in a domain where it matters all that
much; other computations are swamping those costs.

> Sometimes I even win out compared to brute force number crunching
> approaches because the very high abstraction level of Python allows
> me to push bookkeeping and high-level decision making to a point
> where I know how to skip much of the brute force work.

I'll have to take your word for it.  It seems to me that if you can
skip the brute force work in Python you can do it in C++, too.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com