Guess because you're using inc(count) which may tell the compiler to use a specific procedure, specific procedure that may have its own hidden variables.

Use count := count + 1; and see what happens. This way you're not using the
inc() procedure that may be specific to the system unit.

Plus, you may have GCC with optimization flags on, due to your Linux system [for example Gentoo] - whily FPC may be compiling its programs in the normal, unoptimized way. This also may be a problem. Check it.

Hi

I wrote two programs one in C and one in Freepascal.

The program read a variable of a library and write it to stdout. I will put it into a file: ("#: ./dataprog > file.dat"). I use "printf" in the C and "writeln" in Freepascal.

The problem: The fpc-based program is explicit slower than the c-based program. My questions: Why is it so? Is it possible to avoid the problem?

--------------
C source:

for (i=0;i<n;i++) {
  out1=(single) libout1[i];
  out2=(single) libout2[i];
  count+=1;
  printf("%20.0f%15.5f%15.5f\n",count,out1,out2);}

--------------
fpc source:

for i:=0 to n do
begin
  out1:=single(libout1[i]);
  out2:=single(libout2[i]);
  inc(count);
  writeln(stdout, count:20, out1:15:5, out2:15:5);
end;

--------------

interesting... which version of fpc are you using? how big does n go? you can use the time util to give us some figures.

henry

The problem: The fpc-based program is explicit slower than the c- based program. My questions: Why is it so? Is it possible to avoid the problem?

I guess it's the single to string conversion. This routine is very complex and not it both right and portable
is hard enough by itself, as far as I'm concerned.

Jonas

Op Wed, 13 Jun 2007, schreef Catalin Zamfir Alexandru:

Nonsense, inc is compiler internal and fast.

The problem is probably our real to string conversion is slower.

Daniël

Hi

thank's at all for your help!

Here some more Information:

1.) I think, that the inc(counter) procedure is faster then counter:=counter+1;.
     In the FreePascal book (Free Pascal; M. van Canneyt,F. Klämpfl; C&L; 2000; ISBN 3-932311-67-1; S. 519) you can find this information.

2.) I think, FreePascal produce fast programs. I look in fpc options an found: -O<x> optimizations:
-OG generate faster code (default)
I use this default option. I use on gcc no specific optimizations.

3.)The version is "Free Pascal Compiler version 2.0.4 [2006/08/22] for i386".

4.) n is not so high (i think on 32 or 64) but the program must work in Realtime mode.
     The library produce an periodic callback-process and I will know some informations (out1,out2) which are in two arrays (libout1,libout2);
     I know, programs with a writeln() have lower performance, but I think, printf() and writeln() must do the same. This need time to calculate.
     But the difference between printf() and writeln() are so, that the fpc program breaks with errors.
     Here the Informations about the difference:
      You can produce with gcc an output like the example source with 80% CPU efficiency.
      The fpc program with only the line "writeln(out1:0:4);" works without breaking by 100% CPU efficiency. "writeln(out1:0:5);" will break.

regards,
Markus

--------------
C source:

for (i=0;i<n;i++) {
  out1=(single) libout1[i];
  out2=(single) libout2[i];
  count+=1;
  printf("%20.0f%15.5f%15.5f\n",count,out1,out2);}

--------------
fpc source:

for i:=0 to n do
begin
  out1:=single(libout1[i]);
  out2:=single(libout2[i]);
  inc(count);
  writeln(stdout, count:20, out1:15:5, out2:15:5); (* This will break! *)
end;

--------------

What kind of errors?

Jonas

Hi Jonas,

> I know, programs with a writeln() have lower performance, but I think, printf() and writeln() must do the same. This need time to calculate. > But the difference between printf() and writeln() are so, that the fpc program breaks with errors. What kind of errors?

It will break with an error from the library, if the procedure is to slow. The fpc-writeln() works fine but to slow. The gcc-printf() works fine and fast.

Do you know a better way to produce a fast formated output in FreePascal. I would use FreePascal and not gcc, but the fpc result is not practical.

Markus

--------------
C source:

for (i=0;i<n;i++) {
  out1=(single) libout1[i];
  out2=(single) libout2[i];
  count+=1;
  printf("%20.0f%15.5f%15.5f\n",count,out1,out2);}

--------------
fpc source:

for i:=0 to n do
begin
  out1:=single(libout1[i]);
  out2:=single(libout2[i]);
  inc(count);
  writeln(stdout, count:20, out1:15:5, out2:15:5); (* This will break! *)
end;

--------------

I'm sorry, but you are not providing enough information to give any useful comments. There is no reason why a generic library would error out because certain code is "too slow". Is this a real time application on an embedded system or so?

Do you know a better way to produce a fast formated output in FreePascal. I would use FreePascal and not gcc, but the fpc result is not practical.

