Hi, On Fri, 19 May 2017, 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. It's not about that. There's no black magic, or not because FPC people are stupid. It's well known that modern compilers do two tricks: common subexpression elimination (CSE), for example to move as many parts of the code inside of a loop to outside a loop as possible of the actual loop, even down to things like simplifying addressing modes and so on, and SSA - static single assignment, which allows CSE to act more efficently. Basically some compilers will rewrite your code to fix it and make it more efficient. Not on the assembler level, but on the high level. What FPC compiles mimics the high level code much closer. (FPC has both of the above, but in a quite limited form.) Sadly, these are not easy to implement with the current architecture of FPC, which is not going away anytime soon. There are works going in that way though. Also, the difference is usually nowhere as dramatic if you don't measure tight loops, because other code is heavily penalized by cache misses for example, and also function calls are just slow, doesn't matter the compiler. Yes, a software rendering loop is a tight loop. > 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. Fortunately, there are still people who know what the hell they do, so they can still write fast multimedia and graphics code with FPC. Look around in the demoscene for examples. Charlie Ps: can someone direct me to the right code you are discussing? I looked around in the lazarus forum, but found several examples of the code, one i fixed up for SDL2, and then it ran on my MacBook with minor tweaks at 22-24 fps... Which is not great, but not that terrible. But I'm not sure if this is the actual code I should be looking at. And I even know how to make it 2x as fast, but that's an algorithmic change... _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
