Recent

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

Nitorami

  • Sr. Member
  • ****
  • Posts: 491
Re: Actual gaming performance of FPC?
« Reply #30 on: May 24, 2017, 10:01:02 pm »
Test results from my ~13 year old AMD Athlon 3500+, compiled and run from the FPC IDE

■ Free Pascal IDE Version 1.0.12 [2015/11/16]
■ Compiler Version 3.0.0
■ GDB Version GDB 7.4
■ Using configuration files from: D:\speed\
Running "d:\speed\project1.exe "
FILL TEST: [10000000 items]
Records:  0,248648573253774 s
Classes:  2,0375213753895 s
Pointers: 0,9052851958167 s

QUICKSORT TEST: [10000000 items]
Records:  2,58236324632539 s
Classes:  12,3440482267842 s
Pointers: 9,90768453970034 s

FREE MEM TEST: [10000000 items]
Records:  0,155206947245678 s
Classes:  5,768513388735 s
Pointers: 4,44650447871946 s

The majority of time for the Class FILL test is obviously used up by creating the Classes, not by setting the variables. Of note is further that Class variables are automatically initialised with zero on Create, which is not the case for standard records.
Anyway, I am not sure whether anyone would use such atomic Classes in real life.

Paul_

  • Full Member
  • ***
  • Posts: 143
Re: Actual gaming performance of FPC?
« Reply #31 on: May 24, 2017, 10:23:01 pm »
Thank you Nitorami, of course I will try to make them bigger with some functionality.

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
Re: Actual gaming performance of FPC?
« Reply #32 on: May 25, 2017, 09:58:27 am »
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)
An that's why I'm against early-optimization.  I mean, early-optimizations require early-assumptions (for example: plain Pascal is faster than Object Pascal) and that would be wrong. (I would be ;))

I must investigate about those "optimizations provided by Generic lists". :-X

How do you have structured this sound generator? Can you post code?
Of course I can. You can read it from my SourceForge SVN:
https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/engine/mngsound.pas

The runtime generator is the TmngPSG CLASS.  Sorry for mixing English and Spanish in both comments and naming.  I was recycling some old code.  Anyway public stuff is all in English.
« Last Edit: May 25, 2017, 10:09:58 am by Ñuño_Martínez »
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

Eugene Loza

  • Hero Member
  • *****
  • Posts: 671
    • My games in Pascal
Re: Actual gaming performance of FPC?
« Reply #33 on: May 25, 2017, 12:44:18 pm »
I must investigate about those "optimizations provided by Generic lists". :-X
It was very algorithm-specific.
With the first algorithm I was randomly scanning the array.
The next gen used temporary generic list of the tiles that were applicable which appeared many orders more efficient than just randomly trying to add the tiles.
The core is here: https://github.com/eugeneloza/decoherence/blob/master/decodungeongenerator.pas#L478
My FOSS games in FreePascal&CastleGameEngine: https://decoherence.itch.io/ (Sources: https://gitlab.com/EugeneLoza)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11446
  • FPC developer.
Re: Actual gaming performance of FPC?
« Reply #34 on: May 25, 2017, 01:24:30 pm »
The example with the loading of objects originally used sorted TStringlist as index. Between 100000 and 200000 that ground to a halt (D6, in 2003) (as in minute + loading times)

I then created a different container type, which I ported to generics (FPC 3.0/3.1 and D2009+) and simplified streaming and it became single digit seconds.

We actually had quite a laugh when a ISV came for official bill generation and after 4 hours the Java application crashed, and they had to restart and said there was not enough time left, and they would come back the next day.

Of course that was a generic application vs a tuned one, but my boss, ever the politician pointed out to them that his own programmers could do it under a minute (the actual I/O of the report generation being the bottle neck there, this was pre SSD times). We laughed, they didn't :-)

One of the reasons it was so bad was that our dataset was 10-20 times bigger than the next biggest customer they had, which were typical single muncipalities, while we were an adminstration office that little muncipalities  delegated the work to, that however in total amounted to a quarter of the households in the country.

The lesson was that ordered insertions in a one array structure is slow. The conventional solution is a hash, but I needed ordered lists (to compare dumps to another part of the system), so I created something myself
« Last Edit: May 25, 2017, 03:15:27 pm by marcov »

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Actual gaming performance of FPC?
« Reply #35 on: May 25, 2017, 02:23:06 pm »
Between 100000 and 20000 that ground to a halt (D6, in 2003) (as in minute + loading times)
The final count down?
 :'(
Note, regarding the subject, I have seen some really nice peephole optimizations by Florian the past few weeks.
At least two of these can have impact on gaming performance.
« Last Edit: May 25, 2017, 02:25:23 pm by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

 

TinyPortal © 2005-2018