* * *

Author Topic: Actual gaming performance of FPC?  (Read 7091 times)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5875
Re: Actual gaming performance of FPC?
« Reply #15 on: May 23, 2017, 03:26:38 pm »
In general I expect FPC to be a bit less, but not much (say 10-20% on average).  In applications where most of the heavily lifting is done by an external library (like SDL) it might even be not noticable.

But game is not just rendering. Game elements must have structure - arrays, classes, lists. In every frame is calculated lot of things (physics, states, AI), game loop must go through the lists etc. etc.
If you lose 20% in every aspect..

FPC classes are performance killer. What I test earlier.

E.g. there are 2 demos in ZenGL library:
- first is based on classes, nice clear code and really low performance.
- second is using records + array of pointers and it's really fast (but if it could compete with C ++ I dont know).

If you start comparing dynamic memory management to statically allocated then of course it is a problem.

I however use classes all the time (but in speed sensitive code don't constantly create and destroy them, and  that works fine.

But you do mention something on the side that deserves to be unambiguously stated: the more advanced C++ compilers are more likely to reduce naive C++ code into something better than FPC can, and (as the fpc-devel list show) can do very great things with tight loops with all data value types and local.

FPC misses various kinds of CSE and hoisting and hurts there. But it is all relative, and a matter of tuning the code a bit. And since the rate-determining code is usually fairly localized that is not that bad.

« Last Edit: May 24, 2017, 11:13:01 am by marcov »

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 659
    • Burdjia
Re: Actual gaming performance of FPC?
« Reply #16 on: May 24, 2017, 11:04:07 am »
I'm working in my very own old-school 2D game engine, so I'm dealing with a lot of what you're talking about here.

Right now I don't care about performance a lot, I'm more concerned about engine structure fighting against the early-optimization illnes everytime I code anything.  So I'm using a lot of classes (except one OBJECT that I actually don't know why I keep) and performance sucks. It works correctly in my not-so-modern 4core desktop but it is too slow in my older 2core notebook (for example, the runtime sound generator kills it).

I think I can boost performance a lot by using plain Pascal instead of Object Pascal, but I'll not even discuss it until version 1.0 is up and running with an actual commertial-quality game finished. That means the optimized version would be version 2.0 with radical API redesign that forces me to rewrite such first game from scratch.  Or may be rewriting a few methods is enough and version 1.1 or 1.2 with minor changes in API are enough.

What I want to say is that bad performance of my engine isn't in the language but in the way I'm using it.  Looking Castle Engine it uses a lot of CLASSes and has much better performance than mine, and this confirms it.
« Last Edit: May 24, 2017, 11:14:31 am by Ñuño_Martínez »

Eugene Loza

  • Hero Member
  • *****
  • Posts: 529
    • My "almost daily" development blog
Re: Actual gaming performance of FPC?
« Reply #17 on: May 24, 2017, 01:31:59 pm »
A month-old results. Classes vs records. Task: 3D maze generation (9x9x9)
Records: 22000 ms.
Classes: 250 ms. (thanks to many optimizations provided by Generic lists) + thread-safe (up to another 8x speed)
« Last Edit: May 24, 2017, 02:48:26 pm by Eugene Loza »
Lazarus 1.9 + FPC 3.1.1 Debian Jessie 64 bit.

My Free and Open Source games in Lazarus/FreePascal/CastleGameEngine:
https://decoherence.itch.io/
(and some ancient games in Turbo Pascal too)
Sources are here: https://github.com/eugeneloza?tab=repositories

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5875
Re: Actual gaming performance of FPC?
« Reply #18 on: May 24, 2017, 03:27:24 pm »
Naive value type code can be slow due to excessive copies. In ye old days this was the case with the stringtype; Shortstring

Thaddy

  • Hero Member
  • *****
  • Posts: 4779
Re: Actual gaming performance of FPC?
« Reply #19 on: May 24, 2017, 04:13:12 pm »
Naive value type code can be slow due to excessive copies. In ye old days this was the case with the stringtype; Shortstring
Uuhhhmmmm,Marco,
The Pascal shortstring type was by design more efficient than C type "strings". (for the average readers: early C did not know about strings as such, just an array of byte, early Pascal did..)
That's because its length is known to the compiler beforehand. And length is stored. And we have strings that can contain zero's.
And that is simply both a faster and a better design.
Unlest you forgot... O:-)
« Last Edit: May 24, 2017, 04:16:52 pm by Thaddy »
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5875
Re: Actual gaming performance of FPC?
« Reply #20 on: May 24, 2017, 04:30:22 pm »
Naive value type code can be slow due to excessive copies. In ye old days this was the case with the stringtype; Shortstring
Uuhhhmmmm,Marco,
The Pascal shortstring type was by design more efficient than C type "strings". (for the average readers: early C did not know about strings as such, just an array of byte, early Pascal did..)

