Recent

Author Topic: How optimized is the FPC compiler  (Read 23492 times)

Shpend

  • Full Member
  • ***
  • Posts: 150
How optimized is the FPC compiler
« on: December 19, 2020, 03:54:26 pm »
Actually Title.

But in addition, I m curious how much ov, high-perf (internal)Vectorization, MxM mulitplications, MMX and so on is implemented by the fpc, so that apps developed by the fpc are actually considered (really) fast or medium fast or whatever :D

And in what regard is it for instance slower than Delphi 10.4 compiler or even current C++ 21 Clang compiler what could be done better(im far away from compiler knowledge actually let alone compiler optimizations xD but I would really love to see how is the current state of the FPC, what could be done better and are ppl interessted in  doing so)

** note ** this is not a bashing against fpc regardless what the outcome of the optimization is, sinc eim fullyy aware that its not a 1000 man company behind fpc   ;)


Would love to know about these.
« Last Edit: December 19, 2020, 03:57:04 pm by Shpend »

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #1 on: December 19, 2020, 04:16:25 pm »
I use Pascal at work. FPC and Lazarus.
And it runs fast on really old hardware and PC with like 2gb of ram.

Usually the bottleneck when using databases like sqlite is the hard disk. Is better to run on  SSD drives.

Is faster than Javascript that I also use at work, and it uses less memory for same object structures. Say tables with 1000 or more complex elements.

Usually it gets slow with bad written code, not for the compiler itself. So it depends more on what you write at the end.

Like for example using fpjson is slower than using third party jsontools. And jsontools is slower than using sqlite json extension.

Shpend

  • Full Member
  • ***
  • Posts: 150
Re: How optimized is the FPC compiler
« Reply #2 on: December 19, 2020, 04:22:54 pm »
Yea thats nice to hear, its mostly that , why I asked, to know how it would actually compete in terms of opts with C++ Clang compiler how big is the optimization difference there.

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #3 on: December 19, 2020, 04:29:40 pm »
I can't say since the tools I mentioned and also kotlin is what I use at work.
Never used c++ to do a gui or console application. But AFAIK is harder no visual designer or not a cross platform library except for QT that's not free.

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #4 on: December 19, 2020, 04:30:52 pm »
Time say it in other words I see no other option than using FPC for linux mac windows and desktop gui that can run on old hardware. Tell me if you know one.

Shpend

  • Full Member
  • ***
  • Posts: 150
Re: How optimized is the FPC compiler
« Reply #5 on: December 19, 2020, 04:41:50 pm »
No i dont know haha, im just trying to open up a discussion about this topic not to do really any suggestions to replace it lol

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #6 on: December 19, 2020, 04:45:29 pm »
No problem. Because I faced the same question before. But at the end you can see that if FPC is a bit slower than C++ that doesn't mean it's bad.

It depends for what you will use it. If it's for cross platform desktop GUI and also Free, there is no other best option.

But if you do command line go and use C++ for sure if you know how to use it you can produce a more optimized tool.

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #7 on: December 19, 2020, 04:52:49 pm »
To be fair, if you feel that your target is GUI here a list of GUI tools to compare
https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries

And if you want to compare speed in console applications, feel free too =)

But please provide some compilable code in a real use case, else we're talking about air.

Like real world applications done in C++ and Pascal at the same time...

No i dont know haha, im just trying to open up a discussion about this topic not to do really any suggestions to replace it lol

Sorry if I was a bit offtopic, but I think the only way to compare compilers it's by it's output program, for that I said that we need to compare compilable code.

I'm out since I already said what I wanted to contribute.

In my opinion is good to optimize FPC, but I have no idea on how to do that so I can't contribute anymore. Also I don't have any idea on C++, so I can't compare FPC and that language anyways.

Keep it running =)
« Last Edit: December 19, 2020, 06:06:14 pm by lainz »

lainz

  • Hero Member
  • *****
  • Posts: 3874
Re: How optimized is the FPC compiler
« Reply #8 on: December 19, 2020, 06:15:32 pm »
I mean you wanted to compare the speed of the final application, and not the speed of the compiler compiling that application. For that we need to compare source code and final binaries, like measuring.

Say we can compare equivalent pieces of source code and see how they are finally assembled, if they run fast or slow.

I think that can continue the discussion from that, and forget what I said, that's merely stuff for another discussion.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7517
  • Debugger - SynEdit - and more
    • wiki
Re: How optimized is the FPC compiler
« Reply #9 on: December 19, 2020, 06:25:19 pm »
There have been quite a few discussions on this topic here (and some got a bit out of hand).

I am not familiar enough with the compiler internals to answer this question in great detail (i.e. pick and compare individual optimization and indicate which compiler does or does not do them.)

I am also unclear, if you want to explicitly (and only) know about
Quote
  (internal)Vectorization, MxM mulitplications, MMX
or other opts too (like register alloc, eval during compile / replace by constant, dead code detection, ....)


There is some work being done on optimizations. But I do not know if it touches the features you mentioned. The people involved in that are generally found on the fpc mail list.

Thaddy

  • Hero Member
  • *****
  • Posts: 10991
Re: How optimized is the FPC compiler
« Reply #10 on: December 19, 2020, 06:40:34 pm »
The llvm back-end -  which fpc supports - is a better way to compare and it does not disappoint.
But note the default compiler CAN be much faster in specific cases and using the optimizations supported.
IOW, it is not the language itself.
The average programmer productivity is 4-5 hours per day. Peak performance 72 hours for short bursts. MTBF is 1 second or less.

Shpend

  • Full Member
  • ***
  • Posts: 150
Re: How optimized is the FPC compiler
« Reply #11 on: December 20, 2020, 03:36:24 pm »
Sry for my late answer.. wanted to clearly think about this b4  i hurry to write smth about that topic.

So the thing is there is this Website which measures Performance of a viarity sets of different algorithms (heavy ones actually too, not trivial!) and often sadly (but obviously understandable considering that C/C++ has big companies behind it..) is signigficantly slower in execution and hence internal optimizations which maybe maybe can be doner abit better in the near future to make the FPC a really really neat compiler to consider even more :)

But suprisingly, the first 3 Algorithms seems to be really close to each other.


Here the link!
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html

Shpend

  • Full Member
  • ***
  • Posts: 150
Re: How optimized is the FPC compiler
« Reply #12 on: December 20, 2020, 03:51:13 pm »
But the really worriable part for me is actually, that there is only litterally 1 FPC programm regarding this algorithm here:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/revcomp.html

where as in average,  for every language/Compiler there were massive improvementys made for the performance side of it, like take C++ in that list, the algorithm was reworked like 3-4 times by ppl and everytime got a good piece of boost to it, or Java, 6 times reworked, and so on, and fpc only 1 (the 1.time released algorithm) and I think stronglyy this can be reworked too and maybe get some boost , im really sure!

Shpend

  • Full Member
  • ***
  • Posts: 150
Re: How optimized is the FPC compiler
« Reply #13 on: December 20, 2020, 03:52:03 pm »
this is the algorithm in code:

Code: Pascal  [Select][+][-]
  1. {  The Computer Language Benchmarks Game
  2.    https://salsa.debian.org/benchmarksgame-team/benchmarksgame/
  3.  
  4.    contributed by Marco van de Voort
  5. }
  6.  
  7. program reverse_complement;
  8.  
  9. var lookupComplement : array[#0..#255] of char;
  10.  
  11. Const FASTAXLAT : array[0..11] of array[0..1] of char = (
  12.                   ( 'A', 'T' ), ( 'C', 'G' ),
  13.                   ( 'B', 'V' ), ( 'D', 'H' ),
  14.                   ( 'K', 'M' ), ( 'R', 'Y' ),
  15.                   ( 'a', 't' ), ( 'c', 'g' ),
  16.                   ( 'b', 'v' ), ( 'd', 'h' ),
  17.                   ( 'k', 'm' ), ( 'r', 'y' ));
  18.  
  19.       BufferIncrement = 1024;
  20.  
  21. procedure flushbuffer(buffer:pchar;inbuf:longint);
  22. var p,p2 : pchar;
  23.     c  : char;
  24. begin
  25.   if inbuf>0 then
  26.    begin
  27.      p:=buffer;
  28.      p2:=@buffer[inbuf-1];
  29.      while p<p2 do
  30.       begin
  31.        c:=lookupcomplement[p^];
  32.        p^:=lookupcomplement[p2^];
  33.        p2^:=c;
  34.        inc(p);
  35.        dec(p2);
  36.      end;
  37.     if p2=p then
  38.       p^:=lookupcomplement[p^];
  39.  
  40.     p:=buffer;
  41.     p[inbuf]:=#0;
  42.  
  43.    while (inbuf > 60) do
  44.      begin
  45.         c := p[60];
  46.         p[60]:=#0;
  47.         writeln(p);
  48.         p[60]:=c;
  49.         inc(p,60);
  50.         dec(inbuf,60);
  51.      end;
  52.      p[inbuf]:=#0;
  53.      writeln(p);
  54.   end;
  55. end;
  56.  
  57. const initialincrement=1024;
  58.  
  59. procedure run;
  60.  
  61. var s  : string;
  62.     c  : char;
  63.     buffersize,
  64.     bufferptr,
  65.     len         : longint;
  66.     p  :pchar;
  67.     line : integer;
  68.     bufin,bufout : array[0..8191] of char;
  69.  
  70. begin
  71.   settextbuf(input,bufin);
  72.   settextbuf(output,bufout);
  73.   for c:=#0  to #255  do
  74.     lookupcomplement[c]:=c;
  75.   for len:=0 to high(FASTAXLAT) do
  76.     begin
  77.       lookupcomplement[FASTAXLAT[len][0]]:=upcase(FASTAXLAT[len][1]);
  78.       lookupcomplement[FASTAXLAT[len][1]]:=upcase(FASTAXLAT[len][0]);
  79.     end;
  80.   buffersize:=initialincrement;
  81.   bufferptr :=0;
  82.   getmem(p,buffersize);
  83.   line:=0;
  84.   while not eof do
  85.     begin
  86.       readln(s);
  87.       inc(line);
  88.       len:=length(s);
  89.       if (len>0) and (s[1]='>') then
  90.           begin
  91.             flushbuffer(p,bufferptr);
  92.             writeln(s);
  93.             bufferptr:=0;
  94.           end
  95.        else
  96.          begin
  97.            if (bufferptr+len+1)>buffersize then
  98.              begin
  99.                 inc(buffersize,buffersize);
  100. //              inc(buffersize,initialincrement);
  101.                 reallocmem(p,buffersize);
  102.              end;
  103.            move (s[1],p[bufferptr],len);
  104.            inc(bufferptr,len);
  105.          end;
  106.     end;
  107.     flushbuffer(p,bufferptr);
  108. end;
  109.  
  110. begin
  111.   run;
  112.  
  113.  
  114.  
« Last Edit: December 20, 2020, 03:53:38 pm by Shpend »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7517
  • Debugger - SynEdit - and more
    • wiki
Re: How optimized is the FPC compiler
« Reply #14 on: December 20, 2020, 05:03:51 pm »
like take C++ in that list, the algorithm was reworked like 3-4 times by ppl and everytime got a good piece of boost to it

Let me see if I understand that correctly:  The C (and also Java and others) source code was tweaked over and over until eventually the compiler got a better result?
If that is true, then this is in not a comparison of compilers.

It simple means that there are more people willing to spent time on tweaking code. (And tweaking code can be based on pure luck too, since sometimes the most unexpected change may give you a better result)


The problem for comparing compilers (cross language) is that
- You need code, written to the same standard and quality. ZERO tweaks for any language.
   However that leaves you at odds, if one language does not have a feature that is useful for the test. (Punish all languages that have the feature? I think not)
- You need code that the compiler does not have special tweaks for.
   (That is a basic "binary search" could be recognized by a compiler, and the compiler could contain hand written optimized translations for it / like the diesel emission scandal)



There have been a few "competitions" on the forum for code tweaking.... (Sorry no links)
« Last Edit: December 20, 2020, 05:06:18 pm by Martin_fr »

 

TinyPortal © 2005-2018