Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > incredible slowdown switching to 64 bit g++

Reply
Thread Tools

incredible slowdown switching to 64 bit g++

 
 
nandor.sieben@gmail.com
Guest
Posts: n/a
 
      11-25-2008
I have a fairly complex C++ program that uses a lot of STL, number
crunching using doubles and the lapack library (-llapack -lblas -lg2c -
lm). The code works fine on any 32 bit unix machine compiled with g++
but when I try it on a 64 bit machine a running time of 10 seconds
becomes 15 minutes. The code is complex, I could not create a simple
subset that produces this problem. I tried this on several 32 and 64
bit machines. The speed of the machines are comparable. I use -O2
optimization. The program is not swapping to disk. What could cause
this incredible slowdown?

Some suspects:

-The lapack library
- Tolerances I use for floating point comparisons
- Large vector<vector<int > > variables ( even vector<vector<vector< >
> > variable )

- Need a compiler option on the 64 bit machines?
- Random number generator

 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      11-25-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> I have a fairly complex C++ program that uses a lot of STL, number
> crunching using doubles and the lapack library (-llapack -lblas -lg2c -
> lm). The code works fine on any 32 bit unix machine compiled with g++
> but when I try it on a 64 bit machine a running time of 10 seconds
> becomes 15 minutes. The code is complex, I could not create a simple
> subset that produces this problem. I tried this on several 32 and 64
> bit machines. The speed of the machines are comparable. I use -O2
> optimization. The program is not swapping to disk. What could cause
> this incredible slowdown?

[snip]

Just A Quick question: does the program do the same thing on a 64bit machine
as on a 32bit machine? has testing shown that for the same input you get
the same output?


Best

Kai-Uwe Bux
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-25-2008
(E-Mail Removed) wrote:
> I have a fairly complex C++ program that uses a lot of STL, number
> crunching using doubles and the lapack library (-llapack -lblas -lg2c -
> lm). The code works fine on any 32 bit unix machine compiled with g++
> but when I try it on a 64 bit machine a running time of 10 seconds
> becomes 15 minutes. The code is complex, I could not create a simple
> subset that produces this problem. I tried this on several 32 and 64
> bit machines. The speed of the machines are comparable. I use -O2
> optimization. The program is not swapping to disk. What could cause
> this incredible slowdown?
>

You'll have to profile to find out. It's not uncommon for 64 bit
executables to be slower when the code has been tuned for 32bit. That's
one reason why 32 bit executables are still common on 64 bit platforms.

> Some suspects:
>
> -The lapack library
> - Tolerances I use for floating point comparisons


Shouldn't matter.

> - Large vector<vector<int > > variables ( even vector<vector<vector< >
>>> variable )


Shouldn't matter. A heavy use of long might.

Try a gcc or Linux group or maybe comp.unix.programmer.

--
Ian Collins
 
Reply With Quote
 
nandor.sieben@gmail.com
Guest
Posts: n/a
 
      11-25-2008
> Just A Quick question: does the program do the same thing on a 64bit machine
> as on a 32bit machine? has testing shown that for the same input you get
> the same output?


There are small differences in the values of doubles but I guess
that's not unexpected.


 
Reply With Quote
 
nandor.sieben@gmail.com
Guest
Posts: n/a
 
      11-25-2008
> You'll have to profile to find out. *

I did try profiling but I did not make much sense of it. Generally it
seemed
like everything takes somewhat longer.

> It's not uncommon for 64 bit
> executables to be slower when the code has been tuned for 32bit. *That's
> one reason why 32 bit executables are still common on 64 bit platforms.


But could it be such a huge difference? What does it mean to be tuned
for 32bit?
The code does not depend on it, could it be that the STL library is
optimized for
32 bit or the lapack library?

> Shouldn't matter. *A heavy use of long might.


No long in the code.
 
Reply With Quote
 
nandor.sieben@gmail.com
Guest
Posts: n/a
 
      11-25-2008
> It's not uncommon for 64 bit
> executables to be slower when the code has been tuned for 32bit. *That's
> one reason why 32 bit executables are still common on 64 bit platforms.


I am not trying to run the executable compiled on the 32 bit machine.
I recompile
everything on the 64 bit machines.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-25-2008
(E-Mail Removed) wrote:
>> It's not uncommon for 64 bit
>> executables to be slower when the code has been tuned for 32bit. That's
>> one reason why 32 bit executables are still common on 64 bit platforms.

>
> I am not trying to run the executable compiled on the 32 bit machine.
> I recompile
> everything on the 64 bit machines.


Why?

--
Ian Collins
 
Reply With Quote
 
nandor.sieben@gmail.com
Guest
Posts: n/a
 
      11-25-2008
> > I am not trying to run the executable compiled on the 32 bit machine.
> > I recompile
> > everything on the 64 bit machines.

>
> Why?


It is my own code. Since I have the source code it makes sense to
recompile and hope it
will be optimized for the new machine. I don't know if the 32 bit
executable would run on
the 64 bit machines but perhaps I should try that.

Could this piece of code be responsible?

extern "C"
{
void dsyev_ (const char *jobz,
const char *uplo,
const int &n,
double a[],
const int &lda,
double w[], double work[], int &lwork, int &info);
}

int
dsyev (const vector < vector < double > >&mat, vector < double
>&eval,

vector < vector < double > >&evec)
{
....
dsyev_ ("V", "U", n, a, n, w, work, lwork, info);
....
}

This is how I use the fortran lapack library. Perhaps the type sizes
change differently in C++ and in Fortran
when going from 32 bit to 64 bit.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-25-2008
(E-Mail Removed) wrote:
>>> I am not trying to run the executable compiled on the 32 bit machine.
>>> I recompile
>>> everything on the 64 bit machines.

>> Why?

>
> It is my own code. Since I have the source code it makes sense to
> recompile and hope it
> will be optimized for the new machine. I don't know if the 32 bit
> executable would run on
> the 64 bit machines but perhaps I should try that.
>

Under any decent OS, they should. I don't use 32 bit systems any more
and I seldom build 64 bit executables.

> Could this piece of code be responsible?
>
> extern "C"
> {
> void dsyev_ (const char *jobz,
> const char *uplo,
> const int &n,
> double a[],
> const int &lda,
> double w[], double work[], int &lwork, int &info);
> }
>

doubles or ints shouldn't be an issue.

You'd should try asking on a more specialised group. You should be able
to find a 64 porting guide for your platform.

--
Ian Collins
 
Reply With Quote
 
Maxim Yegorushkin
Guest
Posts: n/a
 
      11-25-2008
On Nov 25, 6:21*am, (E-Mail Removed) wrote:
> I have a fairly complex C++ program that uses a lot of STL, number
> crunching using doubles and the lapack library (-llapack -lblas -lg2c -
> lm). The code works fine on any 32 bit unix machine compiled with g++
> but when I try it on a 64 bit machine a running time of 10 seconds
> becomes 15 minutes. The code is complex, I could not create a simple
> subset that produces this problem. I tried this on several 32 and 64
> bit machines. The speed of the machines are comparable. I use -O2
> optimization. The program is not swapping to disk. What could cause
> this incredible slowdown?


[]

Have you tried comparing 32 and 64-bit versions compiled on the very
same machine? Use -m32 compiler switch to compile a 32-bit version.

--
Max
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the point of having 16 bit colour if a computer monitor can only display 8 bit colour? How do you edit 16 bit colour when you can only see 8 bit? Scotius Digital Photography 6 07-13-2010 03:33 AM
Process Switching vs. Fast/CEF Switching? asdf Cisco 7 05-29-2007 05:26 PM
"LoadLibrary" of a 32 bit so with 64 bit java on a 64 bit machine markryde@gmail.com Java 3 01-19-2007 10:30 PM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit, Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new ! vvcd Computer Support 0 09-17-2004 08:15 PM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit,Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new! Ionizer Computer Support 1 01-01-2004 07:27 PM



Advertisments