RE: [boost] Re: Re: Boost Mathematicians

Behalf Of Thorsten Ottosen Sent: Thursday, 3 June 2004 4:25 PM
"Reid Sweatman" <drunkardswalk@earthlink.net> 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@sig.com 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.

"Hurd, Matthew" <hurdm@sig.com> wrote in message news:BA1220310B07EC4A8E321B451E07AF4784833F@msgbal501.ds.susq.com... | 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. yeah, we want move semantics. | 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.
From what I now, we cannot put C and C++ into the same basket. See Type-Based Alias Analysis:
http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm?temp=fXniOPb1aS I my suggestion for Design by Contract I mentioned that aliasing (or lack of it) could be expressed by a function precondition: void foo( T* l, T* r, size_t sz ) precondition() { std::less<T*>( l + sz, r ) || std::less<T*>( r + sz, l ); }; | You still need to wrap as you can't hope, nor should you try, to offer | all algorithms from all languages. probably not. But simply wrapping stuff is not always an option. For eaxample, in the statistics lib I'm working on, I need to invert matrices. If I write wrappers, I will probably only be ably to support float,double,complex leaving out higher precsion datatypes. br Thorsten
participants (2)
-
Hurd, Matthew
-
Thorsten Ottosen