Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-09 16:07:16

Joel Falcou wrote:
>> I agree that something like that could be done, and there are plenty
>> of other AST transformations we would make to improve even simple
>> arithmetic expressions written by the user, but I'm not convinced we
>> should.  If the user is able to write the optimal expression himself
>> then my view is that a library does not need to optimize the user's
>> suboptimal expressions.  If the user sees a problem with the
>> expression he wrote (uses too much memory, runs too long) he can fix
>> it himself.  As a user I would not expect the library to optimize my
>> expressions for me, nor would I trust it to do so even if it claimed
>> in its documentation that it does unless I understood the details of
>> what it can or cannot do, which isn't something I would want to
>> invest time in.           
> he, compositionnal repalcement is nowhere from hard to expect.
>> We need to set a reasonable expectation for what the library should
>> do.  These exact same types of optimizations could be applied to my
>> Polygon library expression templates, but I judged it to be not
>> worthwhile.  The common case for use of the expression template is a
>> single operation and even in complex expressions that don't get
>> broken across multiple statements the opportunity for improving on
>> what was written is the exception, not the rule, and easily done
>> manually by the user.  Implementing a compiler as a template
>> metaprogram is exactly what I want to avoid in this case.  Every
>> user will pay the compilation cost imposed by the abstraction, while
>> few will benefit and those most in need of benefit are the ones who
>> will optimize their expression by hand and benefit least.           
>> 
>> 
> I never say that, it doesn't do any meta-compilation, just rearranging
> of trees before evaluation.
> And again your fear of compilation cost are vastly exagerated ...
> 
> Future of library design is exactly the opposite, leveragign details
> from user hands and implement them as active mechanism runnign at CT
> or 
> RT dependign ont he grain and scope of said operation. The more
> intentional and wrapped an interface can be the better. We now have
> the 
> tools to make the thingy implement itself automatically dependign on a
> alrge scope of factor so I really dont see the point of pushign this
> design forward. Are we Boost, the state of the art C++ lirbary or
> Boost 
> the overly conservative library ?

I agree with you about the future of library development, but I'm not convinced that the future is now.  If we had C++ concepts and (implicit) access to optimization algorithms implemented by the compiler for types that model concepts the compiler knows how to optimize *AND* the ability to write libraries that define new concepts and implement optimizations thereof to extend the compiler then I would say the future is now.  Right now it looks like the future is C++3x ratified in 2041.

So do we implement constant propigation and common sub expresion elimination in a general way using proto to optimize expressions of multi-precision integers that are confined to a single statement?  Constant propigation would require we implement infinite precision integer algorithms at compile time.  We probably don't want to do that, so lets just take common sub expression elimination.  Oops, we can't really tell if the arguments of an expression are the same or not in our template metaprogram, only what their types are, so we can't even implement common sub expression elimination.  I guess your right, we can't implement a compiler using proto and would be wise not to try in the instances where it is technically possible but highly impractical.  What we are left with is the ability to implement only a patchwork of half measures that prove that that sort of thing can be done, but that wouldn't really add much value to the library.  As a library user I'm not interested in the technical reason why it can't implement basic optimization passes, only that it fails to do the obvious optimizations that I could easily do manually.  What you need to do this right in C++ we have now is a JIT compiler implemented in a library, not proto.  While we are at it we can use that JIT compiler to SSE accelerate the algorithms and then dispatch them to many cores or even the GPU.  We may be boost, but we should know our limitations.

Regards,
Luke