[fpc-pascal] FPC Graphics options?

Marco van de Voort marcov at stack.nl
Fri May 12 12:22:15 CEST 2017


In our previous episode, Graeme Geldenhuys said:
> > Ah ok, so a tight loop benchmark.
> 
> And lots of colour value loop-ups. Nothing wrong with that - how else 
> are you supposed to implement a software raycaster.

I mean it does an awful lot of calculation with very overviewable,
localizzed datastructures that are thus very optimizable.  Moreover, the
achilles heal of Java, GC, doesn't come into play large scale.

A lot of graphics code will have such heavy loops of code, but a raycaster
is extreme since it is purely calculating, and few applications, even if
graphical in nature will have this kind of code as only rate determining
code. And then I'm not even talking about auto-vectorization.

In general FPC and Delphi code is fine, unless you touch such domains, where
it all depends if you implemented all optimizations and transformations in
the book.

Functional language interpreters are afaik another such special case, where
small differences can be amplified enormously. No doubt FPC will score
relatively bad against the corporate (sponsored) behemoths there too

Lies, damned lies and benchmarks.

> It must be noted, my intention was not to implement a "benchmark". 

Yes. But you do try to make a performance point with a samplesize of 1,
which is not exactly a typical one.




More information about the fpc-pascal mailing list