John Lamb wrote:

Colin Carter wrote:

...

Does anybody know if SuSE 64 bit system is really 64 bit code? I can't seem to get any response from SuSE staff regarding the questions: 1: If I define int i; and real x; do I get 64 bit integer and float if compiled under 64?

Try it and see:

#include int main() { printf( "short has size %d\n", sizeof( short ) ); printf( "int has size %d\n", sizeof( int ) ); printf( "long has size %d\n", sizeof( long ) ); printf( "long long long has size %d\n", sizeof( long long ) ); printf( "float has size %d\n", sizeof( float ) ); printf( "double has size %d\n", sizeof( double ) ); }

A 32-bit system will give 2 for short, 4 for int, long and float and and 8 for long long and double. A 64-bit system ought to give different values. Remember that C also specifies bounds for some of these values; so short isn't going to have size 8 just because you've got 64-bit code.

...

2: Where does one find the definitions in the SuSE system? For example, where is the definition for the structure of XSizeHints ? Where is the definition of the function prototypes for the 64 bit functions?

Typically somewhere in the /usr/include hierarchy.

...

Maybe the 'average' programmer can ignore such issues, but I want to use FORTRAN to do the number crunching and I need to know if I should pass an integer(KIND=4) or integer(KIND=8)

I don't suppose there's any way I could persuade you to try using C++ or C instead of FORTRAN (I gave up FORTRAN in 1988 and haven't looked back). If you're calling C functions, then I guess you just look for the declarations in an include directory and use the program above (compile it gcc name.c and run it ./a.out) to identify the actual sizes.

FORTRAN is still as much as 75% faster than C/C++ with good compilers (SGI & Intel under various linuces, including SuSE), I have seen that without fail. If you are doing runs which take days to complete, the difference definitely counts.

John Lamb wrote:

William A. Mahaffey III wrote:

...

...

I don't suppose there's any way I could persuade you to try using C++ or C instead of FORTRAN (I gave up FORTRAN in 1988 and haven't looked back). If you're calling C functions, then I guess you just look for the declarations in an include directory and use the program above (compile it gcc name.c and run it ./a.out) to identify the actual sizes.

FORTRAN is still as much as 75% faster than C/C++ with good compilers (SGI & Intel under various linuces, including SuSE), I have seen that without fail. If you are doing runs which take days to complete, the difference definitely counts.

I guess you don't do C/C++ then. Could I interest you in java or python?

By the by, I do do some C & (frankly) like it. Almost all new stuff I write is, in fact, in C (no good w/ C++ yet ....), unless there are definite speed requirements, whence I go to FORTRAN.

Stefan Hundhammer wrote:

On Saturday 28 August 2004 05:07, William A. Mahaffey III wrote:

...

By the by, I do do some C & (frankly) like it. Almost all new stuff I write is, in fact, in C (no good w/ C++ yet ....), unless there are definite speed requirements, whence I go to FORTRAN.

Just curious: Did you do any hard benchmarking to support that supposed performance advantage of Fortran compared to C used in a similar way - i.e. not doing any fancy stuff, just number crunching?

Any pointers, anybody?

A reasonable starting point would be http://www.amath.washington.edu/~lf/software/CompCPP_F90SciOOP.html since it's mainly in the realms of Computational Maths/Physics/Chemistry that FORTRAN remains important. -- JDL

Stefan Hundhammer wrote:

OK, thanks, that's a very informative site.

But according to the charts there, there is hardly any difference in performance, right? Sometimes even C/C++ appears to be faster.

Or am I reading those charts wrong?

No, though there may be other examples where F is actually faster, depending on the usual things, how it's compiled, what number-crunching is done etc. There are still F libraries such as ATLAS that are reputedly better than the C equivalent. OTOH, since C has the asm keyword, it's always technically possible to get C code to compile as fast as F. I've found that wring the number crunching stuff in C/C++ carefully often gives assembly output that I couldn't reasonably improve, albeit the style of the C/C++ tends to resemble F a bit. In the end, there's nothing in C/C++ that says it can't compile to run at least as fast as F, esp with the right optimisations (-march=pentium4 -O3 -mfpmath=sse -msse -msse2 -malign-double works for me!), though I think that's not always the point. Otherwise I wouldn't use java and python. ;-) -- JDL

In terms of performance optimisation one of the biggest advantages Fortran has is the lack of pointers and therefore the lack off possible aliases. C/C++ compilers have to employ comlex alias optimisation analysis. Here C++ is significantly better then C. Reference types (instead of pointers), the use of 'const', and inline member functions all help the complier. This is very true in context, but C++ is significantly more difficult to optimize. Reference types, const, and inline member functions certainly have an advantage, but many commercial C compilers inline many common

On Tue, 31 Aug 2004 19:09:32 +0200 Michael Stevens wrote: library functions, such as strlen, strcpy, etc. Years ago, I used to avoid subscripts like the plague and use pointers for performance. Today, I use and teach the use of subscripts because subscripts allow better optimization than pointers. (And they improve readability). Compiler writers tend to be much smarter than other programmers as they will constantly remind you. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Tue, 31 Aug 2004 20:24:01 +0200 Michael Stevens wrote:

That was until Intel bought out KAI and then killed of their excellent

optimising C++ compiler! Intel acquired a lot of the compiler people from Compaq Computer (formerly Digital now HP). -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Thu, 02 Sep 2004 05:23:38 +0200 Philipp Thomas wrote:

Colin Carter [26 Aug 2004 10:06:23 GMT]:

...

Does anybody know if SuSE 64 bit system is really 64 bit code?

Of cause it is.

...

1: If I define int i; and real x;

What, please, is an int? C/C++ do not know the type real.

...

do I get 64 bit integer and float if compiled under 64? ints on 64 bits systems are generally 32 bits. Longs are 64 bit on a 64 bit system, and pointers are 64 bits. Just use this small programm to tell you. #include int main() { printf("Sizeof(int) = %ld\n", sizeof(int)); printf("Sizeof(long) = %ld\n", sizeof(long)); printf("Sizeof(float) = %ld\n", sizeof(float)); printf("Sizeof(double) = %ld\n", sizeof(double)); printf("Sizeof(char *) = %ld\n", sizeof(char *)); return 0; }

Note that I do not have a 64 bit SuSE system at the moment, but I had an older Linux on Alpha. Note that there is no primitive type "real" in C or C++. In general doubles are 64 bits on both 32 and 64 bit systems. Note that the sizeof operator returns a size_t that is implementation defined, and may be a long, hence you should use %ld because size_t is often a long. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9