|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2013-12-09 10:14:55
Karli,
I am not so sure the requirements for smal /large containers are so
diverse. After all you can have compile-time dispatching for small
(static) or large (dynamic) containers if you want to use different
algorithms for each or for mixed cases. Can you please elaborate if I am
not getting it right?
-Nasos
On 12/09/2013 09:49 AM, Karl Rupp wrote:
> 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
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]