Link Copied
IgorLevicki:
As for avoiding destructor, what if you need to derive a class which also has to do some house-keeping of its own? What if you need virtual destructor? Sorry, removing it is not a solution, just a workaround and a lousy one at best because it might break in the future.
My experience is that advanced C++ and high performance are not always good friends. Well, for the sake of software structure you may use advanced language features like inheritence, virtual functions and templates, but if you are not careful, this may also lead to poor performance - it is a common misconception among most C++ programmers that C++ actually is so useful in supercomputing. They have all been mislead by Bjarne Stroustrup's The C++ Programming Language (2007). He states that "Consequently, the standard library provides a vector - called valarray - designed specifically for speed of the usual numeric vector operations. Following his code (pp 662-674),
#include#include #include #include #define SIZE 4000 template class Slice_iter { std::valarray *v; std::slice s; size_t curr; T& ref(size_t i) const {return (*v)[s.start()+i*s.stride()]; } public: Slice_iter(std::valarray *vv, std::slice ss): v(vv), s(ss), curr(0) { } T& operator[](size_t i){ return ref(i); } T& operator[](size_t i) const { return ref(i); } }; template class Cslice_iter { std::valarray *v; std::slice s; size_t curr; T& ref(size_t i) const {return (*v)[s.start()+i*s.stride()]; } public: Cslice_iter(std::valarray *vv, std::slice ss): v(vv), s(ss), curr(0) { } T& operator[](size_t i) const { return ref(i); } }; class Matrix { std::valarray< float > *v; size_t r, c; public: Matrix(size_t x, size_t y){r=x;c=y;v = new std::valarray (0.,x*y);} Slice_iter< float > row(size_t i ) { return Slice_iter< float >(v, std::slice(i*c, c, 1)); } Cslice_iter< float > row(size_t i ) const { return Cslice_iter< float >(v, std::slice(i*c, c, 1)); } Slice_iter< float > operator[](size_t i) {return row(i);} Cslice_iter< float > operator[](size_t i) const {return row(i);} }; int main() { int i, j, k; Matrix a(SIZE,SIZE),b(SIZE,SIZE),c(SIZE,SIZE); clock_t start, finish; for(i = 0; i < SIZE; i++){ for(j = 0; j < SIZE; j++){ b = a = (float)rand()/RAND_MAX; c = 0.0; } } start = clock(); for(i=0;i = c + a * b ; finish = clock(); printf("%f %f ",(float)(finish - start)/CLOCKS_PER_SEC, c[0][0]); }
extends the 4000x4000 float matrix multiplication simulation time to 620.2 seconds, even with the latest Intel C++
10.0 compiler. I have seen developers argueing that Intel C++ Compiler is no better than other compilers when the actual problem is that the software they have written is completely resistant to any compiler optimizations, exactly like the above Matrix suggested by Bjarne Stroustrup.
Best Regards,
Lars Petter Endresen.
Sorry for the confusion Igor - you need to set a global enironment variable KMP_STACKSIZE to 512m.When you have an executable that runs, please report back the fastest of 5 successive runs, because the programs runs better when the caches are warm.
To help you out Igor, I have posted a showstopper to premier support "Cannot align class with destructorIssue Number 481167". My experience with premier support is that they usually resolve issues quickly, in particular ifI manage to convince them that this is of importance for the general public. I never write any code with destructors, that's why I never saw your crash Igor (I like classes and the many other features of C++ like copy-constructors and in particular the composition paradigm which is good for performance).
And they are most likely right not only it is not better but it seems to be worse.
Let us put ourselves in the shoes of Intel Compiler Team - should they honor stupid people writing stupid software or smart people writing smart software? I mean, they have limited resources and must do some choices, what is the most important feature of our compiler? I couple of years ago they "merged" the advanced optimizations of Compaq Visual Fortran, first into Intel Visual Fortran and then into Intel C++, meaning that similar semantics in C++ and FORTRAN gives almost exactly the same assembly code and performance (try yourselves!), in particular if you write FORTRAN style C code, using features in C99 like restrict. But this is not the approach of most C++ programmers that have been mislead by many C++ books like "Effective C++" and "MoreEffective C++".
To summarize, dependent of the problem at hand use,
- Intel C++ without intrinsics,
- Intel C++ with intrinsics,
- Microsoft C++ with/without intrinsics.
In large software projects I prefer to use Microsoft C++ for the code that is not performance critical because it compiles so quickly, but try to write as much as possible of the performance critical code without using intrinsics. My experience is also that many well written codes written for other platforms or systems gives excellent performance "out of the box" with Intel C++, because many developers have known for a long time what is meant by "compiler friendly".
You do not need to improve the matrix multiplication any more, my point is that in many cases it is quite difficult to match the compiler with your own code (implementing unroll-and-jam may also be a laborious process...)
Best Regards,
Lars Petter Endresen
And they are most likely right not only it is not better but it seems to be worse.
Let us put ourselves in the shoes of Intel Compiler Team - should they honor stupid people writing stupid software or smart people writing smart software? I mean, they have limited resources and must do some choices, what is the most important feature of our compiler? I couple of years ago they "merged" the advanced optimizations of Compaq Visual Fortran, first into Intel Visual Fortran and then into Intel C++, meaning that similar semantics in C++ and FORTRAN gives almost exactly the same assembly code and performance (try yourselves!), in particular if you write FORTRAN style C code, using features in C99 like restrict. But this is not the approach of most C++ programmers that have been mislead by many C++ books like "Effective C++" and "MoreEffective C++".
To summarize, dependent of the problem at hand use,
- Intel C++ without intrinsics,
- Intel C++ with intrinsics,
- Microsoft C++ with/without intrinsics.
In large software projects I prefer to use Microsoft C++ for the code that is not performance critical because it compiles so quickly, but try to write as much as possible of the performance critical code without using intrinsics. My experience is also that many well written codes written for other platforms or systems gives excellent performance "out of the box" with Intel C++, because many developers have known for a long time what is meant by "compiler friendly".
You do not need to improve the matrix multiplication any more, my point is that in many cases it is quite difficult to match the compiler with your own code (implementing unroll-and-jam may also be a laborious process...)
Best Regards,
Lars Petter Endresen
