Re: [fpc-other] [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/23/2017 01:35 AM, nore...@z505.com wrote:

On 2017-05-18 10:12, Graeme Geldenhuys wrote:

On 2017-05-18 16:04, Ryan Joseph wrote:

After I looked at the code I didn't see anything strange about it


Thank you, that's what I thought too.


it just got me thinking, if that code can be that slow how slow is
all the stuff I’m writing on a daily basis? It’s just worrying that’s
all.


+1
Thank goodness normal desktop applications are not that sensitive to
inefficient generated binaries.


And this is why it is usually premature optimization.. most people are 
using FPC likely for lazarus desktop apps, not game programming or 
fast graphics rendering, so no one cared about this bug/slowness until 
someone reported it..


Which is good that it was reported, to find a problem with FPC that 
was not noted before or that no one previously had any issues with.


But with that pascal game development web forum out there, it should 
have come up some time previously?  As there are game programmers out 
there using fpc, and there is andorra/zengl so what do they do? Work 
around the bug instead of fixing it at the source in the rtl/compiler? 
Swap in their own faster functions instead of replacing the rtl 
functions at the source level on fpc's svn server?
It was actually a case, not typical at all for game development. It was 
software rendering and game engines almost always use hardware 
rendering, even for 2D games. And a huge part of the performance 
difference was caused by the highly specific fact that floating point to 
integer conversion is slow on the x87 FPU and SSE3 improves this a lot. 
If it was regular floating point, without so many integer conversions, 
SSE3 wouldn't matter, and I'm guessing that SSE2 wouldn't make a lot of 
difference. Disclaimer: I have not tested this. :)


And yes, Florian, Jonas and Sven did a few small optimizations, which is 
a good thing, but they are nowhere near as impactful in general use 
cases as people think ( which is related to the fact that the FPC 
optimization performance is not as bad as this particular test was 
making it out to be :) )


Nikolay
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 10:05, Graeme Geldenhuys wrote:

On 2017-05-18 15:58, Reimar Grabowski wrote:

A real game would be done differently and then FPC is fast.


Oh, so work around the FPC problem. I get it now. ;-)



Wanne do PacMan in 160x100 resolution, no problem for FPC.


Check.



Wanne do something more modern...


Use Java instead. ;-) Check. Oh wait, that's what I did for that 
project.




What about Rust or plain C? Or Digital Mars D?

Biggest problem with C is all the manual memory management, like 
strings, for example, that IMO morons waste hours of time on and create 
buggy code, all needlessly and unnecessarily.


Or instead of using rust/c/java, simply fix FPC, which is a good 
solution IMO, as not only does it speed up some boring game test case, 
but fixes other things that people didn't know about which were slowing 
down their app.


I don't see how ZenGL and Andorra3D have been able to succeed as game 
engines with all these performance issues in the RTL/compiler? Did they 
work around them and swap in their own faster code, instead of reporting 
the bug/issue to the fpc bug reporting?


Indeed it is not exactly a bug but could just be correct code that is 
slow.

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-21 07:58, Felipe Monteiro de Carvalho wrote:

On Thu, May 18, 2017 at 5:05 PM, Graeme Geldenhuys
 wrote:
Use Java instead. ;-) Check. Oh wait, that's what I did for that 
project.


Well, Java also has its issues.

...


import java.util.*;

class FelipeTestThread
{
volatile boolean running = true;

public void test()
{
new Thread(new Runnable()
{
public void run()
   {
int counter = 0;
while (running) {
counter++;
}


Yes indeed, one issue is:

your code is
{
{
 {
   way
 {
   over here


Compare that to oberon or even Plain C where your code:

someproc {
is here
}


Not here:

{
  {

 {
 system.print()

Same issue with C#

Not an issue with: golang, fpc, delphi, oberon, C, or even in some cases 
ruby


The amount of nesting and indented procedures inside classes in Java is 
horrible, IMO.

Just to get a program started you are

   way over here
  by morning
 and worse
 by night
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other