Re: [fpc-pascal] FPC Graphics options?

[Martin Schreiber]

On Saturday 27 May 2017 03:37:59 Ryan Joseph wrote:
>
> Is MSElang another Pascal compiler? I’ve never heard of it. I know LLVM is
> being used by Apple for Objective-C/Swift (I think) but for Pascal?
>
https://gitlab.com/mseide-msegui/mselang/wikis/home

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 24, 2017, at 11:47 PM, Martin Schreiber  wrote:
> 
> MSElang, LLVM 3.8.0
> No options -> 4.2 FPS
> -O3 -> 5.9 FPS
> -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS
> 
> With trunci32() operations
> https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest_trunc.pas
> -O3 -> 8.1
> -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 41.5 FPS

Is MSElang another Pascal compiler? I’ve never heard of it. I know LLVM is 
being used by Apple for Objective-C/Swift (I think) but for Pascal?

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[code dz]

seems fpc faster than llvm on -O3/4 only . this is a good news :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Martin Schreiber]

On Saturday 20 May 2017 21:34:34 Jonas Maebe wrote:
>
> Also in summary, very little was learned from this. We have known for a
> long time that FPC needs SSA for better code generation for loops (and
> Florian has been working on it for a long time too).
>
Here for comparison the results of FPC / MSElang - LLVM 3.8.0:

Linux 32 bit
Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz

With round() operations
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest.pas

FPC 3.0.2
-O- -> 8 FPS
-O4 -CfSSE3 -CpCOREI -> access violation
-O3 -CfSSE3 -CpCOREI -> access violation
-O2 -CfSSE3 -CpCOREI -> access violation
-O1 -CpCOREI -CfSSE3 -> 12.5 FPS
-O4 -CpCOREI -> 8.2 FPS

MSElang, LLVM 3.8.0
No options -> 4.2 FPS
-O3 -> 5.9 FPS
-O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS

With trunci32() operations
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest_trunc.pas
-O3 -> 8.1
-O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 41.5 FPS

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/24/2017 06:14 PM, James Richters wrote:

I was finally able to get this working, and now my keyboard issues are solved, 
so thank for the help and fix Nikolay!  I can't believe the performance 
increase using ptcgraph instead of graph, I am now even able to run my program 
on a tiny windows 10 tablet with no performance issues.  Also ptccrt solves 
some of the bugs with wincrt, mainiy that wincrt doesn't respond to any alt 
keys at all and not all of the crtl keys
It's great that it's finally working for you. And yes, ptccrt supports 
most alt and ctrl key combinations, but if you find some key combination 
missing, please report it - it is easy to add.


What I finally realized was there was another set of PTC units with the default 
installation of Freepascal 3.0.2 that I needed to remove so the correct 
versions of the files could be found.

Perhaps it would be a good idea to make note of this in the instructions?

I ended up needing to remove:
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.0
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.0
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.0

And the entire folder  H:\FPC\3.0.2\units\i386-win32\ptc

Also I could not compile with a space in my FPC install directory, so a quick 
comment about that may be useful to someone.
Yes, the ptcpas compilation instructions in INSTALL.txt are from the 
time when ptcpas wasn't included in the fpc distribution, and haven't 
been updated since then. This usually isn't a problem, since most people 
use the version that comes with fpc. Only when I add a new feature, or 
bug fix is there a need to update it. Eventually, I'm going to commit 
these changes in fpc trunk and they will be included in the next version 
of fpc as well, so most people will get these updates this way.



James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, May 23, 2017 5:40 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?


Just like you now use -FuSomePath to tell the compiler where to find units, you 
can use -FiSomePath to tell the compiler where to look for include files.

I've been trying to compile with Free Pascal Text IDE, I have no experience 
with compiling programs from the command line,  but this gave me an idea to try 
it from command line instead.

First, I thought I would start clean, and  I re-installed Free Pascal and left 
the directory structure alone, and just changed the drive to H: where I have a 
lot of room. I suspect it did not like the space I had in my directory name.
 From the new install of FPC 3.0.2 on my H Drive, I was able to successfully 
follow the instructions and I finally managed to compile ptcpas-code-715-trunk.

I was also able to compile the examples and they executed correctly.  So I used 
the command line used to compile one of the examples, and put the whole path of 
ptcpas in and I was finally able to successfully compile my test program with 
the following command line:
h:/FPC/3.0.2/bin/i386-Win32/ppc386.exe 
-Fuh:/ptcpas-code-715-trunk/units/i386-win32/ -FE. 
-FUh:/ptcpas-code-715-trunk/units/i386-win32 -di386 dual-key-screen.pas When I 
compiled It this way, I am now able to ALT-Tab from the graph window and when I 
return everything is fine,  so this proves the problem has been solved, but 
integrating the solution into my compiler is the problem.

I am trying to get it to work from the Free Pascal text mode IDE but when I add 
h:\ptcpas-code-715-trunk\units\i386-win32 to the list of unit directories in 
the Free Pascal text IDE and try to compile my program, I get:

PPU Loading H:\ptcpas-code-715-trunk\units\i386-win32\ptcgraph.ppu
║ PPU Source: ptcgraph.pp not found
║ PPU Source: graphh.inc not available
║ PPU Source: graph.inc not available
║ PPU Source: fontdata.inc not available ║ PPU Source: clip.inc not available ║ 
PPU Source: palette.inc not available ║ PPU Source: modes.inc not available ║ 
PPU Source: fills.inc not available ║ PPU Source: gtext.inc not available ║ 
Recompiling ptcgraph, checksum changed for ptc ║ dual-key-screen.pas(3,6) 
Fatal: Can't find unit ptcgraph used by KeyTestWin.p ║ dual-key-screen.pas(0) 
Fatal: Compilation aborted

How do I properly use the FreePascal Text mode IDE to use the ptcpas units I 
compiled?

My entries under directories > Units are:
H:\ptcpas-code-715-trunk\units\i386-win32
h:\FPC\3.0.2\units\$fpctarget
h:\FPC\3.0.2\units\$fpctarget\*
h:\FPC\3.0.2\units\$fpctarget\rtl

All other directories tabs are blank

Thanks for the help

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Ewald
Sent: Tuesday, May 23, 2017 2:03 PM
To: FPC-Pascal users discussions <fpc-pascal@lists.fr

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I was finally able to get this working, and now my keyboard issues are solved, 
so thank for the help and fix Nikolay!  I can't believe the performance 
increase using ptcgraph instead of graph, I am now even able to run my program 
on a tiny windows 10 tablet with no performance issues.  Also ptccrt solves 
some of the bugs with wincrt, mainiy that wincrt doesn't respond to any alt 
keys at all and not all of the crtl keys

What I finally realized was there was another set of PTC units with the default 
installation of Freepascal 3.0.2 that I needed to remove so the correct 
versions of the files could be found. 

Perhaps it would be a good idea to make note of this in the instructions?  

I ended up needing to remove:
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.0 
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.0 
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.0

And the entire folder  H:\FPC\3.0.2\units\i386-win32\ptc

Also I could not compile with a space in my FPC install directory, so a quick 
comment about that may be useful to someone.


James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, May 23, 2017 5:40 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?

>Just like you now use -FuSomePath to tell the compiler where to find units, 
>you can use -FiSomePath to tell the compiler where to look for include files.

I've been trying to compile with Free Pascal Text IDE, I have no experience 
with compiling programs from the command line,  but this gave me an idea to try 
it from command line instead.

First, I thought I would start clean, and  I re-installed Free Pascal and left 
the directory structure alone, and just changed the drive to H: where I have a 
lot of room. I suspect it did not like the space I had in my directory name.
From the new install of FPC 3.0.2 on my H Drive, I was able to successfully 
follow the instructions and I finally managed to compile ptcpas-code-715-trunk.

I was also able to compile the examples and they executed correctly.  So I used 
the command line used to compile one of the examples, and put the whole path of 
ptcpas in and I was finally able to successfully compile my test program with 
the following command line:
h:/FPC/3.0.2/bin/i386-Win32/ppc386.exe 
-Fuh:/ptcpas-code-715-trunk/units/i386-win32/ -FE. 
-FUh:/ptcpas-code-715-trunk/units/i386-win32 -di386 dual-key-screen.pas When I 
compiled It this way, I am now able to ALT-Tab from the graph window and when I 
return everything is fine,  so this proves the problem has been solved, but 
integrating the solution into my compiler is the problem.

I am trying to get it to work from the Free Pascal text mode IDE but when I add 
h:\ptcpas-code-715-trunk\units\i386-win32 to the list of unit directories in 
the Free Pascal text IDE and try to compile my program, I get:

PPU Loading H:\ptcpas-code-715-trunk\units\i386-win32\ptcgraph.ppu
║ PPU Source: ptcgraph.pp not found
║ PPU Source: graphh.inc not available
║ PPU Source: graph.inc not available
║ PPU Source: fontdata.inc not available ║ PPU Source: clip.inc not available ║ 
PPU Source: palette.inc not available ║ PPU Source: modes.inc not available ║ 
PPU Source: fills.inc not available ║ PPU Source: gtext.inc not available ║ 
Recompiling ptcgraph, checksum changed for ptc ║ dual-key-screen.pas(3,6) 
Fatal: Can't find unit ptcgraph used by KeyTestWin.p ║ dual-key-screen.pas(0) 
Fatal: Compilation aborted

How do I properly use the FreePascal Text mode IDE to use the ptcpas units I 
compiled?

My entries under directories > Units are:
H:\ptcpas-code-715-trunk\units\i386-win32
h:\FPC\3.0.2\units\$fpctarget
h:\FPC\3.0.2\units\$fpctarget\*
h:\FPC\3.0.2\units\$fpctarget\rtl

All other directories tabs are blank

Thanks for the help

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Ewald
Sent: Tuesday, May 23, 2017 2:03 PM
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

On 23/05/17 19:50, James Richters wrote:
> *correction  to directory names:
> Now I got an error that it could not find graphh.inc So I copied all the .inc 
> files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc  to 
> J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no 
> idea how else to make it find them.

Just like you now use -FuSomePath to tell the compiler where to find units, you 
can use -FiSomePath to tell the compiler where to look for include files.

See `fpc -h`, under the section "-F Set file names and paths:" for a list of 
other related switches.


--
Ewald
_

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/23/2017 11:05 PM, James Richters wrote:

Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
units\i386-win32 from the snapshot directory to the unit search path of your 
compiler.

When I try to follow the instructions, I get:
fpcmake -r
Processing Makefile.fpc
Error: Target "win32", package "rtl" not found

I have fpcdir=j:\Programming\fpc 3.0.2  set in my environment variables
I'd recommend reinstalling FPC in a directory without spaces. Spaces in 
paths can cause trouble for fpcmake and makefiles in general. By default 
FPC installs in a directory without spaces, so it's not well tested at all.


Make -v  reports:
GNU Make 3.82
Built for i686-pc-mingw32

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 2:07 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 08:28 PM, James Richters wrote:

I have done the "download snapshot" but I just don't know what to do with it 
now to properly integrate it into my compiler.

Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
units\i386-win32 from the snapshot directory to the unit search path of your 
compiler.

Here is what I have tried to do.
First I moved everything from J:\Programming\FPC
3.0.2\units\i386-win32\graph to a temporary location so it wouldn't
find the old versions of ptcgraph and ptccrt Now when I try to compile
my program, I get unit ptcgraph not found... which is what I want because I 
want to be sure not to get the old version Then I copied the entire snapshot to 
into J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas Now when I try to compile 
my program, I still get unit ptcgraph not found.
I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the
directories Now I got an error that it could not find graphh.inc So I
copied all the .inc files from J:\Programming\FPC 
3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
them.
Now I can can compile successfully and run my program, but it has the same 
issues.
But I notice the modified file win32kbd.inc is never used.   I have even 
removed it temporarily and I can still compile successfully.  I did a 
search for win32kbd and I find win32kbdd.inc but not win32kbd.inc

That is where I am at.  I think If I could correctly apply
win32kbd.inc it may work

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On
Behalf Of Nikolay Nikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 06:09 PM, James Richters wrote:

I think I figured out my problem, but I'm not sure how to fix it.   I was 
looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
And I see that the change made was to win32kbd.inc, but I don't think I'm using 
the updated version of it.   I think my problem is that I just compiled 
ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
apparently that's not the correct way to do it.So then I tried adding the 
entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/

But that's a fix, that's not yet released (because it needs testing), so it's 
in svn trunk only, and not in the release files. Get it from:

https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion
(TortoiseSVN) and checkout https://svn.code.sf.net/p/ptcpas/code/trunk


Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now It 
can't find ptcgraph, even though it's there under  
FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
guessing and really don't have a clue the proper way to integrate this into my 
fpc compiler.

Could someone please tell me the correct way I should be doing this so that the 
compiler will find the correct versions of all the files necessary?

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On
Behalf Of James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?


Here is a simple sample program that has the issue for me on both my windows 10 
desktop and my windows 10 laptop, both are 64bit.
https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also af

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Just like you now use -FuSomePath to tell the compiler where to find units, 
>you can use -FiSomePath to tell the compiler where to look for include files.

I've been trying to compile with Free Pascal Text IDE, I have no experience 
with compiling programs from the command line,  but this gave me an idea to try 
it from command line instead.

First, I thought I would start clean, and  I re-installed Free Pascal and left 
the directory structure alone, and just changed the drive to H: where I have a 
lot of room. I suspect it did not like the space I had in my directory name.
From the new install of FPC 3.0.2 on my H Drive, I was able to successfully 
follow the instructions and I finally managed to compile ptcpas-code-715-trunk.

I was also able to compile the examples and they executed correctly.  So I used 
the command line used to compile one of the examples, and put the whole path of 
ptcpas in and I was finally able to successfully compile my test program with 
the following command line:
h:/FPC/3.0.2/bin/i386-Win32/ppc386.exe 
-Fuh:/ptcpas-code-715-trunk/units/i386-win32/ -FE. 
-FUh:/ptcpas-code-715-trunk/units/i386-win32 -di386 dual-key-screen.pas
When I compiled It this way, I am now able to ALT-Tab from the graph window and 
when I return everything is fine,  so this proves the problem has been solved, 
but integrating the solution into my compiler is the problem.

I am trying to get it to work from the Free Pascal text mode IDE
but when I add h:\ptcpas-code-715-trunk\units\i386-win32 to the list of unit 
directories in the Free Pascal text IDE and try to compile my program, I get:

PPU Loading H:\ptcpas-code-715-trunk\units\i386-win32\ptcgraph.ppu 
║ PPU Source: ptcgraph.pp not found
║ PPU Source: graphh.inc not available
║ PPU Source: graph.inc not available
║ PPU Source: fontdata.inc not available
║ PPU Source: clip.inc not available
║ PPU Source: palette.inc not available
║ PPU Source: modes.inc not available
║ PPU Source: fills.inc not available
║ PPU Source: gtext.inc not available
║ Recompiling ptcgraph, checksum changed for ptc
║ dual-key-screen.pas(3,6) Fatal: Can't find unit ptcgraph used by KeyTestWin.p
║ dual-key-screen.pas(0) Fatal: Compilation aborted

How do I properly use the FreePascal Text mode IDE to use the ptcpas units I 
compiled?

My entries under directories > Units are:
H:\ptcpas-code-715-trunk\units\i386-win32
h:\FPC\3.0.2\units\$fpctarget
h:\FPC\3.0.2\units\$fpctarget\*
h:\FPC\3.0.2\units\$fpctarget\rtl

All other directories tabs are blank

Thanks for the help

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Ewald
Sent: Tuesday, May 23, 2017 2:03 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

On 23/05/17 19:50, James Richters wrote:
> *correction  to directory names:
> Now I got an error that it could not find graphh.inc So I copied all the .inc 
> files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc  to 
> J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no 
> idea how else to make it find them.

Just like you now use -FuSomePath to tell the compiler where to find units, you 
can use -FiSomePath to tell the compiler where to look for include files.

See `fpc -h`, under the section "-F Set file names and paths:" for a list of 
other related switches.


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

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

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 23.05.2017 um 05:15 schrieb Ryan Joseph:
> and compiling with -O2 -Cfsse3 (the non-SDL

If you do benchmarking, at least -O3 should be used, -O4 is also fine most of 
the time.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
>units\i386-win32 from the snapshot directory to the unit search path of your 
>compiler.

When I try to follow the instructions, I get:
fpcmake -r
Processing Makefile.fpc
Error: Target "win32", package "rtl" not found

I have fpcdir=j:\Programming\fpc 3.0.2  set in my environment variables

Make -v  reports:
GNU Make 3.82
Built for i686-pc-mingw32

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 2:07 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 08:28 PM, James Richters wrote:
> I have done the "download snapshot" but I just don't know what to do with it 
> now to properly integrate it into my compiler.
Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
units\i386-win32 from the snapshot directory to the unit search path of your 
compiler.
>
> Here is what I have tried to do.
> First I moved everything from J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph to a temporary location so it wouldn't 
> find the old versions of ptcgraph and ptccrt Now when I try to compile 
> my program, I get unit ptcgraph not found... which is what I want because I 
> want to be sure not to get the old version Then I copied the entire snapshot 
> to into J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas Now when I try to 
> compile my program, I still get unit ptcgraph not found.
> I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the 
> directories Now I got an error that it could not find graphh.inc So I 
> copied all the .inc files from J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
> them.
> Now I can can compile successfully and run my program, but it has the same 
> issues.
> But I notice the modified file win32kbd.inc is never used.   I have even 
> removed it temporarily and I can still compile successfully.  I did a 
> search for win32kbd and I find win32kbdd.inc but not win32kbd.inc
>
> That is where I am at.  I think If I could correctly apply 
> win32kbd.inc it may work
>
> James
>
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Nikolay Nikolov
> Sent: Tuesday, May 23, 2017 1:03 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>
>
> On 05/23/2017 06:09 PM, James Richters wrote:
>> I think I figured out my problem, but I'm not sure how to fix it.   I was 
>> looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
>> And I see that the change made was to win32kbd.inc, but I don't think I'm 
>> using the updated version of it.   I think my problem is that I just 
>> compiled ptcgraph.pp and replaced ptcgraph.ppu in 
>> FPCWin\units\i386-win32\graph so apparently that's not the correct way 
>> to do it.So then I tried adding the entire folder downloaded from 
>> https://sourceforge.net/projects/ptcpas/files/
> But that's a fix, that's not yet released (because it needs testing), so it's 
> in svn trunk only, and not in the release files. Get it from:
>
>https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/
>
> Either click on "Download Snapshot", or install subversion 
> (TortoiseSVN) and checkout https://svn.code.sf.net/p/ptcpas/code/trunk
>
>> Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
>> ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now 
>> It can't find ptcgraph, even though it's there under  
>> FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
>> guessing and really don't have a clue the proper way to integrate this into 
>> my fpc compiler.
>>
>> Could someone please tell me the correct way I should be doing this so that 
>> the compiler will find the correct versions of all the files necessary?
>>
>> James
>>
>>
>> -Original Message-
>> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
>> Behalf Of James Richters
>> Sent: Monday, May 22, 2017 7:13 PM
>> To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
>> Subject: Re: [fpc-pascal] FPC Graphics options?
>>
>>> Here is a simple sample program that has the issue for me on both my 
>>> windows 10 desktop and my windows 10 laptop, both are 64bit.
>>> https://hastebin.com/nubonozaho.pas
>> I started thin

Re: [fpc-pascal] FPC Graphics options?

[wkitty42]

On 05/22/2017 07:13 PM, James Richters wrote:

The problem is not the ALT-tab from the graphics window,  it's ALT being
pressed when the window focus changes.   CTRL is also affected, but not
shift.
this is really sounding like a problem i remember from early GUIs several 
decades ago... when switching tasks, the state of the CTRL or ALT or SHIFT keys 
would ""get stuck""... when returning, things weren't right but tapping the 
CTRL, ALT and/or SHIFT keys a few times would return them to their proper state...


i remember the problem but am not aware of the fix... i know i dealt with it on 
OS/2 as well as winwhatever... we just got into the habit of tapping those keys 
when we returned...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/23/2017 08:28 PM, James Richters wrote:

I have done the "download snapshot" but I just don't know what to do with it 
now to properly integrate it into my compiler.
Follow the instructions in docs/INSTALL.txt to compile the package. Then 
add units\i386-win32 from the snapshot directory to the unit search path 
of your compiler.


Here is what I have tried to do.
First I moved everything from J:\Programming\FPC 3.0.2\units\i386-win32\graph 
to a temporary location so it wouldn't find the old versions of ptcgraph and 
ptccrt
Now when I try to compile my program, I get unit ptcgraph not found... which is 
what I want because I want to be sure not to get the old version
Then I copied the entire snapshot to into J:\Programming\FPC 
3.0.2\units\i386-win32\ptcpas
Now when I try to compile my program, I still get unit ptcgraph not found.
I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the directories
Now I got an error that it could not find graphh.inc
So I copied all the .inc files from J:\Programming\FPC 
3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
them.
Now I can can compile successfully and run my program, but it has the same 
issues.
But I notice the modified file win32kbd.inc is never used.   I have even 
removed it temporarily and I can still compile successfully.  I did a 
search for win32kbd and I find win32kbdd.inc but not win32kbd.inc

That is where I am at.  I think If I could correctly apply win32kbd.inc it may 
work

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 06:09 PM, James Richters wrote:

I think I figured out my problem, but I'm not sure how to fix it.   I was 
looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
And I see that the change made was to win32kbd.inc, but I don't think I'm using 
the updated version of it.   I think my problem is that I just compiled 
ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
apparently that's not the correct way to do it.So then I tried adding the 
entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/

But that's a fix, that's not yet released (because it needs testing), so it's 
in svn trunk only, and not in the release files. Get it from:

   https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion (TortoiseSVN) and 
checkout https://svn.code.sf.net/p/ptcpas/code/trunk


Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now It 
can't find ptcgraph, even though it's there under  
FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
guessing and really don't have a clue the proper way to integrate this into my 
fpc compiler.

Could someone please tell me the correct way I should be doing this so that the 
compiler will find the correct versions of all the files necessary?

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On
Behalf Of James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?


Here is a simple sample program that has the issue for me on both my windows 10 
desktop and my windows 10 laptop, both are 64bit.
https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


___
fpc-pasc

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I have done the "download snapshot" but I just don't know what to do with it 
now to properly integrate it into my compiler.  

Here is what I have tried to do.
First I moved everything from J:\Programming\FPC 3.0.2\units\i386-win32\graph 
to a temporary location so it wouldn't find the old versions of ptcgraph and 
ptccrt
Now when I try to compile my program, I get unit ptcgraph not found... which is 
what I want because I want to be sure not to get the old version
Then I copied the entire snapshot to into J:\Programming\FPC 
3.0.2\units\i386-win32\ptcpas
Now when I try to compile my program, I still get unit ptcgraph not found.
I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the directories
Now I got an error that it could not find graphh.inc 
So I copied all the .inc files from J:\Programming\FPC 
3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
them.
Now I can can compile successfully and run my program, but it has the same 
issues.
But I notice the modified file win32kbd.inc is never used.   I have even 
removed it temporarily and I can still compile successfully.  I did a 
search for win32kbd and I find win32kbdd.inc but not win32kbd.inc

That is where I am at.  I think If I could correctly apply win32kbd.inc it may 
work

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 06:09 PM, James Richters wrote:
> I think I figured out my problem, but I'm not sure how to fix it.   I was 
> looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
> And I see that the change made was to win32kbd.inc, but I don't think I'm 
> using the updated version of it.   I think my problem is that I just compiled 
> ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
> apparently that's not the correct way to do it.So then I tried adding the 
> entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
But that's a fix, that's not yet released (because it needs testing), so it's 
in svn trunk only, and not in the release files. Get it from:

  https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion (TortoiseSVN) and 
checkout https://svn.code.sf.net/p/ptcpas/code/trunk

> Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
> ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now 
> It can't find ptcgraph, even though it's there under  
> FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
> guessing and really don't have a clue the proper way to integrate this into 
> my fpc compiler.
>
> Could someone please tell me the correct way I should be doing this so that 
> the compiler will find the correct versions of all the files necessary?
>
> James
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of James Richters
> Sent: Monday, May 22, 2017 7:13 PM
> To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>> Here is a simple sample program that has the issue for me on both my windows 
>> 10 desktop and my windows 10 laptop, both are 64bit.
>> https://hastebin.com/nubonozaho.pas
> I started thinking about this, and did some more tests, and I think I have 
> narrowed down what is really happening, but not sure how to fix it.
>
> The problem is not the ALT-tab from the graphics window,  it's ALT being 
> pressed when the window focus changes.   CTRL is also affected, but not 
> shift.  Try this:
> Go to Graph window,  type some letters,  see that it's working correctly,  
> now hold just ALT, or CTRL - switch to another window by clicking on it.  
> Click on console window, see letters are working correctly, now go back to 
> graph window,  anything you press acts like ALT, or CTRL is still being 
> pressed until you actually enter a keystroke using ALT, or CTRL.   It seems 
> to me there is probably some flag or variable being set that the alt or ctrl 
> key is being pressed, but is being interrupted by the window focus change, 
> when focus is brought back, the variable is still set for ALT or CTRL being 
> down, but neither is down anymore, but the flag cannot be cleared until a key 
> sequence using ctrl or alt is used.  I did also notice that just hitting alt 
> or ctrl and releasing it in the graph window clears the condition and 
> characters are back to normal again.
>
>

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/23/2017 06:09 PM, James Richters wrote:

I think I figured out my problem, but I'm not sure how to fix it.   I was 
looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
And I see that the change made was to win32kbd.inc, but I don't think I'm using 
the updated version of it.   I think my problem is that I just compiled 
ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
apparently that's not the correct way to do it.So then I tried adding the 
entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
But that's a fix, that's not yet released (because it needs testing), so 
it's in svn trunk only, and not in the release files. Get it from:


 https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion (TortoiseSVN) 
and checkout https://svn.code.sf.net/p/ptcpas/code/trunk



Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now It 
can't find ptcgraph, even though it's there under  
FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
guessing and really don't have a clue the proper way to integrate this into my 
fpc compiler.

Could someone please tell me the correct way I should be doing this so that the 
compiler will find the correct versions of all the files necessary?

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?


Here is a simple sample program that has the issue for me on both my windows 10 
desktop and my windows 10 laptop, both are 64bit.
https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


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

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


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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I think I figured out my problem, but I'm not sure how to fix it.   I was 
looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
And I see that the change made was to win32kbd.inc, but I don't think I'm using 
the updated version of it.   I think my problem is that I just compiled 
ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
apparently that's not the correct way to do it.So then I tried adding the 
entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now It 
can't find ptcgraph, even though it's there under  
FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
guessing and really don't have a clue the proper way to integrate this into my 
fpc compiler.

Could someone please tell me the correct way I should be doing this so that the 
compiler will find the correct versions of all the files necessary? 

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] FPC Graphics options?

>Here is a simple sample program that has the issue for me on both my windows 
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.   

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


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

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-22 23:11, nore...@z505.com wrote:

What happens if you use the SVN bridge that allows you to run svn
commands to a git server? does git suffer the same problems in this mode
too?


Replied in "fpc-other" mailing list.

Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 22, 2017, at 9:24 PM, Marco van de Voort  wrote:
> 
> I saw Florian worked hard last weekend, and the new value is 23.0 - 23.6
> (was 19.1 - 19.5) for x86_64. Sometimes floating point division by zero.
> 
> and for x86 10.8 but half of the time I get an exception (ctrl-C ??!?!) here.

Thanks for working on this.

I updated to the latest trunk version just now  and compiling with -O2 -Cfsse3 
(the non-SDL version which another user ported) and replacing FLoor() with 
Trunc() (not sure if that changes the output) I get a 28fps but only 11fps with 
Floor().

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

I realized I should have posted this in fpc-other. So, please reply in 
[fpc-other] and not here.



On 05/23/2017 03:03 AM, Nikolay Nikolov wrote:



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

On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64


Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others
are floating point division? How does Java handle this so much better
than FPC and what are the work arounds? Just curious. As it stands I
can only reason that I need to avoid dividing floats in FPC like the
plague.



Isn't java just a wrapper around C?
No. Java compilers generate code for a virtual machine, called JVM 
(Java Virtual Machine). They do not generate code for x86 CPUs or any 
other real CPU. The JVM is like a fictional CPU, that does not exist 
in a silicon implementation anywhere, but is implemented in software 
only.


C compilers usually generate native code for real CPUs, just like FPC 
does.


Why does it matter? The x86 instruction set architecture has gone 
through quite a long evolution and there are many instruction set 
extensions, that were added along the way: 32-bit extensions (x86 
originally started as 16-bit), the x87 FPU instructions (this was a 
separate coprocessor in the beginning, but later became integrated 
into the main CPU starting from the 486DX onwards), MMX, SSE, SSE2, 
the 64-bit extensions (x86_64), SSE3, AVX, etc.


There are generally two ways to do floating point on the x86:
  - the x87 FPU - this is used by default by the FPC compiler on 
32-bit (and 16-bit) x86
  - the SSE2 instruction set extension - this can replace the FPU and 
generally works faster on modern CPUs. This is used by default by the 
64-bit FPC compiler. That's because all 64-bit x86 CPUs support this 
extension.


There is one disadvantage to using SSE2 instead of the x87 FPU - the 
SSE2 instructions don't support the 80-bit extended precision float 
type. There's no support for it in any of the later x86 instruction 
set extensions either. If you need the 80-bit precision, the x87 FPU 
is the only way to go, even on x86_64.


There's another disadvantage to using SSE2 by default on 32-bit x86 - 
programs, compiled for SSE2 will not run on older CPUs, which don't 
support SSE2. There's simply no way around that. Therefore, we cannot 
make use of SSE2 by default, without sacrificing backwards 
compatibility. The only exception to that are certain RTL routines, 
like Move() or FillChar() which take advantage of the SSE2 extensions, 
because they check the CPU capabilities at runtime and internally 
dispatch to several different implementations, for different CPU 
types, which are all compiled and linked in. But you simply cannot 
take this approach for every FPU operation, because if you do a CPU 
check on every floating point calculation, the overhead of all the 
checks will make your program slower that it would be, if you simply 
used the x87 FPU instructions for example.


Virtual machines like the JVM don't have this problem and they can 
always take advantage of newer instruction set extensions, without 
sacrificing backward compatibility with older CPUs. Why? Because the 
JVM bytecode has nothing to do with any processor at all. When you run 
your program, the JVM bytecode is converted ("Just-In-Time" compiled) 
to native code for the CPU the user has. So, if the user is running 
your Java program on a CPU, that has SSE3, the JIT compiler will know 
it can use SSE2 and SSE3 instructions. If another person runs it on an 
older CPU, which doesn't have SSE2, the JIT compiler will compile it 
to use x87 FPU instructions. Sounds so great, you're going to ask if 
there are any disadvantages to this approach? And, of course, there 
are - since the program is essentially recompiled every time the user 
runs it, starting Java programs take a long time. There's also limited 
time that the JIT compiler can spend on optimization (otherwise 
programs will start even slower). There are ways to combat that, by 
using some sort of cache (.NET has the global assembly cache), but 
they are far from perfect either - these caches eat a lot of disk 
space and then either program installation or the first time it is run 
(when the JIT compiled assembly hasn't been added to the cache) 
becomes slow. In general native programs (FPC and C programs) feel a 
lot snappier to most users, because they start fast. But in the highly 
specific case of heavy floating point code (where SSE2 vs x87 FPU 
instruction sets matter), a native program (C or Pascal) compiled for 
the x87 FPU will be slower than the JVM, because the JVM will use SSE2 
and SSE3 on modern CPUs.


Does this mean that it's always better to use the JVM? No. I mean, if 
it suits you, go ahead and use 

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Here is a simple sample program that has the issue for me on both my windows 
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.   

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64


Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others
are floating point division? How does Java handle this so much better
than FPC and what are the work arounds? Just curious. As it stands I
can only reason that I need to avoid dividing floats in FPC like the
plague.



Isn't java just a wrapper around C?

So could compare to C too, to see how it does it. But, I don't know 
anything about Java internals.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-19 05:25, Graeme Geldenhuys wrote:

On 2017-05-19 06:58, Florian Klämpfl wrote:
Over the weekend I’ll verify by testing on both FreeBSD and Windows, 
and

then see if “calling conventions” make any difference.


*BSD is the same as Linux.


Good to know, thanks.


It has its purposes, but it is not suitable for the main repository of 
FPC.


It is not a technical thing but just a matter of mind. ;-)



What happens if you use the SVN bridge that allows you to run svn 
commands to a git server? does git suffer the same problems in this mode 
too?


https://help.github.com/articles/support-for-subversion-clients/

Local working copy issues Florian described would be an issue with this 
bridge, or not an issue?


I'm wondering because I use the bridge for some things, as sometimes I 
find svn simpler. But it may not solve the issues Florian describes

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-19 06:16, Graeme Geldenhuys wrote:

On 2017-05-18 16:33, Reimar Grabowski wrote:

and JS is clearly not faster than FPC.


The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.

   http://jsdo.it/notch/dB1E

Again, what does that say about FPC generated binary performance.



I think javascript has been recently heavily improved since millions of 
people are using javascript and work was done to make it faster, whereas 
not so many millions of people use fpc.


Still this is all a good test case to find flaws/slow downs in fpc and 
fix them.


IMO this is like a bug report that's not really a bug, as the code may 
still be correct, just slow...


And IMO when someone finds an issue like this, a slow part of the RTL or 
the compiler, it is a good thing not a bad thing because now is a chance 
to find out where the issue is. Whereas if this had not been found or 
reported it would have gone unnoticed.


It might even be just 2 procedures somewhere that are extremely slow, 
but correct, in some unit..


Until someone profiles it... no one knows. Sorry, I'm not up to date on 
the latest findings of this thread if anyone profiled it or not.


Again if it is an rtl issue, the solution is to swap in a faster rtl 
unit or even a couple of procedures .. that are causing it to become 
slow. Or it could be some while loop in the rtl or a for loop. Or a 
concatenation that wasn't using a fast Copy(), or something that could 
have used a buffer, but did it one by one instead.


But reporting and finding the issue, imo, is a good thing... even if you 
currently find fpc binaries slow, at least you found something to fix! 
:-)

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 22 May 2017, Nikolay Nikolov wrote:

> Today, I checked whether we can take advantage of this optimization for
> floats, but I didn't see any load-modify-store instructions in the x86
> instruction set (neither x87, nor SSE/AVX). Are there any floating point
> instructions on any architecture, that we support, that does
> load-modify-store (i.e. modify-in-place) of a memory operand?

No, but wouldn't it also cover cases like:

move.l d1,d0
op.l   d2,d0
move.l d0,d1

to

op.l d2,d1

I'm pretty sure it "fixed" a lot of those for m68k.

This doesn't contain memory ops, still, the difference is significant both
in code size and performance. (Of course on the other hand it might not be
ideal for CPUs with 3 operants, if one of the source and the target is the
same, but that's a different case...)

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

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 22.05.2017 um 19:34 schrieb Nikolay Nikolov:
> 
> 
> On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:
>>
>>
>> On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
>>> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
 Hi,

 On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:

> I think Jeppe wanted to add vector support. Though the question here is
> whether one wants to optimize/detect this at the AST level and convert
> that to implicit vectors or at the CSE level.
 I think the higher level you can do an optimization/simplification, the
 higher you should do it. Otherwise the lower layers get really messy, as
 they already are in some cases. Well, in general, we should up our
 floating point game. For example if Nikolay's recent load-modify-store
 optimization would work on floats, that would already a nice step forward
 in this case. ;) (Sorry for my ignorance, if it already works, missed that
 then.)
>> No, it does not work for floats, yet, but feel free to add support for them 
>> as well :)
> Today, I checked whether we can take advantage of this optimization for 
> floats, but I didn't see any
> load-modify-store instructions in the x86 instruction set (neither x87, nor 
> SSE/AVX). Are there any
> floating point instructions on any architecture, that we support, that does 
> load-modify-store (i.e.
> modify-in-place) of a memory operand?

Not that I am aware of.

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:



On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:

On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:

Hi,

On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:

I think Jeppe wanted to add vector support. Though the question 
here is

whether one wants to optimize/detect this at the AST level and convert
that to implicit vectors or at the CSE level.

I think the higher level you can do an optimization/simplification, the
higher you should do it. Otherwise the lower layers get really 
messy, as

they already are in some cases. Well, in general, we should up our
floating point game. For example if Nikolay's recent load-modify-store
optimization would work on floats, that would already a nice step 
forward
in this case. ;) (Sorry for my ignorance, if it already works, 
missed that

then.)
No, it does not work for floats, yet, but feel free to add support for 
them as well :)
Today, I checked whether we can take advantage of this optimization for 
floats, but I didn't see any load-modify-store instructions in the x86 
instruction set (neither x87, nor SSE/AVX). Are there any floating point 
instructions on any architecture, that we support, that does 
load-modify-store (i.e. modify-in-place) of a memory operand?


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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Marco van de Voort said:
> 
> i386:
> just compile : 7.9   (both 3.0.2 and 3.1.1)
>   -O4  3.0.2: 8.2   3.1.1: 8.1
> -O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 3.0.2 8.35   3.1.1 : 12.1 
> 
> 
> x64: only 3.1.1, sometimes divide by zero (have to set exception mask?)
> just compile 13.9
> -O4   :  19.5 
> -O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 : 19.1

I saw Florian worked hard last weekend, and the new value is 23.0 - 23.6
(was 19.1 - 19.5) for x86_64. Sometimes floating point division by zero.

and for x86 10.8 but half of the time I get an exception (ctrl-C ??!?!) here.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
  Tonight I'll also add the option for changing the title bar text, 
when in windowed mode.
Implemented in r715. Note that you still cannot change the window title, 
after the window has been created, but at least now you can set it (in a 
multiplatform way) before InitGraph.


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

Re: [fpc-pascal] FPC Graphics options?

[Jonas Maebe]

On 21/05/17 14:58, Felipe Monteiro de Carvalho wrote:

Well, Java also has its issues.


Please move that kind of posts to the fpc-other mailing list.

Thanks.


Jonas
FPC mailing lists admin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Felipe Monteiro de Carvalho]

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. I am studying Java and I am completely
shocked that you need to use "volatile" to avoid serious hard-to-debug
multithreading bugs.

It looks like you pretty much need to declare all vars that might be
accessed from different threads as volatile from what I understood,
because otherwise the java compiler might never write values to the
variable at all, instead write only to a local cache. Amazing!

In FPC this isn't needed since assignments always change real memory.
Thinking about it, maybe FPC needs the oposite kind of variable
modified, a "notvolatile" so that it could optimize more agressively
in case you are 100% sure this code will be run on a single thread...

This simple program never ends if you delete the volatile keyword (I
tested here in Windows):

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++;
}
System.out.println("Thread 1 finished. Counted up to "
+ counter);
}
}).start();
new Thread(new Runnable()
{
public void run()
{
// Sleep for a bit so that thread 1 has a chance to start
try
{
Thread.sleep(100);
} catch (InterruptedException ignored) { }
System.out.println("Thread 2 finishing");
running = false;
}
}).start();
  }
public static void main(String[] args)
{
new FelipeTestThread().test();
}
}

Not to mention that 1 file per class is super annoying and it is
impossible to resize arrays and there are no unsigned integers.
Generics can't accept non-Object values. There is no way to pass
parameters by reference, accessing operating system APIs is a
nightmare which involves writing large JNI wrappers in C...etc.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jonas Maebe]

On 21/05/17 10:35, Florian Klämpfl wrote:

Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal:

At least if the compiler also recognizes that oy and oz are constant...


If the typed constants are declared as read only, we could treat them as real 
constants. Maybe at
least in -O4 mode?


They're plain local variables that are assigned once and never changed. 
That said, simply treating them (and floor(oy)/floor(oz)) as constants 
does not improve the generated code very much. There's probably another 
similar thing that causes a large part to be simplified/evaluated away 
in the C version.



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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/21/2017 06:34 AM, Ryan Joseph wrote:


I just compiled with ppcx64 3.1.1 (from 3.0.2) and went from 8fps to 22fps 
without optimizations and 28fpc with (I got some divide by zero errors but 
that’s just translations). What is that about? What changed?

Just curious, why isn’t -Cfsse3 always enabled in optimizations? It seems like 
we want this on always.
Compatibility with older CPUs. For example, some Athlon 64 CPUs 
(steppings earlier than Venice) don't support SSE3. If you don't care 
about them, feel free to add this option to your fpc.cfg file.


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

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal:
> On 20.05.2017 21:34, Jonas Maebe wrote:
>> There's at least one minor twist of the classic "C compiler evaluates
>> constant stuff at compile time":
>> 1) oy and oz are constant. The "floor" function is a standard C library
>> function, and hence C compilers know what it does and can evaluate it at
>> compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions
>> are (equal) constants for C compilers.
> 
> Would it help here if we'd declare suitable overloads for Floor() for


The overloads are imo not needed, if x is randomly positive/negative the 
following code is much
better than the current implementation:

function Floor(x : float) : Integer;Inline;
  begin
Result := Trunc(x)-ord(Frac(x)<0);
  end;

> the various floating point types instead of only the "Float" one,
> declare them as inline and have the inline nodes for Frac() and Trunc()
> handle constant values?

I adjusted the inline heuristics so the Floor code above is completely folded 
for constant arguments.

> At least if the compiler also recognizes that oy and oz are constant...

If the typed constants are declared as read only, we could treat them as real 
constants. Maybe at
least in -O4 mode?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 21, 2017, at 2:34 AM, Jonas Maebe  wrote:
> The Pascal test program that was benchmarked here contains a number of 
> bugs/wrong translations from the C code (some stem from the original version, 
> another one was added):

Thanks for looking this over. I’m personally a little worried when I see this 
kind of thing because I don’t know the causes and how it affects my code. 
Despite all the noise I think we finally got down to bed rock though. 
Unfortunately as a person who doesn’t understand compilers well all I can 
conclude from this is to avoid floating point math in tight loops. That’s 
probably not accurate enough but that’s the only way I can understand it right 
now.

What I’m hearing is there are some bad C translations and some missing FPC 
features. Not sure what percent is translations and what is FPC but I think 
it’s mainly on the side of the compiler.

> 
> Then, there's one thing that can be done to optimize the Pascal version 
> (after removing the bugs above):
> 1) Compile with SSE3 or higher, in particular because SSE3 can be used to 
> implement trunc() with a single instruction (otherwise we pass via a helper 
> that uses the x87 fpu, which moreover has to reconfigure it to change the 
> rounding more and restore it afterwards). However, there does seem to be a 
> bug in FPC 3.0.2 whereby compiling this program for -O2 -Cfsse3 causes it to 
> crash, because then it loads data from an 8-byte aligned location on the 
> stack. It works fine when compiled with trunk and -O2 -Cfsse3 though (at 
> least for 64 bit).

I just compiled with ppcx64 3.1.1 (from 3.0.2) and went from 8fps to 22fps 
without optimizations and 28fpc with (I got some divide by zero errors but 
that’s just translations). What is that about? What changed?

Just curious, why isn’t -Cfsse3 always enabled in optimizations? It seems like 
we want this on always.

> 
> There's at least one minor twist of the classic "C compiler evaluates 
> constant stuff at compile time":
> 1) oy and oz are constant. The "floor" function is a standard C library 
> function, and hence C compilers know what it does and can evaluate it at 
> compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions are 
> (equal) constants for C compilers.

How are those constants? I see them defined as "float oy = 32.5;” in the c 
version.


Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

On 20.05.2017 21:34, Jonas Maebe wrote:
> There's at least one minor twist of the classic "C compiler evaluates
> constant stuff at compile time":
> 1) oy and oz are constant. The "floor" function is a standard C library
> function, and hence C compilers know what it does and can evaluate it at
> compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions
> are (equal) constants for C compilers.

Would it help here if we'd declare suitable overloads for Floor() for
the various floating point types instead of only the "Float" one,
declare them as inline and have the inline nodes for Frac() and Trunc()
handle constant values?
At least if the compiler also recognizes that oy and oz are constant...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 20.05.2017 um 21:34 schrieb Jonas Maebe:
> Also in summary, very little was learned from this. We have known for a long 
> time that FPC needs SSA
> for better code generation for loops (and Florian has been working on it for 
> a long time too).

Actually, this is not completely true :) What FPC needs to generate better code 
in this case (on SYS
V ABI targets), is life splitting around call nodes. This needs no SSA/SSA 
might actually not help.
I have a patch for it, but not finished, as another patch is needed for this to 
make it work well:
spill coalescing (nodes/registers which are spilled, are spilled to the same 
memory location if they
are not interfering but connected by a move). I have also a half backed patch 
for this, but never
finished it nor committed it to the official trunk. Both patches combined 
result for the example in
much better code regarding register usage as variables can go to xmm registers 
which are
stored/restored around call nodes.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jonas Maebe]

On 19/05/17 02:54, Ryan Joseph wrote:

On May 18, 2017, at 10:40 PM, Jon Foster  wrote:

62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others are 
floating point division?
How does Java handle this so much better than FPC and what are the work arounds?
The Pascal test program that was benchmarked here contains a number of 
bugs/wrong translations from the C code (some stem from the original 
version, another one was added):
1) casting a floating point number to an int in C does not round, but 
truncates (I think this may have been mentioned earlier in the thread, I 
didn't read everything)
2) The usage of floor in the test program is wrong. C's floor takes a 
floating point number and returns one. The math unit's floor function 
takes a floating point number and returns an integer. In the Pascal 
version, this integer is then converted back to a floating point number 
because the rest of that expression also uses floating point.
3) The Pascal version uses longword instead of int32 for a number of 
variables (that are "int" in the C version). This results in one 
expression getting evaluated as 64 bit on 32 bit systems, which is where 
the FPC_DIV_INT64 calls come from (that's a routine to perform 64 bit 
*integer* divisions on 32 bit platforms)
4) frac() is only used to get a monotonous increasing value as part of 
the data input for the test program. The C code (and original Pascal 
version) uses a tick count and multiplies/divides that, which is much 
faster.


Then, there's one thing that can be done to optimize the Pascal version 
(after removing the bugs above):
1) Compile with SSE3 or higher, in particular because SSE3 can be used 
to implement trunc() with a single instruction (otherwise we pass via a 
helper that uses the x87 fpu, which moreover has to reconfigure it to 
change the rounding more and restore it afterwards). However, there does 
seem to be a bug in FPC 3.0.2 whereby compiling this program for -O2 
-Cfsse3 causes it to crash, because then it loads data from an 8-byte 
aligned location on the stack. It works fine when compiled with trunk 
and -O2 -Cfsse3 though (at least for 64 bit).


There's at least one minor twist of the classic "C compiler evaluates 
constant stuff at compile time":
1) oy and oz are constant. The "floor" function is a standard C library 
function, and hence C compilers know what it does and can evaluate it at 
compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions 
are (equal) constants for C compilers.


Finally, there are two things FPC definitely is missing:
1) an SSE version of the int() function (which is the basis of a 
floating point version of floor()) (fairly specific to this program)
2) SSA support in loops (to make better use of SSE registers; related to 
Florian's note about the calling conventions). However, without the 
previous changes, even FPC code compiled to LLVM IR and then compiled to 
machine code with Clang (and hence with full SSA support) results in 
even worse performance than the code directly compiled with FPC.


There are definitely more things (as I did not manage to get FPC's LLVM 
IR to compile to a version that's equally fast as the LLVM IR generated 
from the C program), but I already spent more time than is reasonable on 
this. I hope the "the sky is falling" comments will stop though.


In summary, as has been mentioned by several people in this thread: you 
(not directed have to you personally, Ryan) always have to check where 
your program's slowness comes from, otherwise your test/benchmark is 
worse than useless (because it just creates confusion, and wastes other 
people's time when they get tired of mailing list getting flooded by the 
same information-less statements over and over again).


Also in summary, very little was learned from this. We have known for a 
long time that FPC needs SSA for better code generation for loops (and 
Florian has been working on it for a long time too).



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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/19/2017 06:13 PM, Jon Foster wrote:


On 05/19/2017 04:11 AM, Nikolay Nikolov wrote:



On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the 
others are floating point division? How does Java handle this so 
much better than FPC and what are the work arounds? Just curious. As 
it stands I can only reason that I need to avoid dividing floats in 
FPC like the plague.
[...] The default options for the i386 compiler is to target the 
Pentium CPU, which does not have SSE. This gives most compatibility 
and least performance, but that's what's appropriate for most users, 
because for most desktop applications, CPU speed is no longer an 
issue. Only very specific tasks, such as software 3D rendering need 
high CPU performance, and people doing that stuff, usually know very 
well their compiler options and how to enable support for modern 
instruction extensions for maximum performance. Of course, people 
coming from a Java background might not be used at all to having to 
do this kind of stuff, but it's really not that hard.


As stated I tried *ALL* of the FPU settings and received the same 
result or an "access violation", which I assumed meant my FPU did not 
support that feature set.
Access violation means usually accessing memory, which is way out of 
bounds. You can try turning range and overflow checking on, but there's 
no guarantee it is going to catch it. However, you should try to narrow 
it down to find the offending location. It could be a bug in your code, 
or a bug in the code generator (which produces an invalid result from a 
given calculation).
I even tried to enable emulation, to see what the difference would be, 
but ppc386 said it was an invalid switch even though it lists it in 
the help output.
Emulation is only supported under go32v2 (the 32-bit DOS target) and is 
only needed on 486SX and 386 CPUs without an FPU, so it's very unlikely 
you would need it. 486DX and above all have a built-in FPU and need no 
emulation. And newer instruction set extensions such as SSE2 and SSE3 
are never emulated, because emulation usually defeats the purpose of 
your code being faster. However, it is very likely that your CPU has 
SSE2 and SSE3 support, unless it is very ancient. Btw, what CPU do you have?


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

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/19/2017 04:11 AM, Nikolay Nikolov wrote:



On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others 
are floating point division? How does Java handle this so much better 
than FPC and what are the work arounds? Just curious. As it stands I can 
only reason that I need to avoid dividing floats in FPC like the plague.
[...] The default options for the i386 compiler is to target the Pentium 
CPU, which does not have SSE. This gives most compatibility and least 
performance, but that's what's appropriate for most users, because for 
most desktop applications, CPU speed is no longer an issue. Only very 
specific tasks, such as software 3D rendering need high CPU performance, 
and people doing that stuff, usually know very well their compiler 
options and how to enable support for modern instruction extensions for 
maximum performance. Of course, people coming from a Java background 
might not be used at all to having to do this kind of stuff, but it's 
really not that hard.


As stated I tried *ALL* of the FPU settings and received the same result or 
an "access violation", which I assumed meant my FPU did not support that 
feature set. I even tried to enable emulation, to see what the difference 
would be, but ppc386 said it was an invalid switch even though it lists it 
in the help output.


--
Sent from my Debian Linux laptop -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com
541-410-2760
Making computers work for you!

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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 22:24 schrieb "Sven Barth" :
>
> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
> > Hi,
> >
> > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
> >
> >> I think Jeppe wanted to add vector support. Though the question here is
> >> whether one wants to optimize/detect this at the AST level and convert
> >> that to implicit vectors or at the CSE level.
> >
> > I think the higher level you can do an optimization/simplification, the
> > higher you should do it. Otherwise the lower layers get really messy, as
> > they already are in some cases. Well, in general, we should up our
> > floating point game. For example if Nikolay's recent load-modify-store
> > optimization would work on floats, that would already a nice step
forward
> > in this case. ;) (Sorry for my ignorance, if it already works, missed
that
> > then.)
>
> I agree that we should improve that. Maybe we should also allow for more
> FPU type specific helper routines. Currently on i386 and x86_64 the x87
> FPU will be used even if -CfsseX is given and only Single/Double are
> used, cause the compiler defaults to Extended. If SSE isn't used that
> might make sense, but for SSE we should fall back to Double if we're
> only dealing with double, IMHO (and analogous for Single).

And you might notice that I had written this before I had discovered the
existence of the professorspecific inline nodes which I commented on below
that, so forgot what I wrote here aside from the fact that we should indeed
improve things regarding floating point ^^'

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:

On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:

Hi,

On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:


I think Jeppe wanted to add vector support. Though the question here is
whether one wants to optimize/detect this at the AST level and convert
that to implicit vectors or at the CSE level.

I think the higher level you can do an optimization/simplification, the
higher you should do it. Otherwise the lower layers get really messy, as
they already are in some cases. Well, in general, we should up our
floating point game. For example if Nikolay's recent load-modify-store
optimization would work on floats, that would already a nice step forward
in this case. ;) (Sorry for my ignorance, if it already works, missed that
then.)
No, it does not work for floats, yet, but feel free to add support for 
them as well :)

I agree that we should improve that. Maybe we should also allow for more
FPU type specific helper routines. Currently on i386 and x86_64 the x87
FPU will be used even if -CfsseX is given and only Single/Double are
used, cause the compiler defaults to Extended. If SSE isn't used that
might make sense, but for SSE we should fall back to Double if we're
only dealing with double, IMHO (and analogous for Single).


By the way: I think my commit today of a SSE Frac() implementation sped
up the framerate by a third on Win64 compared to the one without it :D

Cool, but shouldn't this be an inline node instead for real speed++...? ;)
I mean if Trunc() and Round() are...

Ah, right, hadn't seen that we do indeed have an inline node
implementation for x86. I should probably put that on the list then :D
Yes, we do. And we can, in fact, make similar ones for many routines in 
the math unit as well. In fact, it is on my todo list, but feel free to 
start working on it, if you have time, since I have also other things to 
do and I don't know when I'm going to even start this one :) Btw, the 
sincos() routine is also a good candidate for inlining, and so are the 
divmod routines and the min/max routines (they are a good candidate for 
using the cmov instruction on i686+). When we have these as inline, we 
can then even add optimization passes that convert calls to sin(x) and 
cos(x) that are close to each other with the same parameter and no side 
effects between them to sincos(), same for div and mod -> divmod, etc.


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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
> 
> On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
> 
>> I think Jeppe wanted to add vector support. Though the question here is
>> whether one wants to optimize/detect this at the AST level and convert
>> that to implicit vectors or at the CSE level.
> 
> I think the higher level you can do an optimization/simplification, the
> higher you should do it. Otherwise the lower layers get really messy, as
> they already are in some cases. Well, in general, we should up our
> floating point game. For example if Nikolay's recent load-modify-store
> optimization would work on floats, that would already a nice step forward
> in this case. ;) (Sorry for my ignorance, if it already works, missed that
> then.)

I agree that we should improve that. Maybe we should also allow for more
FPU type specific helper routines. Currently on i386 and x86_64 the x87
FPU will be used even if -CfsseX is given and only Single/Double are
used, cause the compiler defaults to Extended. If SSE isn't used that
might make sense, but for SSE we should fall back to Double if we're
only dealing with double, IMHO (and analogous for Single).

>> By the way: I think my commit today of a SSE Frac() implementation sped
>> up the framerate by a third on Win64 compared to the one without it :D
> 
> Cool, but shouldn't this be an inline node instead for real speed++...? ;)
> I mean if Trunc() and Round() are...

Ah, right, hadn't seen that we do indeed have an inline node
implementation for x86. I should probably put that on the list then :D

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:

> I think Jeppe wanted to add vector support. Though the question here is
> whether one wants to optimize/detect this at the AST level and convert
> that to implicit vectors or at the CSE level.

I think the higher level you can do an optimization/simplification, the
higher you should do it. Otherwise the lower layers get really messy, as
they already are in some cases. Well, in general, we should up our
floating point game. For example if Nikolay's recent load-modify-store
optimization would work on floats, that would already a nice step forward
in this case. ;) (Sorry for my ignorance, if it already works, missed that
then.)

> By the way: I think my commit today of a SSE Frac() implementation sped
> up the framerate by a third on Win64 compared to the one without it :D

Cool, but shouldn't this be an inline node instead for real speed++...? ;)
I mean if Trunc() and Round() are...

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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> >
> > I also tried -Oofastmath, but to no avail. (floor is still external, and
> > still double)
> 
> Floor is not declared as inline and even the Trunc()/Frac() intrinsics it
> uses wouldn't be inlined as they're assembler routines and FPC as of now
> doesn't inline assembler routines.

The inline might release some register pressure.

> Also if it's Double then all is well. Extended (the 80-bit one) is the
> problematic case.
> What system are you testing on?

My work laptop, win10/64.

I think it was win64 as target, so no extended. The compiler did list it in
options tho.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 16:39 schrieb "Karoly Balogh (Charlie/SGR)" <
char...@scenergy.dfmk.hu>:
>
> Hi,
>
> On Fri, 19 May 2017, Reimar Grabowski wrote:
>
> > Final: The render function takes about 90%, the cast-to-int about 5%. No
> > other interesting functions shown. So the missing time must be spent
> > doing floating point math and branching (ifs), as that's all the render
> > function does.
>
> Well, if I comment out the three additions where the ray is actually
> traced and the tex := line, it's actually 60fps on my macbook. But
> actually the real difference is made with the additions. If i comment out
> everything, but those 3 (4 in fact) additions are in still there, it's
> still slow.
>
> Which made me thinking. I think you can vectorize that quite easily, and
> use some packed SIMD instruction, maybe that will make a difference. C/C++
> has some compiler intrinsics for that. I can't remember from the top of my
> head if it's doable with FPC. Someone who feels like fiddling with this,
> might want to try some assembly magic there, if it's possible somehow...

I think Jeppe wanted to add vector support. Though the question here is
whether one wants to optimize/detect this at the AST level and convert that
to implicit vectors or at the CSE level.

By the way: I think my commit today of a SSE Frac() implementation sped up
the framerate by a third on Win64 compared to the one without it :D

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 15:29 schrieb "Marco van de Voort" :
>
> In our previous episode, Sven Barth via fpc-pascal said:
> >
> > You only compiled the program with SSE, but not the RTL. And to
completely
> > avoid the x87 FPU you additionally need to fiddle around with some
> > defines/code inside the compiler as well.
>
> Hmm. in addition to my earlier benchmarks, the RTL is compiled with full
> optimization opts. (-Opcoreavx2 -Cfavx2 -Cpcoreavx2 -O4)
>
> I also tried -Oofastmath, but to no avail. (floor is still external, and
> still double)

Floor is not declared as inline and even the Trunc()/Frac() intrinsics it
uses wouldn't be inlined as they're assembler routines and FPC as of now
doesn't inline assembler routines.
Also if it's Double then all is well. Extended (the 80-bit one) is the
problematic case.
What system are you testing on?

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 07:21 PM, Ryan Joseph wrote:
On May 19, 2017, at 8:01 AM, Jon Foster  
wrote:

You can find both versions in my GitHub account: 
https://github.com/jafcobend/fpcflop

Thanks again, I was finally able to get this complied. No idea why the 
inclusion of SDL 2 was crashing at that line.
If I remember right your crash was in the call to plot(). The SDL plot used 
pointers the non-SDL plot writes to a static global array. It would seem a 
logical assumption that the pointer weren't initialized appropriately.


--
Sent from my Debian Linux laptop
Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 19 May 2017, Reimar Grabowski wrote:

> Final: The render function takes about 90%, the cast-to-int about 5%. No
> other interesting functions shown. So the missing time must be spent
> doing floating point math and branching (ifs), as that's all the render
> function does.

Well, if I comment out the three additions where the ray is actually
traced and the tex := line, it's actually 60fps on my macbook. But
actually the real difference is made with the additions. If i comment out
everything, but those 3 (4 in fact) additions are in still there, it's
still slow.

Which made me thinking. I think you can vectorize that quite easily, and
use some packed SIMD instruction, maybe that will make a difference. C/C++
has some compiler intrinsics for that. I can't remember from the top of my
head if it's doable with FPC. Someone who feels like fiddling with this,
might want to try some assembly magic there, if it's possible somehow...

And actually, when looking at the generated code, it's a typical code
which suffers from the fact that FPC's SSA is switched off in loops right
now. So the registers are reused in a way, which are a recipe for a
pipeline stall, especially with SIMD, plus it has a few unnecessary moves.
So guess what. See my previous mail.

Charlie

(Ps: Yeah, talking about code generated with fastmath optimizations on,
and SSE3.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> 
> You only compiled the program with SSE, but not the RTL. And to completely
> avoid the x87 FPU you additionally need to fiddle around with some
> defines/code inside the compiler as well.

Hmm. in addition to my earlier benchmarks, the RTL is compiled with full
optimization opts. (-Opcoreavx2 -Cfavx2 -Cpcoreavx2 -O4)

I also tried -Oofastmath, but to no avail. (floor is still external, and
still double)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Mattias Gaertner]

On Fri, 19 May 2017 14:34:40 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:

>[...]
> Not the point, the point is, does javascript generate exceptions on division
> by zero by default?

No. It creates Infinity.

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Fri, 19 May 2017 12:32:17 +0100
Graeme Geldenhuys  wrote:

> And no, I don’t agree that this is a “special case”.
Doing lots of calculations in a tight loop is more or less a special case.
On the other hand I have written quite some code that doesn't do much else than 
computing lots of stuff the fastest way possible.

> It’s a g*d d*mn game engine I tried to implement.
Here I beg to differ. You tried to implement a game engine but that doesn't 
make it one (no offense intended).
Game engines never, ever, ever use the brute force approach unless it's trivial 
for your hardware to deal with.
Raycasting was used in Wolfenstein and then dropped. Doom already used BSPs 
which is completely different and way faster.
Looking at what the 'engine' does it should run on a phone but you need a high 
end rig to reach interactive frame rates.
But I get where you are coming from and you are IMHO not so wrong with that 
opinion.

> 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.
It's not explicitly stated but by hanging around on this list long enough I got 
the impression that for raw speed you should just go somewhere else. Maybe FPC 
can be fast if you know all the knobs and handles and how to push and turn them 
but I don't have to do that for other languages so it's just less hassle.
C/C++ and Java being the usual suspects. Im sure the FPC developers are not 
ignoring the performance differences to the aforementioned languages but you 
know that the team is small and other stuff is deemed more important which 
considering that not many people need that much performance is the right thing 
to do.

> As I mentioned, I'll profile the application under both FreeBSD and 
> Windows over the weekend and post my finds.
Just profiling doesn't give you much. Jon profiled on 32-bit with gprof and I 
did it on 64-bit with callgrind.
Findings: nearly all the time is spent in the render function, floor is slow 
(but it's in other languages, too).
Fast ASM-floor gives about 25% gain (8->10 fps), replacing floor by cast-to-int 
gains ~33% (8->12fps) [only compiled with -01 as all other optimizations crash 
in the map making procedure]. And it gives div-by-zero errors of course 
(dimLength).

Final: The render function takes about 90%, the cast-to-int about 5%. No other 
interesting functions shown. So the missing time must be spent doing floating 
point math and branching (ifs), as that's all the render function does.

> But as far as I'm concerned, 
> there is nothing wrong with the way the program has been implemented.
FWIW I think so, too.

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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 12:51 schrieb "Mattias Gaertner" :
>
> On Fri, 19 May 2017 10:54:25 +0200
> Sven Barth via fpc-pascal  wrote:
>
> >[...]
> > Even though FPC might use SSE for maths it will still use the x87 to
> > transfer floating values to/from function, especially if they take
Extended
> > as parameter/result.
>
> Can you elaborate on this?
> I thought on x64 does not have extended, so extended is double.

Only on Win64 cause Microsoft declared the x87 as deprecated there. All
other x86_64 OSes can happily make use of it and thus Extended is 80bit
there, thus resulting in the usage of the x87 instead of solely SSE.
(Note: you can also enable the x87 for Win64 per define when building the
compiler, but your mileage may vary...)

>
> > I did a test by disabling Extended on Linux x64 trunk compiler and RTL
and
> > it tripled the framerate from ~3 to ~10.
>
> And it works?

Yes, why shouldn't it? :)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 13:32 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-05-19 12:11, Nikolay Nikolov wrote:
>>
>> In FPC, if you want to use SSE and
>> avoid the x87 FPU, you have to compile with a specific compiler options
>> and forfeit the option for your executable to run on non-SSE capable
>> CPUs, because FPC generates native code. If you want to keep
>
>
> All good and well... Yes, we tried compiling the demo with SSE3
explicitly enabled. No performance increase! What did happen though is that
we got random crashes after a few seconds of the application running.

You only compiled the program with SSE, but not the RTL. And to completely
avoid the x87 FPU you additionally need to fiddle around with some
defines/code inside the compiler as well.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > Then maybe the original code was DESIGNED for gcc and/or java ?
> 
> Now you are taking the piss!
> 
> The code I worked from was JavaScript actually. I posted the link a 
> couple minutes ago. Translating the JavaScript code to Object Pascal was 
> a manual process that wasn't very hard. I also verified the Object 
> Pascal implementation against a C version somebody else ported long 
> before me.

Not the point, the point is, does javascript generate exceptions on division
by zero by default?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-19 13:14, Karoly Balogh (Charlie/SGR) wrote:

Ps: can someone direct me to the right code you are discussing?



 Forwarded Message 
Subject: Re: [fpc-pascal] FPC Graphics options?
Date: Fri, 12 May 2017 18:29:05 +0100
From: Graeme Geldenhuys <mk>
To: fpc-pascal@lists.freepascal.org

On 2017-05-12 17:24, Jon Foster wrote:
> I don't suppose you could post a link to the Lazarus forum 
discussion. I'm
> extremely curious and so far my hunting on the forum hasn't turned up 
anything.


Indeed, searching the Lazarus Forums is 99% luck, 1% relevant.

The start of the thread:
http://forum.lazarus.freepascal.org/index.php/topic,3.0.html


My Object Pascal version:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg235937.html#msg235937

My Java version:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236090.html#msg236090


JavaScript and C versions:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236352.html#msg236352


Improved JavaScript versions:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236356.html#msg236356



PLEASE NOTE:
   Many of the guys there did not pay attention to detail. The demo 
should run at an exact resolution, and the camera viewpoint should

be in the centre of the tunnel. Some versions posted by others, the
camera viewpoint is on the edge of the tunnel or at different 
resolutions. So when you do comparisons, make sure everything is exactly 
the same, otherwise you don't get accurate comparisons.

- [ END ]---


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-19 12:43, Marco van de Voort wrote:

Then maybe the original code was DESIGNED for gcc and/or java ?


Now you are taking the piss!

The code I worked from was JavaScript actually. I posted the link a 
couple minutes ago. Translating the JavaScript code to Object Pascal was 
a manual process that wasn't very hard. I also verified the Object 
Pascal implementation against a C version somebody else ported long 
before me.



Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> Bottom line is, with the exact same code, NO work-arounds is required 
> for GCC or Java!

Then maybe the original code was DESIGNED for gcc and/or java ? 

> So why must we have work-arounds for FPC? 

The language is different. E.g. I get crashes too, but they are floating
point divide by zeros that FPC traps, but other languages often not (but
with corrupt results)

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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Jon Foster said:
> 
> I read that some were having trouble compiling Graeme's code because of SDL 
> version differences so I stripped out the SDL code and replaced the timing 
> function with traditional time/now calls. I then realized I still had Kylix 
> buried in some recess of all these excess terabytes and thought I'd see 
> what happens if I compiled the code with that. So I went through another 
> set of changes taking out all of the neat FPC C style operators and 
> returning them to the traditional ones. And put "inline" declarations and 
> other useful FPC defines in ifdefs. I then back ported all of those changes 
> into the SDL enabled code just to make sure it still rendered accurately.

Probably it needs to turn of FPU exceptions also, sometimes I a lot of floating
point division by zero

I ran the mctest a few times with different parameters:

i386:
just compile : 7.9   (both 3.0.2 and 3.1.1)
  -O4  3.0.2: 8.2   3.1.1: 8.1
-O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 3.0.2 8.35   3.1.1 : 12.1 


x64: only 3.1.1, sometimes divide by zero (have to set exception mask?)
just compile 13.9
-O4   :  19.5 
-O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 : 19.1

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-19 12:11, Nikolay Nikolov wrote:

In FPC, if you want to use SSE and
avoid the x87 FPU, you have to compile with a specific compiler options
and forfeit the option for your executable to run on non-SSE capable
CPUs, because FPC generates native code. If you want to keep


All good and well... Yes, we tried compiling the demo with SSE3 
explicitly enabled. No performance increase! What did happen though is 
that we got random crashes after a few seconds of the application running.


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.


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.


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.


Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-19 12:16, Graeme Geldenhuys wrote:

The JavaScript version runs very smooth on my system.


ps:
  And it doesn't use WebGL either. Simply blitting of a
  memory image to the canvas.


Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/19/2017 02:11 PM, Nikolay Nikolov wrote:



On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others 
are floating point division? How does Java handle this so much better 
than FPC and what are the work arounds? Just curious. As it stands I 
can only reason that I need to avoid dividing floats in FPC like the 
plague.
Java is a JVM, which generates bytecode, which isn't CPU specific and 
comes with a JIT compiler, which compiles the bytecode to native code, 
when the program is run, so it can always make use of the instruction 
set, supported by the CPU you're using. But, of course, launching the 
application becomes much slower. In FPC, if you want to use SSE and 
avoid the x87 FPU, you have to compile with a specific compiler 
options and forfeit the option for your executable to run on non-SSE 
capable CPUs, because FPC generates native code. If you want to keep 
compatibility and support modern instruction set extensions, you need 
to compile different executables for different instruction sets and 
make a launcher .exe, which detects the CPU type and runs the 
appropriate executable. The default options for the i386 compiler is 
to target the Pentium CPU, which does not have SSE. This gives most 
compatibility and least performance, but that's what's appropriate for 
most users, because for most desktop applications, CPU speed is no 
longer an issue. Only very specific tasks, such as software 3D 
rendering need high CPU performance, and people doing that stuff, 
usually know very well their compiler options and how to enable 
support for modern instruction extensions for maximum performance. Of 
course, people coming from a Java background might not be used at all 
to having to do this kind of stuff, but it's really not that hard.
With all that said, I'm not saying that FPC still doesn't have room for 
optimization, only the difference shown shouldn't be this huge, if you 
use the capabilities of modern CPUs. fpc_frac_real is slow on modern 
CPUs, because it uses slow x87 code, instead of SSE. FPC_DIV_INT64 is 
slow, because it does 64-bit division on 32-bit CPUs, using an algorithm 
that does use only 32-bit instructions. The fact that this procedure is 
a bottleneck in your code means that your code will benefit immensely if 
compiled for x86_64, which has a native 64-bit division instruction.


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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 16:33, Reimar Grabowski wrote:

and JS is clearly not faster than FPC.


The JavaScript version runs very smooth on my system. There is no 
framerate counter though, so I don't know how much faster.


   http://jsdo.it/notch/dB1E

Again, what does that say about FPC generated binary performance.

Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/19/2017 03:54 AM, Ryan Joseph wrote:

On May 18, 2017, at 10:40 PM, Jon Foster  wrote:

62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others are 
floating point division? How does Java handle this so much better than FPC and 
what are the work arounds? Just curious. As it stands I can only reason that I 
need to avoid dividing floats in FPC like the plague.
Java is a JVM, which generates bytecode, which isn't CPU specific and 
comes with a JIT compiler, which compiles the bytecode to native code, 
when the program is run, so it can always make use of the instruction 
set, supported by the CPU you're using. But, of course, launching the 
application becomes much slower. In FPC, if you want to use SSE and 
avoid the x87 FPU, you have to compile with a specific compiler options 
and forfeit the option for your executable to run on non-SSE capable 
CPUs, because FPC generates native code. If you want to keep 
compatibility and support modern instruction set extensions, you need to 
compile different executables for different instruction sets and make a 
launcher .exe, which detects the CPU type and runs the appropriate 
executable. The default options for the i386 compiler is to target the 
Pentium CPU, which does not have SSE. This gives most compatibility and 
least performance, but that's what's appropriate for most users, because 
for most desktop applications, CPU speed is no longer an issue. Only 
very specific tasks, such as software 3D rendering need high CPU 
performance, and people doing that stuff, usually know very well their 
compiler options and how to enable support for modern instruction 
extensions for maximum performance. Of course, people coming from a Java 
background might not be used at all to having to do this kind of stuff, 
but it's really not that hard.


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

Re: [fpc-pascal] FPC Graphics options?

[Mattias Gaertner]

On Fri, 19 May 2017 10:54:25 +0200
Sven Barth via fpc-pascal  wrote:

>[...]
> Even though FPC might use SSE for maths it will still use the x87 to
> transfer floating values to/from function, especially if they take Extended
> as parameter/result.

Can you elaborate on this?
I thought on x64 does not have extended, so extended is double.

 
> I did a test by disabling Extended on Linux x64 trunk compiler and RTL and
> it tripled the framerate from ~3 to ~10.

And it works?

 
> Additionally some internal functions are not yet available with sole SSE
> support (frac() indeed comes to mind).

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-19 06:58, Florian Klämpfl wrote:

Over the weekend I’ll verify by testing on both FreeBSD and Windows, and
then see if “calling conventions” make any difference.


*BSD is the same as Linux.


Good to know, thanks.



It has its purposes, but it is not suitable for the main repository of FPC.


It is not a technical thing but just a matter of mind. ;-)




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 19.05.2017 03:30 schrieb "Ryan Joseph" :
>
>
> > On May 19, 2017, at 3:48 AM, Florian Klämpfl 
wrote:
> >
> > Well, the reason are the linux calling conventions: there are no callee
saved xmm registers. This
> > means FPC does not use any single/double register variables. I have
some prototype fixes in my local
> > git mirror, but they are neither finished nor tested.
>
> Can you please explain how do calling conventions affect this? I failed
to run this at all on my Mac but I’m not sure why and even more confused
how this would decimate speeds like this.

Even though FPC might use SSE for maths it will still use the x87 to
transfer floating values to/from function, especially if they take Extended
as parameter/result.

I did a test by disabling Extended on Linux x64 trunk compiler and RTL and
it tripled the framerate from ~3 to ~10.

Additionally some internal functions are not yet available with sole SSE
support (frac() indeed comes to mind).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 18. Mai 2017 11:59:30 nachm. schrieb Graeme Geldenhuys
:

> On 2017-05-18 21:48, Florian Klämpfl wrote:
>>
>> Well, the reason are the linux calling conventions:
>
> Not sure if it makes any difference, but I was testing under 64-bit
> FreeBSD. I believe on the Lazarus Forum, some folk were using Linux and
> some on Windows.
>
> Over the weekend I’ll verify by testing on both FreeBSD and Windows, and
> then see if “calling conventions” make any difference.

*BSD is the same as Linux.

>
>
>
>> I have some prototype fixes in my local
>> git mirror, but they are neither finished nor tested.
>
> What I took away from that is You are using Git! ;-)

It has its purposes, but it is not suitable for the main repository of FPC.
And actually, if I had not used git, the patches would be already in trunk
because I would be forced to clean up my working copy. With git I just
commit unfinished stuff to a branch and forget about it. It is not a
technical thing but just a matter of mind :-)

>
>
>
> Regards,
>Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 19, 2017, at 8:01 AM, Jon Foster  wrote:
> 
> You can find both versions in my GitHub account: 
> https://github.com/jafcobend/fpcflop

Thanks again, I was finally able to get this complied. No idea why the 
inclusion of SDL 2 was crashing at that line.

The profiler on Mac seems to be incomplete and is telling me 23% in Floor and 
3.8% in FPC_DIV_INT64 which is not what you’re getting. If I remove floor I 
don’t get any more interesting information from it besides FPC_DIV_INT64.

with floor:

Seconds: 11.66   fps: 8.6

without floor (replaced to trunc):

Seconds: 9.34   fps: 10.7

replacing sin+cos with sincos added 2 fps but that’s not really the issue here. 
Your profiling says FPC barfed with the math and I’d like to know why.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 19, 2017, at 3:48 AM, Florian Klämpfl  wrote:
> 
> Well, the reason are the linux calling conventions: there are no callee saved 
> xmm registers. This
> means FPC does not use any single/double register variables. I have some 
> prototype fixes in my local
> git mirror, but they are neither finished nor tested.

Can you please explain how do calling conventions affect this? I failed to run 
this at all on my Mac but I’m not sure why and even more confused how this 
would decimate speeds like this.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 10:40 PM, Jon Foster  
> wrote:
> 
> 62.44  1.33 1.33 fpc_frac_real
> 26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
> 10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others are 
floating point division? How does Java handle this so much better than FPC and 
what are the work arounds? Just curious. As it stands I can only reason that I 
need to avoid dividing floats in FPC like the plague.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 08:56 AM, Reimar Grabowski wrote:

On Thu, 18 May 2017 08:40:43 -0700
Jon Foster  wrote:


I limited run time to 10secs, and used "time" to verify actual run time.
Here are the results, time output listed first and the first section of the
gprof output without comments:

A little of topic but did gprof just work like it used to?
I remember last time I tried to profile with gprof I could not get it to work 
and even asked about this on this list and was suggested alternatives.
Has there been something fixed or is it by chance that it works?
It just worked for me. I'm using FPC 3.0.0 with gprof 2.22. Probably an 
older version as I'm still running Debian 7 32bit. If it hadn't just worked 
I wouldn't have been able to post anything more useful in a timely fashion.

The code that is slow appears to be all standard floating point and integer
math

AFAIK floating point math is done using the extended type (as the gprof output 
shows) and there are no optimizations for single or double.
Correct me if I am wrong.



I read that some were having trouble compiling Graeme's code because of SDL 
version differences so I stripped out the SDL code and replaced the timing 
function with traditional time/now calls. I then realized I still had Kylix 
buried in some recess of all these excess terabytes and thought I'd see 
what happens if I compiled the code with that. So I went through another 
set of changes taking out all of the neat FPC C style operators and 
returning them to the traditional ones. And put "inline" declarations and 
other useful FPC defines in ifdefs. I then back ported all of those changes 
into the SDL enabled code just to make sure it still rendered accurately.


You can find both versions in my GitHub account: 
https://github.com/jafcobend/fpcflop


Graeme, I assume you don't mind me reposting that code on GuitHub? If so I 
can take it down.


The headless code when compiled with "fpc -XXs -O3" on my 32bit Linux box 
produces the preset 100 frames in about 32secs, a tad over 3fps. When 
compiled with "dcc" (Kylix v3) using whatever its default optimizations are 
and losing the FPC inlining, runs just slightly faster averaging 29sec for 
the 100 frame runs. Not much better, but not worse either. Kind of thought 
that loss of inlining would have hurt more. Or maybe it does and that's why 
it didn't do much better.--


--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 21:48, Florian Klämpfl wrote:


Well, the reason are the linux calling conventions:


Not sure if it makes any difference, but I was testing under 64-bit 
FreeBSD. I believe on the Lazarus Forum, some folk were using Linux and 
some on Windows.


Over the weekend I’ll verify by testing on both FreeBSD and Windows, and 
then see if “calling conventions” make any difference.





I have some prototype fixes in my local
git mirror, but they are neither finished nor tested.


What I took away from that is You are using Git! ;-)



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 18.05.2017 um 16:00 schrieb Ryan Joseph:
> 
>> On May 18, 2017, at 8:53 PM, Michael Van Canneyt  
>> wrote:
>> 
>> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
>> an equivalent
>> raytracer in Java. All the rest are diversions from the original subject.
> 
> That’s right. I’d really like to know what the hell FPC is doing to make it 
> so slow (besides the
> call to Floor()).

Well, the reason are the linux calling conventions: there are no callee saved 
xmm registers. This
means FPC does not use any single/double register variables. I have some 
prototype fixes in my local
git mirror, but they are neither finished nor tested.

> The compiler team should be worried about this also I would think.

I am not worried, the code on windows is reasonable good as windows has well 
designed calling
conventions making life for a compiler much easier :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 14:45, nore...@z505.com wrote:

When I toyed around with Andorra3D it had some concept/code for a
Camera, but he may have added it with his own code


He must have done it himself. Reimar is correct, OpenGL doesn't have a 
Camera object/view. But in tutorials and texts they often use the 
"concept of a camera" to describe how to set up a scene - that seems to 
give many the false sense that OpenGL has a "camera". It doesn't. :)


Regards,
  Graeme


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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 17:07:47 +0200 (CEST)
Michael Van Canneyt  wrote:

> Giving people advice that they should use perl instead of FPC for math is 
> simply insulting.
But Python is ok?

Btw. everyone knows that you do your math in C if you do Python or Perl.

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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > I was extremely curious to see if those calls to Floor() were causing it.
> 
>  From memory, I remember trying replacing Floor() with Frac() and even 
> Trunc(), and neither made any difference in the speed.
> 
> So I don't believe it is simply down to the Floor() usage.

FPC/Delphi do high precision rounding. A lot of Delphi gaming uses simple
assembler instructions for rounding.

Note that the profiling from Jon also shows that all targets should be
forced to the same architecture (since 64-bit division seems to be a RDS)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 08:40:43 -0700
Jon Foster  wrote:

> I limited run time to 10secs, and used "time" to verify actual run time. 
> Here are the results, time output listed first and the first section of the 
> gprof output without comments:
A little of topic but did gprof just work like it used to?
I remember last time I tried to profile with gprof I could not get it to work 
and even asked about this on this list and was suggested alternatives.
Has there been something fixed or is it by chance that it works?

> The code that is slow appears to be all standard floating point and integer 
> math
AFAIK floating point math is done using the extended type (as the gprof output 
shows) and there are no optimizations for single or double.
Correct me if I am wrong.

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 15:28, Ryan Joseph wrote:

I was extremely curious to see if those calls to Floor() were causing it.


From memory, I remember trying replacing Floor() with Frac() and even 
Trunc(), and neither made any difference in the speed.


So I don't believe it is simply down to the Floor() usage.

Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Brian]

Ryan Joseph wrote
>> On May 18, 2017, at 9:19 PM, Reimar Grabowski 

> reimgrab@

>  wrote:
>> 
>> By getting the source of Graemes test, using a profiler on it and having
>> a look at the results?
> 
> I tried (had to change the code to support SDL 2 even) but gave up after
> it crashed on one line. Graeme suggested a staggering difference in
> performance and I was extremely curious to see if those calls to Floor()
> were causing it. Hopefully this was a red herring and FPC isn’t as bad as
> the test suggests.
> 
> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  

> fpc-pascal@.freepascal

> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

You must treat SDL2.0 as a single threaded library. You can open a window in
any thread , but whichever thread in which you create the window , all
subsequent function calls to SDL2.0 must be made from within that thread ,
including events otherwise strange behavior or crashes will ensue.

Brian



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/FPC-Graphics-options-tp5728513p5728697.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 17:06:39 +0200 (CEST)
Michael Van Canneyt  wrote:

> And here I was thinking that math is what computers are for... :/
Back in the day, yes.
But nowadays computers do strings.

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

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done 
> > differently and then FPC is fast.
> 
> Asking honestly, so you don?t think there?s anything troubling about a 8
> fps vs 40 fps from the same code? 

No, since this is not a general trend, but similar extremes are known.

If it is floating point, then the floating point exception regime of FPC
might have to do with it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 07:19 AM, Reimar Grabowski wrote:

On Thu, 18 May 2017 20:32:57 +0700
Ryan Joseph  wrote:


On May 18, 2017, at 8:23 PM, Graeme Geldenhuys  
wrote:

The compiler must be doing something really stupid for it mess up like that but 
how can we know?

By getting the source of Graemes test, using a profiler on it and having a look 
at the results?

I compiled Graeme's code which was surprisingly easy. I guess I already had 
SDL installed with the dev files. FPC on my old 2GHz Intel gets 2fps. With 
Java (OpenJDK 1.6.x) I get a pretty steady 14fps. On my 3yr notebook with a 
1.9GHz Intel I get 4fps for FPC and 18fps for Java. I find it amusing the 
slower chip is faster. But there has been significant hardware improvements 
over the years.


I would have provided the fps for C++ but I haven't figured out how to get 
it to render the same content. It was doing half the resolution. I upped 
the window size which was obvious but it appears to be magnifying the same 
low pixel count. I've got to get back to work so I'll have to stop fiddling 
with this.


Both devices are multi-core Intel processors, obviously two different 
families, running 32bit Linux with Xorg for the display. FPC is version 
3.0.0. For the benchmark runs I used "-XXs -O3" for compiler switches.


I limited run time to 10secs, and used "time" to verify actual run time. 
Here are the results, time output listed first and the first section of the 
gprof output without comments:


10.05user 0.01system 0:10.11elapsed 99%CPU (0avgtext+0avgdata 9188maxresident)k
0inputs+272outputs (0major+1010minor)pagefaults 0swaps

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls  Ts/call  Ts/call  name
 62.44  1.33 1.33 fpc_frac_real
 26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
 10.33  2.12 0.22 FPC_DIV_INT64
  0.47  2.13 0.01 SYSTEM_$$_GENRAND_MT19937$$LONGINT
  0.00  2.13 0.00   43 0.00 0.00 P$TEST_$$_RENDER
  0.00  2.13 0.008 0.00 0.00 
P$TEST_$$_INTTOSTR$LONGINT$$ANSISTRING

  0.00  2.13 0.001 0.00 0.00  P$TEST_$$_INIT
  0.00  2.13 0.001 0.00 0.00  main


The code that is slow appears to be all standard floating point and integer 
math (* / mod + - >> <<). All of the time is spent in the render() 
function's main loops (lines 191-282 inclusive). I might have missed 
something but I didn't see any function calls of any concern. I rem'd those 
lines out and my frame rate jumped to ~1200. Obviously all I saw was a 
black screen. But I wanted to eliminate the SDL calls from the suspect list 
and make sure I had targeted the right lines.


I'm convinced that its not the integer math from the benchmarks I published 
earlier. And I thought everyone used the FPU so  I never imagined there 
could be a significant speed difference with floating point. But this feels 
like the compiler is using software math instead of the FPU. I tried 
various -Cf... switches and either got the same results or "Access 
Violation". Even tried "-Ce" and the compiler said it was an invalid switch.


I suppose there could be something else I'm missing. Much more work to do 
to find the culprit.


Seems like the compiler team should be very interested in this. Fortunately 
I don't do much with floating point math or I'd probably be heading back to 
C/C++. Ugg. I can still churn through millions of web log lines in pretty 
quick order. :-D

--

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com
541-410-2760
Making computers work for you!

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 22:04:19 +0700
Ryan Joseph  wrote:

> > On May 18, 2017, at 9:58 PM, Reimar Grabowski  wrote:
> > 
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done 
> > differently and then FPC is fast.  
> 
> Asking honestly, so you don’t think there’s anything troubling about a 8 fps 
> vs 40 fps from the same code? After I looked at the code I didn't see 
> anything strange about it so 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. 

Honestly, if I would use FPC on a daily basis I would have profiled Graemes 
code the moment it came to my attention but I don't so ...
As my FPC use is currently only hobby I don't care as much.
But to be fair when I coded my little learning 3D OpenGL engine 15+ years ago 
with FPC, I was able to reach nearly the peak performance triangle throughput 
of my card so it was fast enough and nowadays even more calculations be can 
moved to the GPU.
And without joking you can do games in Python just fine if you use your GPU. 
You can do great stuff in the browser as well with WebGL and JS is clearly not 
faster than FPC.

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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

Please do and keep us informed if you don’t mind.


No problems, will do.

Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 10:05 PM, Graeme Geldenhuys 
>  wrote:
> 
> ps:
>  I might have a few days free soon (between jobs), then I might dig more into 
> this problem. Seeing that everybody is so keen to know.

Please do and keep us informed if you don’t mind. On Mac with ppcx64 the 
program crashed on the line:

plot( x, y, rgbmul( col, fxmul( br, round(ddist) ) ) );

or I would have done this myself this morning.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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.


Regards,
  Graeme
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, 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.

ps:
  I might have a few days free soon (between jobs), then I might dig 
more into this problem. Seeing that everybody is so keen to know.


I am, because I do care about speed.

Giving people advice that they should use perl instead of FPC for math is 
simply insulting.

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

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, Reimar Grabowski wrote:


On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph  wrote:


That’s right. I’d really like to know what the hell FPC is doing to make it so 
slow (besides the call to Floor()). The compiler team should be worried about 
this also I would think.


No, they should not.
It's no real world problem, just a test program. A real game would be done 
differently and then FPC is fast.
People don't do math on computers so raw calculation speed is not important.


And here I was thinking that math is what computers are for... :/

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

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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.

ps:
  I might have a few days free soon (between jobs), then I might dig 
more into this problem. Seeing that everybody is so keen to know.



Regards,
  Graeme

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

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 9:19 PM, Reimar Grabowski  wrote:
> 
> By getting the source of Graemes test, using a profiler on it and having a 
> look at the results?

I tried (had to change the code to support SDL 2 even) but gave up after it 
crashed on one line. Graeme suggested a staggering difference in performance 
and I was extremely curious to see if those calls to Floor() were causing it. 
Hopefully this was a red herring and FPC isn’t as bad as the test suggests.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph  wrote:

> That’s right. I’d really like to know what the hell FPC is doing to make it 
> so slow (besides the call to Floor()). The compiler team should be worried 
> about this also I would think.

No, they should not.
It's no real world problem, just a test program. A real game would be done 
differently and then FPC is fast.
People don't do math on computers so raw calculation speed is not important.
Compiler optimizations would be nice but are hard to do and the project has not 
enough contributors.
Being on many platforms doesn't make the task easier.

Long story short:
Wanne do PacMan in 160x100 resolution, no problem for FPC.
Wanne do something more modern, use something fast like Python or Perl.

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 15:53:46 +0200 (CEST)
Michael Van Canneyt  wrote:

> Yes, it was.
Don't tell me which mail I replied to, that's just rude.

> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
> an 
> equivalent raytracer in Java. All the rest are diversions from the original 
> subject.
Are you a moderator now?
Graeme never complaint about anything raytracing related. 
Could you at least try to understand the differences between raytracing and 
raycasting, please?
The original subject is about the CRT units. All the rest are diversions from 
the original subject.

I just wanted a little explanation from Marco about one of his sentences and I 
get you with lacking reading comprehension and impolite attitude.
Awesome.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 08:23, Graeme Geldenhuys wrote:

On 2017-05-18 13:42, Reimar Grabowski wrote:

The GPU also does clipping calculations
based on the viewpoint (camera position) in the 3D scene.

Camera position?
OpenGL has no concept of a camera.


Yes, yes, but you know what I mean. Camera, View Point, Player View
whatever. And yes I know there is no "real camera", its the scene that
moves in the opposite direction to the user input.



Why do you have to *calculate* *all*?


My original project was to implement a _software_ raycaster, so no
GPU, no OpenGL etc. Old old early 90's style programming.

This thread is getting a bit ridiculous - just like the Lazarus Forum
thread did. Bottom line is, the exact same code (identical, just the
language syntax that differed) produced acceptable results with GCC
and Java. It didn't with FPC. We all now know FPC doesn't do such a
great job at optimisation (I know the reasons why), and that the
graphics API's is also not to blame. So lets leave it at that.



No no you don't "leave" when you are trying to figure out a slow 
procedure that could be causing the problem, you stay here and find what 
is the bottlneck, then insert 3-234 lines of code to fix it so it's 
equal to the speed of x that you are comparing it to :-)


I just want to pinpoint why fpc is slow:
1.the math unit
2.nothing to do with the math unit
3.a wrapper around a graphics lib is slow, not the graphics lib itself 
just the wrapper in fpc

4. system.pp is slow
5. sysutils is slow
6.none of the above
7.magic (not an option. Leave thread..) ;-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 8:53 PM, Michael Van Canneyt  
> wrote:
> 
> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
> an equivalent raytracer in Java. All the rest are diversions from the 
> original subject.

That’s right. I’d really like to know what the hell FPC is doing to make it so 
slow (besides the call to Floor()). The compiler team should be worried about 
this also I would think.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 08:45:59 -0500
nore...@z505.com wrote:

> On 2017-05-18 07:42, Reimar Grabowski wrote:
> > Camera position?
> > OpenGL has no concept of a camera.  
> 
> When I toyed around with Andorra3D it had some concept/code for a 
> Camera, but he may have added it with his own code, not sure if he used 
> built in directx/opengl code
15+ years of OpenGL here and I can tell you it has no camera and never had one.

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 20:38:44 +0700
Ryan Joseph  wrote:

> I only have some game experience but it’s common to need to perform some sort 
> of viewport culling/sorting before you can send the data to OpenGL.
In general there is no sorting needed and culling is better done on mesh level 
than vertex level.
Culling can be really fast if you do it correctly and don't overdo it.
Sending everything you want to draw every frame is definitely wrong for most 
applications.

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 20:32:57 +0700
Ryan Joseph  wrote:

> > On May 18, 2017, at 8:23 PM, Graeme Geldenhuys 
> >  wrote:
> The compiler must be doing something really stupid for it mess up like that 
> but how can we know?
By getting the source of Graemes test, using a profiler on it and having a look 
at the results?

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 14:26:18 +0100
Graeme Geldenhuys  wrote:

> On 2017-05-18 14:21, Reimar Grabowski wrote:
> > Yes, I get that, but the interesting point is what does the profiler say?
> > Where are the bottlenecks?  
> 
> The full source code was posted in the Lazarus Forum (I supplied links 
> to those) - so knock yourself out.
Thanks but no thanks.
I thought you had at least tried to identify them as that's what I generally do 
when performance is sub par (for whatever language or project).

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 14:23:41 +0100
Graeme Geldenhuys  wrote:

> This thread is getting a bit ridiculous - just like the Lazarus Forum 
> thread did. Bottom line is, the exact same code (identical, just the 
> language syntax that differed) produced acceptable results with GCC and 
> Java. It didn't with FPC. We all now know FPC doesn't do such a great 
> job at optimisation (I know the reasons why), and that the graphics 
> API's is also not to blame.
This we know for years.
The bottlenecks would have been interesting to show if there could be something 
done to improve the situation. Just stating that it's slower doesn't help.

> So lets leave it at that.
Seems to be better.

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