/*
While writing a C++ version of the Mandelbrot benchmark over at the
"The Great Computer Language Shootout"...
....I've come across the issue that complex<double> 's seem quite slow
unless compiled with -ffast-math. Of course doing that results in
incorrect answers because of rounding issues. The speed difference for
the program below is between 5x-8x depending on the version of g++. It
is also about 5 times slower than the corresponding gcc version at...
....I'd be interesting in learning the reason for the speed difference.
Sure, the C version is slightly more optimized, but I was thinking that
the C++ code should only be 20-50% slower, not 750% slower like I get
with g++-4.1.0pre021006 (g++ 3.4.2 is a factor of 5 slower when
compiling with "-O3" vs. "-O3 -ffast-math"). Does it have something to
do with temporaries not being optimized away, or somesuch? A
limitation of the x87 instruction set? Is it inherent in the way the
C++ Standard requires complex<double> 's to be calculated? My bad coding
style? Limitations imposed by g++?
Curious,
Greg Buchholz
*/
// Takes an integer argument "n" on the command line and generates a
// PBM bitmap of the Mandelbrot set on stdout.
// see also: ( http://sleepingsquirrel.org/cpp/mandelbrot.cpp.html )
#include<iostre am>
#include<comple x>
int main (int argc, char **argv)
{
char bit_num = 0, byte_acc = 0;
const int iter = 50;
const double limit_sqr = 2.0 * 2.0;
std::ios_base:: sync_with_stdio (false);
int n = atoi(argv[1]);
std::cout << "P4\n" << n << " " << n << std::endl;
for(int y=0; y<n; ++y)
for(int x=0; x<n; ++x)
{
std::complex<do uble> Z(0.0,0.0);
std::complex<do uble> C(2*(double)x/n - 1.5, 2*(double)y/n -
1.0);
for (int i=0; i<iter and norm(Z) <= limit_sqr; ++i) Z = Z*Z +
C;
byte_acc = (byte_acc << 1) | ((norm(Z) > limit_sqr) ?
0x00:0x01);
if(++bit_num == 8){ std::cout << byte_acc; bit_num = byte_acc =
0; }
else if(x == n-1) { byte_acc <<= (8-n%8);
std::cout << byte_acc;
bit_num = byte_acc = 0; }
}
}
While writing a C++ version of the Mandelbrot benchmark over at the
"The Great Computer Language Shootout"...
....I've come across the issue that complex<double> 's seem quite slow
unless compiled with -ffast-math. Of course doing that results in
incorrect answers because of rounding issues. The speed difference for
the program below is between 5x-8x depending on the version of g++. It
is also about 5 times slower than the corresponding gcc version at...
....I'd be interesting in learning the reason for the speed difference.
Sure, the C version is slightly more optimized, but I was thinking that
the C++ code should only be 20-50% slower, not 750% slower like I get
with g++-4.1.0pre021006 (g++ 3.4.2 is a factor of 5 slower when
compiling with "-O3" vs. "-O3 -ffast-math"). Does it have something to
do with temporaries not being optimized away, or somesuch? A
limitation of the x87 instruction set? Is it inherent in the way the
C++ Standard requires complex<double> 's to be calculated? My bad coding
style? Limitations imposed by g++?
Curious,
Greg Buchholz
*/
// Takes an integer argument "n" on the command line and generates a
// PBM bitmap of the Mandelbrot set on stdout.
// see also: ( http://sleepingsquirrel.org/cpp/mandelbrot.cpp.html )
#include<iostre am>
#include<comple x>
int main (int argc, char **argv)
{
char bit_num = 0, byte_acc = 0;
const int iter = 50;
const double limit_sqr = 2.0 * 2.0;
std::ios_base:: sync_with_stdio (false);
int n = atoi(argv[1]);
std::cout << "P4\n" << n << " " << n << std::endl;
for(int y=0; y<n; ++y)
for(int x=0; x<n; ++x)
{
std::complex<do uble> Z(0.0,0.0);
std::complex<do uble> C(2*(double)x/n - 1.5, 2*(double)y/n -
1.0);
for (int i=0; i<iter and norm(Z) <= limit_sqr; ++i) Z = Z*Z +
C;
byte_acc = (byte_acc << 1) | ((norm(Z) > limit_sqr) ?
0x00:0x01);
if(++bit_num == 8){ std::cout << byte_acc; bit_num = byte_acc =
0; }
else if(x == n-1) { byte_acc <<= (8-n%8);
std::cout << byte_acc;
bit_num = byte_acc = 0; }
}
}
Comment