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

> -----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.


 
> 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.


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.


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys