Re: Status of development /Benchmarks

Hi guys,


 > the whole problem of most numerical packages, IMHO, is that everything
> is tied together. I would encourage a very loosely coupled system. I.e.,
> a system that maybe even would be able to switch storage layout,
> algorithms, etc., at run-time, maybe following some simple numerical
> tests. Of course, only if this would be enabled at compile-time.

 From my experience with rebuilding the uBLAS interface within ViennaCL 
I fully support this suggestion.


> * the storage of data. This is about memory-efficiency, and hence, speed
> of computation. Storage engines might be linear, sparse, etc..
> * functional shape of the data. Dense, triangular, etc.
> * numerical properties of the data. Positive definite, etc.
> * loading and saving the data. Why not support a whole bunch of
> data-formats
> * unified matrix/vector view on the data
> * procedural manipulation of the data, shallow views on the data, views
> on views, etc.

One important question should be answered upfront: Should ublas focus on 
linear algebra for 'small' vectors/matrices, or 'big' vectors/matrices? 
I don't consider 'both' a legitimate answer here, because the two 
extremes have highly diverse requirements:
  - For 'small' data (say, 10x10) one goes with expression templates, 
just because any additional runtime overhead is not acceptable.
  - For 'large' data one can do a lot of tricks with respect to avoiding 
memory transfers with some delayed execution techniques. Also, this is 
the regime where one can slowly start to think about threads, 
accelerators, etc. Most machine-specific metrics then become only 
available at runtime, so one needs some runtime logic in addition to 
expression templates anyway. One may even get rid of expression 
templates here and instead enjoy faster compilation times and increased 
flexibility at runtime.

Just my 2 cents of course... :-)

Best regards,
Karli