This depends on the workload and how much manual optimization was applied. I know this matter really well due to my Modula2 days. (which had an even worse concept, null terminated unless it fits exactly in the static allocation).

Pascal shortstrings were much easier to write, and performance not too shabby if you didn't forget to add const to all string parameters.   The 255 limit was a bigger problem than the performance.

Quote
That's because its length is known to the compiler beforehand. And length is stored. And we have strings that can contain zero's.

But default by reference, and my point was that shortstring was not. And people not realizing made it a vfaq even.


Thaddy

  • Hero Member
  • *****
  • Posts: 4779
Re: Actual gaming performance of FPC?
« Reply #21 on: May 24, 2017, 04:33:53 pm »
Hm. I didn't know UCSD pascal had a const modifier for strings or any const modifier at all. I will investigate  :D Oh, And turbo Pascal had not.
Since we are both Pascal historians in some way, please enlighten me if I am wrong?

And I fully agree with the last sentence you wrote,.
« Last Edit: May 24, 2017, 04:38:11 pm by Thaddy »
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5875
Re: Actual gaming performance of FPC?
« Reply #22 on: May 24, 2017, 04:45:26 pm »
Hm. I didn't know UCSD pascal had a const modifier for strings or any const modifier at all. I will investigate  :D Oh, And turbo Pascal had not.

If you had

procedure x(s:string);

instead of

procedure x(const s:string)


in TP, a copy of s on the stack would be created and then passed to s in the first case. In the second case it would be passed by reference.

Thaddy

  • Hero Member
  • *****
  • Posts: 4779
Re: Actual gaming performance of FPC?
« Reply #23 on: May 24, 2017, 05:09:43 pm »
Marco, TP version plz.
TP 1.0 doesn't know it... const... (get it from the Embarcadero museum)?

If I am wrong I will send you a nice bottle of proper wine.
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

Paul_

  • New member
  • *
  • Posts: 48
Re: Actual gaming performance of FPC?
« Reply #24 on: May 24, 2017, 05:22:45 pm »
If you start comparing dynamic memory management to statically allocated then of course it is a problem.

I however use classes all the time (but in speed sensitive code don't constantly create and destroy them, and  that works fine.

I can test it more, also FPC vs basic code in C++. I'm not good programmer so there should be inaccuracies, anyway we will see.

What I want to say is that bad performance of my engine isn't in the language but in the way I'm using it.  Looking Castle Engine it uses a lot of CLASSes and has much better performance than mine, and this confirms it.

Of course, this is on the shoulders of the every programmer :) I'm not sure about Castle Engine, there isn't any stress tests like "08 - Sprite Engine", "09 - Sprite Engine (Classes)" in ZenGL. Links at the end of the post.

How do you have structured this sound generator? Can you post code?

A month-old results. Classes vs records. Task: 3D maze generation (9x9x9)
Records: 22000 ms.
Classes: 250 ms.

But you don't handle 100 000 dynamic objects + add/remove them "on the fly" or you dont sort it etc., right? Thats the difference.


https://github.com/goldsmile/zengl/blob/master/src/zgl_sengine_2d.pas
https://github.com/goldsmile/zengl/blob/master/extra/zglSpriteEngine.pas (same functionality with Classes)

Eugene Loza

  • Hero Member
  • *****
  • Posts: 529
    • My "almost daily" development blog
Re: Actual gaming performance of FPC?
« Reply #25 on: May 24, 2017, 07:44:51 pm »
But you don't handle 100 000 dynamic objects + add/remove them "on the fly" or you dont sort it etc., right? Thats the difference.
Of course I do. Both add/remove on the fly and sorting.
But I do it in an optimized way. And, of course, not 100 000, but as many as I need :)
I could do the same optimizations with dynamic arrays or face dire memory consumption in static arrays. And yes, I am almost sure the code would run faster with just 1-dimensional static arrays. But the performance is perfectly fine for me.
I even doubt usefulness of thread-safety I've spent so much time to ensure. If the map is generated in fractions of seconds, why should I care "Fastening" it by using threads?
The efficiency bottleneck for me is HDD reading. I bet something could be optimized here also, but I don't have any staff, so I prefer to do something more fun :)
Lazarus 1.9 + FPC 3.1.1 Debian Jessie 64 bit.