If your program depends on converting floating point numbers to string representation as quickly as possible, I agree that FPC is not the tool you want in this case.

Jonas

I think that the problem is the buffering. Just set the text buffer (settextbuf) to a larger buffer, and it should work a lot faster.

I don't see why not ?
What would make it more slow than a comparable routine in libc ?

Michael.

That's quite unlikely to be the case. settextbuf seldomly makes a difference for me. Especially if you write to standard output, which will trigger a flush after every writeln anyway.

I don't see why not ? What would make it more slow than a comparable routine in libc ?

Of course it is possible to write a routine which is just as fast as the one in libc, but I'm not going to spend my time on that (I spent months on debugging the current routine on different architectures to get consistent and pretty correct output, and there are plenty of other more interesting and -as far as I am concerned- important things to do).

Currently, FPC's float->string conversion is apparently too slow for him however, so FPC is not useful for him at this time if his main interest is "speed of converting floating point numbers to string representation".

Jonas

Jonas Maebe wrote

That's quite unlikely to be the case. settextbuf seldomly makes a difference for me. Especially if you write to standard output, which will trigger a flush after every writeln anyway.

(unless you redirect the output to a file, at least under *nix)

Jonas

Yes, but is there evidence that this is indeed the cause ? Because there are 2 mixed problems: writeln, and the conversion.

You would have to test the speed of each of them separately to be able to say anything definitive. Like it is now, there is no indication that it is the float-to-text routine which is to blame.

Michael.

Michael Van Canneyt wrote

You would have to test the speed of each of them separately to be able to say anything definitive. Like it is now, there is no indication that it is the float-to-text routine which is to blame.

So use sprintf in C, and the equivalent in fpc; and rerun the test.

Micha

Adrian Wrote:> no - that was not the problem. I have my linux running in a coLinux

Haven't closely read your problem, but here is what I found:http://www.freepascal.org/mantis/view.php?id=6822http://www.freepascal.org/mantis/view.php?id= 7838There are issues with initialization/finalization in certain situations (will probably be fixed soon, if I was smart enough I'd have fixed it).Regards,Lars

Haven't closely read your problem, but here is what I found:

http://www.freepascal.org/mantis/view.php?id=6822
http://www.freepascal.org/mantis/view.php?id=7838

There are issues with initialization/finalization in certain situations (will probably be fixed soon, if I was smart enough I'd have fixed it).

Regards,
Lars

I know, programs with a writeln() have lower performance, but I think, printf() and writeln() must do the same. This need time to calculate.

You have to explain problem more.

The key thing to do is find your bottleneck. Write some benchmarks for float to string conversions and put them in a loop. It could be concatenation or other things.

If you are interested you can also consider writing your own WriteLn to avoid some indirection and abstraction. There is an example of writing your own text writeln driver here:

http://opensvn.csie.org/pspcgi/psp-1.6.0.2-release/extras/webcrt/

(kind of like an overloaded WriteLn, it is for web programming, you would need to write it for speed whereas above is written for CGI).

See also:
http://opensvn.csie.org/pspcgi/psp-1.6.0.2-release/main/native_out.pas

That native_out unit writes to standard out without going through WriteLn system functions - Anothony wrote his own stdout functions from scratch calling the winapi and the linux api's.

But don't try that until you first know what the bottleneck is, obviously. For web programming it was just some fun premature optimization, but may be helpful for you if you have to write your own writeln's and stdout functions.

Lars

Hi

I try your solutions and here are the results:

1.) TIP: set text buffer higher (using settextbuf) -> RESULT: procedure breaks later 2.) TIP: use flush() after writeln() -> RESULT: procedure breaks on first flush() 3.) TIP: convert first float to text and then put it out -> RESULT: the same breaks like the writeln()-included formating 4.) TIP: use sprintf form libc unit -> RESULT: not tested, because the file descriptors change(, isn't?) 5.) TIP: write your own writeln() -> RESULT: not tested, because is to difficult but very interesting

Here an information again: If I put the output with all informations and high precision to /dev/null nothing breaks.

My solution is: I write only one information and I cut the precision like writeln(stdout,out1:0:3). This works fine.

Thank's at all for your help!

regards,
Markus

--------------
C source:

for (i=0;i<n;i++) {
  out1=(single) libout1[i];
  out2=(single) libout2[i];
  count+=1;
  printf("%20.0f%15.5f%15.5f\n",count,out1,out2);}

--------------
fpc source:

for i:=0 to n do
begin
  out1:=single(libout1[i]);
  out2:=single(libout2[i]);
  inc(count);
  writeln(stdout, count:20, out1:15:5, out2:15:5); (* This will break! *)
end;

--------------

Can you please finally explain what 'breaks' means and what kind of environment you are in?

Jonas

It's hard to pull any conclusions from this without the full code. Sounds like a buffering problem, but this is far from sure.

Michael.