[Help-gsl] Re: Question: gsl in C++ ??

[Lionel B]

On Thu, 15 Mar 2007 09:05:31 -0600, Jordi Gutierrez Hermoso wrote:

> Are we offtopic yet?
> 
> On 15/03/07, Lionel B <address@hidden> wrote:
>> > (here's our chance to start indexing from 1 à la GNU Octave!)
>>
>> No, please!
> 
> Wow, ex-Fortran programmer objects to this?

Did say very ex, now C++ ...

> I'll make indexing from 1 optional; personally I think that it makes
> more sense for numerical work since formulae usually are written 1, ...,
> n. Meh, not a big deal, though. ;-)

No I don't think so either. It may not be a huge (coding) overhead to
provide a choice (perhaps as a compile-time option) to allow for
individual coding styles - no doubt this is the stuff of holy wars ;) 

>> > We should also look into implementing gsl_vector with valarrays
>> > instead of direct memory manipulation, but this might break
>> > compatibility with BLAS.
>>
>> I think valarrays are a good idea - relieves the burden of memory
>> management... and valarrays are completely BLAS-friendly too,
> 
> You seem knowledgeable about this. What do you think about the Boost
> implementation of a BLAS interface?

Don't know really, I've never used uBLAS. My suspicion would be that
a low-level well-tuned BLAS (eg. vendor-supplied or something like
ATLAS) which can take advantage of a specific CPU architecture (cache
size, pipelines, what-have-you) is always going to win out in speed over a
"generic" implementation such as uBLAS. On my current setup I find that
ATLAS or the Intel BLAS performs sometimes orders of magnitude faster on
large dense matrices than the generic "reference" BLAS supplied with my
system. Perhaps now, though, compiler optimisation technology has advanced
to the point where this is less of an issue.

> I haven't looked at the underlying mechanics of how they're doing it,
> but it's probably a good idea to build upon their work instead of
> attempting a C++ implementation of GSL from scratch with valarrays.

I do think it would be a good idea to take design ideas from uBLAS - and
some of the other matrix libraries people have mentioned - but I'd still
like to see an option to "plug in" a BLAS implementation of the user's
choice.

> Also, you touted the benefits of valarrays with respect to aliasing, but
> it seems that even the original inventor of valarrays admits that this
> might not be the case because compilers are not taking advantage of the
> anti-aliasing of valarrays (I can't find the newsgroup message where I
> read this).

Never new about that... my suspicion would be that this might vary
considerably between compilers and platforms. My own, totally anecdotal,
experience on my current work setup (dual Xeon workstation running Linux)
is that the Intel compiler (9.0) does a notably better job than gcc (4.1)
on optimising valarray-heavy number crunching code (although, perversely,
it also seems to perform somewhat worse on STL container-heavy pointer
chasing code).

-- 
Lionel B