My Free and Open Source games in Lazarus/FreePascal/CastleGameEngine:
https://decoherence.itch.io/
(and some ancient games in Turbo Pascal too)
Sources are here: https://github.com/eugeneloza?tab=repositories

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5875
Re: Actual gaming performance of FPC?
« Reply #26 on: May 24, 2017, 07:47:34 pm »
I've an application that loads 400000 classes and sort them in various indexes on startup in under a second.  It would be 150-250ms though if I didn't handle string encodings.

Operations after loading are sub ms.

Paul_

  • New member
  • *
  • Posts: 48
Re: Actual gaming performance of FPC?
« Reply #27 on: May 24, 2017, 08:26:22 pm »
Ok guys, let's see the numbers from very simple FPC tests :)

Code: Pascal  [Select]
  1. Type
  2.   PItem     = ^TItem;
  3.   TItem = record
  4.     id         : integer;
  5.     x, y       : integer;
  6.   end;
  7.  
  8.   // Records
  9.   TManager = record
  10.     Count      : integer;
  11.     List       : array of TItem;
  12.   end;
  13.  
  14.   // Classes
  15.   TCItem = Class
  16.     id         : integer;
  17.     x, y       : integer;
  18.   end;
  19.  
  20.   TCManager = Class
  21.     Count      : integer;
  22.     List       : array of TCItem;
  23.   end;
  24.  
  25.   // Pointers to record
  26.   PPManager = ^TPManager;
  27.   TPManager = record
  28.     Count      : integer;
  29.     List       : array of PItem;
  30.   end;

FILL TEST: [1000 items]
Records:  0,0000256353031299197 s
Classes:  0,000318480942414061 s
Pointers: 0,000087160030641727 s

QUICKSORT TEST: [1000 items]
Records:  0,000342608286536339 s
Classes:  0,000292845639284142 s
Pointers: 0,000272940580383263 s

FREE MEM TEST: [1000 items]
Records:  0,0000229209769161635 s
Classes:  0,000117922394397631 s
Pointers: 0,0000799218274050438 s

------------------------------------------------------
FILL TEST: [100000 items]
Records:  0,000991690832870043 s
Classes:  0,0151803825522516 s
Pointers: 0,00582843748591348 s

QUICKSORT TEST: [100000 items]
Records:  0,010936546812315 s
Classes:  0,0120403287605367 s
Pointers: 0,00923714933962406 s

FREE MEM TEST: [100000 items]
Records:  0,000565564287109522 s
Classes:  0,00705573001968356 s
Pointers: 0,00362237615133803 s

------------------------------------------------------
FILL TEST: [10000000 items]
Records:  0,0609045929150976 s
Classes:  0,671325713148588 s
Pointers: 0,2505645791059 s

QUICKSORT TEST: [10000000 items]
Records:  1,44320108061496 s
Classes:  3,1377283567959 s
Pointers: 2,63237050861869 s

FREE MEM TEST: [10000000 items]
Records:  0,0520024844495768 s
Classes:  1,54121744059482 s
Pointers: 1,47699562507726 s

So, some differences are there :) Later I will add something what would simulate a game.
I expected a better performance in "array of records" vs "array of  pointers". Maybe there is a mistake somewhere.

Can test it please someone with older PC? (these numbers are from i7 3.40 GHz)
« Last Edit: May 24, 2017, 08:30:33 pm by PaulG »

Thaddy

  • Hero Member
  • *****
  • Posts: 4779
Re: Actual gaming performance of FPC?
« Reply #28 on: May 24, 2017, 08:39:05 pm »
Can test it please someone with older PC? (these numbers are from i7 3.40 GHz)
If you can send me a still working 8## floppy disk I can. My hardware is still working.
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

Paul_

  • New member
  • *
  • Posts: 48
Re: Actual gaming performance of FPC?
« Reply #29 on: May 24, 2017, 08:48:30 pm »
Actually, I still have some, what is the address?

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus