Now i write program, that program made extensive calculations. And i want write fast code. Question about executing speed: first code-

function Calculate1: Extended;
   function SubCalculate: Extended;
   begin
     ...
   end;
begin
   ...
   ..:=SubCalculate;
   ...
end;
  second code-
function SubCalculate: Extended;
begin
   ...
end;
function Calculate2: Extended;
begin
   ...
   ..:=SubCalculate;
   ...
end;

I think first code is faster than second, because in first code SubCalculate function is in calling function body?

P.S. Where i can read tips about writing fast FP code?

Valdas Jankūnas wrote

P.S. Where i can read tips about writing fast FP code?

Here's one: profile your code!

Cheers,
-Krishna

Zitat von Krishna :

And where can you read how to do that?

Mattias

The section on gprof in the FPC User's Guide? And ofcourse the gprof manual itself.

Cheers,
-Krishna

Zitat von Krishna :

Yes, that's ok for some platforms.
But gprof/fpc does not work under linux anymore.

Mattias

Mattias Gärtner rašė:

my OS is linux...

>>> Here's one: profile your code! >> And where can you read how to do that?

VALGRIND

L rašė:

I processed my app trough "valgrind -v --tool=callgrind ./my_app", opened generated report with Kcachegrid and viewed how many times called some procedures and etc.
Sorry for stupid question: i have no idea how i can check with Valgrind how one coding style is faster than another (see root post)?

One comes in mind- call testing function many times and measure with GetTickCount how long takes this process...

KCachegrind should report the cumulative and median times for your functions. At least it does for me.

IIRC, does not matter. Only the scope of the function is different. If you are that concerned over the call-overhead of your function, you can inline it. E.g
<Code>
function SubCalculate: Extended; inline;
begin
end;
</Code>

P.S. Where i can read tips about writing fast FP code?

FP is no Java. You get what you write. If you don't use virtual functions in OO-code, there are no hidden performance killers.
First identify the bottleneck in your program (SubCalculate) with valgrind (Which you did). Now you can check this code by looking at the assembler output of the fp compiler. "fpc -alrnt ..." You can use this a base for more handoptimizing assembler code.
As a side note. I see you are using extended. Newer x86 CPUs support the SSE1/2/3/4 extensions which can process multiple doubles at mind-boggling speed. If you can, you should consider switching to double and then write SEE code if you are using a x86 CPU.

You *can* write Code with FP that rivals C.

bartek

Op Tue, 30 Oct 2007, schreef L:

C/Fortran yes, Ada no; there exists no Intel Ada compiler. It is also false that FPC is slow because it has been designed for GUI programming, as that is plain false: FPC has been designed to exploit the performance of 32-bit processors: high performance, no memory limitations.

The compiler supports some features necessary for RAD (like rtti), and that is about everything you will find in FPC's design that is about GUI programming. Still, FPC is damned fine for GUI programming.

FPC has not been designed to exploit the performance of SIMD instruction sets, and this is exactly where commercial C and Fortran compilers get their performance.

Daniël

I think first code is faster than second, because in first code SubCalculate function is in calling function body?

Actually some times local scope functions are slower because the variables need to be carried around since you are doing somewhat of a lexical closure. The local scope function can have hidden variables being passed in since it needs to know about the parent function variables. So don't assume local scope is faster always. Assume it is slower, but do testing to verify. It could even be faster in some cases.. for example if you really do need to access all the variables in one place.

P.S. Where i can read tips about writing fast FP code?

I hear the Intel C compilers and Fortran compilers and Ada compilers are better optimized for certain things since FPC/delphi are generally desinged for GUI programming. ;-)

I've never had speed problems when I closely check my SetLength cals, Length() calls on pchars. Too many class instantiations in a loop can slow down a bit, or too many except calls in a loop.

Basically, optimizing Loops is the key always when it comes to performance.

> P.S. Where i can read tips about writing fast FP code?

Also see some of the fastcode projects:

