|
Boost : |
From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-06-03 02:34:06
> Behalf Of Thorsten Ottosen
> Sent: Thursday, 3 June 2004 4:25 PM
>
> > "Reid Sweatman" <drunkardswalk_at_[hidden]> wrote in message
>
> | Oddly enough, scientists is usually pretty
> | conservative folk; they like what they know.
>
> Is that so odd? Yesterday I talked with a matematician here in Sydney
about
> Fortran.
> He uses Fortran because it is good enough for what he is doing. It
would
> probably take quite some
> time for him to learn C++, so why should he?
>
> br
>
> Thorsten
There is an often seen misconception that C/C++ should be as fast as it
gets as the programming model is close to the instruction model of the
machine. In practice FORTRAN is usually faster.
At one level, in C++ this slowness this is usually because of
temporaries and expression templates and modern optimizing compilers can
often mitigate this for typical math calcs. Other abstraction penalties
apply.
Another level is the fundamental differences in aliasing between the
language definitions.
FORTRAN as a language does not allow aliasing ambiguities which makes
the optimizers job a lot easier and the code can be a lot faster. C/C++
assumes aliasing potential which makes optimizing very hard. A C/C++
compiler may allow aliasing to be disabled for a section of code or for
the whole program, but you need to be confident in what you are doing.
Very clever global analysis is needed to cure the aliasing problem, and
given the potential for run time gymnastics, it may not be possible at
all.
Have a look at these benchmarks judging Todd V's blitz to FORTRAN:
http://www.oonumerics.org/blitz/benchmarks/
Boost's equivalent to Blitz++ is uBLAs.
More discussion on C++ versus FORTRAN speed can be found here:
http://osl.iu.edu/~tveldhui/papers/iscope97/
I do think it is worthwhile writing C++ to do this stuff as the
abstraction is much better for the library client IMO. At some levels
the implementation may be tougher for the library writer, as some of the
optimizer gymnastics ends up in the expression templates, but given the
right framework it may be simply extensible and suitable for even
relatively unsophisticated mathematicians to contribute library
components.
You still need to wrap as you can't hope, nor should you try, to offer
all algorithms from all languages.
Another lobbed $0.005,
Matt Hurd.
_______________
Matt Hurd
+61.2.8226.5029
hurdm_at_[hidden]
Susquehanna
Sydney
_______________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk