On 2017-05-19 06:32, Graeme Geldenhuys wrote:
Bottom line is, with the exact same code, NO work-arounds is required for GCC or Java! So why must we have work-arounds for FPC? It's a compiler or RTL issue - not being able to understand the code good enough to generate more efficient binaries.
Agree, but hopefully if it is an RTL issue you can just swap in a fastMath.pp unit or fast system.pp unit, or fast sysutils, or crt, or fastmm.... The whole advantage of a modular unit system is you can swap in replacements easily, then you verify that it really was an RTL issue and not a compiler issue. As an example, the graph unit is swapped in with ptc graph unit and look what happens? So then you decide to fix the graph unit and match it to ptc graph, or take another route and leave it as a more reliable unit but not as fast
And no, I don’t agree that this is a “special case”. It’s a g*d d*mn game engine I tried to implement. If the FPC team wants to keep thinking like that, then they should list in big bold letters (on the Free Pascal homepage) what type of applications they deem fit for FPC, and what type of applications you shouldn’t bother writing with FPC.
I think it was good for you to do the demo/test to find an issue in fpc that needs to be optimized. If you hadn't done this no one would have found this bug/slow code until a later time.
Same with the doom/quake ports. In mode delphi, the equivalent code did not run the same as Delphi 5/7, meaning that mode delphi had a bug that needed to be fixed... Without the quake/doom ports available to compile and try, those bugs/issues would have never been found. So not all wasted, IMO.
There were workarounds required to get the doom/quake code to work properly, which meant mode delphi must have had a bug, or fpc must have had an issue that made the graphics not render correctly and the menus to not function properly. The fixes were fairly small afair.
As I mentioned, I'll profile the application under both FreeBSD and Windows over the weekend and post my finds. But as far as I'm concerned, there is nothing wrong with the way the program has been implemented. Time permitting, I might even try compiling it with Delphi 7 to see what happens.
That's a good comparison _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