http://www.fastcode.dk/fastcodeproject/fastcodeproject/index.htm

And I'm sure you know you can always use GOTO statements when you really need speed out of loops

:)

(not always, only if absolutely neccessary).

There, one should be careful. The best is to avoid to write embedded assembler routines. With FPC, the register convention is not the same with embedded routines than with ordinary ones (at least for x86 processors, for the others I don't know).

mm
http://www.ellipsa.net/

I hear the Intel C compilers and Fortran compilers and Ada compilers are

better

Nitpick, Nitpick, Nitpick.. :-)

I grouped 'Intel C Compiler' together in one section.

1. Intel C Compiler
2. Other Fortran Compiler
3. Other Ada compiler

Not:

1. Intel C Compiler
2. Intel Fortran Compiler
3. Intel Ada compiler

The compiler supports some features necessary for RAD (like rtti), and that is about everything you will find in FPC's design that is about GUI programming. Still, FPC is damned fine for GUI programming.

It is.. and it is damned fine for server utilities that I use every day, and it is damned fine for batch programs and console programs and all sorts of wonderful things.

As a matter of fact, just because you can write procedures called "Exit", "Continue" and "Break", i.e., just because these three instructions are not keywords, using "goto" is more reliable.

(not always, only if absolutely neccessary).

If the code is more efficient with a "goto", this is sufficient to justify its use.

mm
http://www.ellipsa.net/

If the code is more efficient with a "goto", this is sufficient to justify its use.

Or if the code is clearer, for example to avoid deep nesting...

Or to make clean errors and debugging log files easier:

exit; .// default

//else
error1:
begin
  debugln('error1');
  exit;
end;
error2
begin
  debugln('error2');
  exit;
end;
error3
begin
  {$IFDEF DEBUG}debugln('error3');{$ENDIF}
  exit;
end;

This way that line noise stays out of the main algorithm code.

And I'm sure you know you can always use GOTO statements when you really need speed out of loops

Actually, in current FPC versions that will more often than not cause slowdowns, because the compiler cannot optimize as well when goto's are used.

Jonas

False. There's no speed penalty for writing in Ada vs C. They use the same Gnu compiler back-end, and thus the same assembler-level optimizations. Identical algorithms implemented in the two languages often produce indistinguishable performance.
There are cases where an Ada compiler can get better performance than a C compiler, because the Ada compiler has more information to work with.

Op Wed, 31 Oct 2007, schreef Jilani Khaldi:

That is right, but the discussion is about using a certain language because there exists a very optimizing compiler for that language.

As there is no Intel compiler for Ada, and the Intel compilers provide superior performance than GCC, it is not logical to switch from Pascal to Ada if Pascal isn't fast enough for you.

Further, it is unknown how well the GCC backend optimizes Ada language constructs as it is primarily designed for the C language. This problem is at least present in the GNU Fortran compiler; while GCC gives very reasonable performance for C code, the code from the Fortran compiler is awfull.

Daniël

Daniël Mantione wrote

Further, it is unknown how well the GCC backend optimizes Ada language constructs as it is primarily designed for the C language.

Well enough. In other words, optimization is about the same - given fairly equivalent code.

The main difference is that the Ada compiler gets its knowledge from the variable declarations, while the C compiler gets it from the code.

Vinzent.

Please use the fpc-other list for things like that.

Jonas

Further, it is unknown how well the GCC backend optimizes Ada language constructs as it is primarily designed for the C language.

I assumed that people used not just GNU Ada compilers.. for serious work. But I'm not sure.

For example, what do Airplanes use? GNU?
I'd laugh if Richard Stallman controlled the Boeing and rocket ships ;-)

Sorry for flamebait.
But seriously I'm curious if there are Ada compilers out there other than GNU which people use.

L505

For example, what do Airplanes use? GNU?

Ada compilers must be certified, so if you are developing software for avionics *you have* to write your software with a compiler certified for avionics development.
JK