C++ vs Fortran 90 Speed


JTech
06-20-2002, 11:21 AM
Hello,
I have created some code that uses svdcmp and svbksb functions to perform a best fit of a 2D polynomial to a matrix dataset.

This code has previously been compiled using Fortran 90, with good results. The DLL is called from VB and runs in about 1.5 seconds.

I recently ported this code to Visual C++ 6 and noticed a decrease in speed of about 7X. DLL runs in about 7 seconds. The DLL's are essentially identical, and yield identical numerical results. After doing some investigation, it appears the svdcmp routine is taking up over 6 sec of processing time. Could it be the overhead created when returning an array element using the inline subscripting function NRMat? Any time the svd function looks for an array value, this subscripting function is called. This is the only explanation I can think of.

Any other ideas/suggestions as to why the difference in speed is appreciated. Or...is this difference considered normal?

Thanks in advance for any comments!

Bill Press
06-20-2002, 06:43 PM
Interesting!

Do you have the VC++ compiler set for its highest optimization level? If you do, could you try compiling at a *lower* optimization level and see if it makes a difference -- makes it even worse?

Another interesting test would be if you are willing to redo the DLL using the NR in C (not C++) SVDCMP routine, which does its matrix element dereferences by a fast pointer-to-pointer-to-row scheme.

One thing that this points out is that Fortran, for all the scorn sometimes heaped on it, does boast some very optimized compilers for numerical work!

JTech
06-20-2002, 09:08 PM
Bill,

Thanks for your reply. You made me realize that I was compiling a debug version. Duh! I compiled a release version using the Default settings in VC++ and the time went down to just over 2 sec! I am new to VC++ so I will excuse myself for this oversight!

I used the Default settings because I ran into trouble compiling under the Maximize Speed settings (this adds the switch /O2 to the options). I get a C1001 INTERNAL COMPILER ERROR originating from svdcmp at the line that calls the pythag routine for the first time (?). To test whether it was me or not, I tried to compile the xsvgcmp from the examples, with the same error. Have you experienced this? I would like to compile with this setting to see how fast I can make this DLL.

Again, thanks in advance - This forum is very helpful to folks like me!

Best regards,

Eatsum.com
11-20-2002, 04:36 PM
Compile Parallel Fast (CPF) will speed up the compilation of your C/C++/Fortran projects up to 4(FOUR) times.
CPF is compatible with Microsoft Visual C++® 7x (.NET), 6.x and 5.x.
Absolutely NO modifications to your source code are required. Only minimal or no modifications to your make files and batch files would be necessary.
Source code to be compiled can reside on local or network drives.
CPF is easy to install, configure and use. And it provides a comprehensive set of graphical tools to perform administrative tasks. You can even spy on which computer each compiler command line is executed ;)
. (http://www.eatsum.com)

tonyz
01-29-2003, 08:47 PM
CPF is compatible with Microsoft Visual C++® 7x (.NET)!

That helps me somewhat. I'm just starting out with NR in C++ and trying to implement it in VS.NET.

When I compile, every file gets the error:
fatal error C1010: unexpected end of file while looking for precompiled header directive

Any ideas of what you did to get past that error?

Thanks for your help.
Tony

Adrian Hill
03-09-2003, 06:05 PM
Simply add the line

#include "stdafx.h"

as the first executable (non-comment) line in the file.

The VC++ compiler expects this whenever you are using
pre-compiled headers.

Alternatively, use the Project settings to turn off pre-compiled
headers, and then the above step is unnecessary.

Let me know if you need further help,
Adrian

tonyz
03-12-2003, 10:06 AM
Thanks for the advice.

Although adding that line fixed that problem, I did run into other problems trying to call the routines from C#.

In the end, I ended up porting the routines I needed to C#, and all is well. Turns out the port is fairly simply and replicable.


Cheers,
Tony