RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp

[Per W. <pw...@ia...>]

Please. Life is too short to religious wars about which language is the
best. I have never ever said that a C or C++ program is slower than a
Fortran program. Only that because of changes in the memory layout of the
different languages, a direct translation of a Fortran program will be 
slower in C, just as a direct translation of a C program will be slower in
Fortran.

The following link is quite good at discussing differences between array
definitions for a couple of languages:
http://www.compaq.com/fortran/docs/vf-html/pg/pgwarray.htm

It isn't possible to just swap index order of a multi-dimensional array,
since large lin-pack code often perform evaluation of subsets of the
array.

The attached source code displays exactly this behaviour. It contains two
test cases, using same algorithm but different memory layout.
- Array access in correct and incorrect order.
- Access speed for optimal and non-uptimal struct.

The speed difference between the two alternatives applies for just about
all programming languages, and just about all all computer architectures
and compilers. The only thing that differs is the amount of speed
difference between good and bad access patterns.

Small memory (< 80MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  31.3 seconds (50.1 ns/iteration)
  Processing array in order      16.5 seconds (26.5 ns/iteration)
  Improvement factor             1.89
  Non-optimum struct access      24.4 seconds (488 ns/iteration)
  Optimum struct access          12.5 seconds (250 ns/iteration)
  Improvement factor             1.95
  Total user time                46.3 seconds
  Total system time              0.5 seconds

Small memory (< 80MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order 46.3 seconds (74.1 ns/iteration)
  Processing array in order     7.76 seconds (12.4 ns/iteration)
  Improvement factor            5.97
  Non-optimum struct access     11.2 seconds (224 ns/iteration)
  Optimum struct access         10.2 seconds (204 ns/iteration)
  Improvement factor            1.1
  Total user time               68.9 seconds
  Total system time             0.371 seconds

Large memory (< 800MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  2.83e+03 seconds (28.3e+03 ns/iteration)
  Processing array in order      175 seconds (1.75e+03 ns/iteration)
  Improvement factor             16.2
  Non-optimum struct access      354 seconds (35.4e+03 ns/iteration)
  Optimum struct access          225 seconds (22.5e+03 ns/iteration)
  Improvement factor             1.57
  Total user time                23.7 seconds
  Total system time              646 seconds

Large memory (< 800MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order  1.13e+003 seconds (11.3e+03 ns/iteration)
  Processing array in order      455 seconds (4.55e+03 ns/iteration)
  Improvement factor             2.49
  Non-optimum struct access      120 seconds (12e+03 ns/iteration)
  Optimum struct access          106 seconds (10.6e+03 ns/iteration)
  Improvement factor             1.14
  Total user time                46.1 seconds
  Total system time              29.8 seconds

Linux machine: gcc 2.95.4, -O2
WinXP machine, gcc 2.95.3-6, -O2
The small case was run without memory swapping.
The large case was run with memory swapping.

/Per W

On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Thursday, October 31, 2002 11:02 AM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > No, the concept is just about the same for any machine. It is just the
> > width of the memory interface, the cache line sizes, the 
> > number of cache
> > lines etc that are different. A Fortran (or C, Pascal etc) program
> > optimized for locality of reference of data accesses will 
> > will gain speed
> > on just about any computer architecture. It doesn't matter if we talk
> > about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
> > properties of memory still applies, i.e. cache is faster than primary
> > memory, primary memory is faster than disk.
> > The original Fortran algorithms might have been written for a 
> > Vax machine,
> > but the same optimizations still improves the speed on a Xeon 
> > processor.
> 
> Yes i agree. However those same types of optimisations can be performed
> in C code even if it accesses the array backwards (like Fortran does as
> you say).
> 
> 
> 
> > You disagree, while still agreeing :-) I am talking about algorithmig
> > optimization, not language optimization, and I am talking about the
> > problem of just translating an algorithm from one language to another
> > while still keeping the speed.
> 
> Algorthmically speaking, general algorithms (natively & beautifully
> supported by C++ templates) are the same for all types and languages
> (for example bubble sort etc). And the cost in Big-Oh notation is the
> same. And every compiler can perform optimisations.
> 
> 
> 
> > Take a C++ template solution 
> > with sort. I
> > can't easily convert that code to another language.
> 
> Regarding templates yes, you have to create type specialisations.
> However for a specific type why not?
> 
> 
> 
> > However, 
> > I can still
> > get the same speed in a Pascal program by doing a full 
> > rewrite, doing a
> > hand-coded qsort with inline comparison. The same goes the 
> > other way. I
> > can't take an optimized  Fortran program and convert statement for
> > statement to a C++ program and match the speed.
> 
> 
> Why? C++ has also close to the metal facilities for hand-coding that
> Fortran lacks.

When moving Fortran algorithm to C, you must rewrite all data structures
and array references, since the Fortran algorithm is written specifically
for the Fortran memory model. Yes it can be done, but if it took several
man years to write the Fortran code, don't expect less than several man
months to do it in C/C++.

> 
> 
>  
> > Since we are talking about algorithmic efficiency, and locality of
> > reference of data accesses, it shouldn't matter so much about which
> > computer architecture. The location of the break points in 
> > your referenced
> > document moves a bit to the left or right because of cache 
> > sizes, but htey
> > wouldn't even be there if locality of reference wasn't an issue, since
> > these break points isn't about code generation, but about data access
> > patterns of the algorithm.
> 
> 
> I don't understand clearly. For example,  I assume that GCC's fortran
> however-are-called integer types and GCC's C++ equivallents are the same
> implementation.
An integer for an integer or a double for a double isn't a problem.
Keeping the integers or doubles placed in the correct memory order for a
translated program is hard.
> 
> 
> Are you talking for Fortran strings (if they exist!) etc vs C++ high
> level constructs? Like C++'s complex STL type? Yes these things are not
> easy to be used from inside another language, i am talking only about
> built in types.

Strings normally never consume any time in a real program. 0.1 seconds or
0.2 seconds to open a dialog hardly matters. Fortran programs are normally
performing brutal math, where the run times may be everything from minutes
up to months or more. A factor 2 speed loss for a program requiring 1
month would result in wasted month... To solve such a problem with
another language, you can't just translate the program, since a
translation will not use the optimal features and memory layouts of the
new language.

> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>