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

[fpc-pascal] Browser and exe

[Marcos Douglas B. Santos]

Hi,

If you have some apps or components which was written in Object Pascal and
you would like to use them in Web applications (client-side, previously
installed) what is the best option to choose nowadays?

My users use Windows so, I thought in ActiveX. It works, but I think Chrome
do not use anymore, right?

Is there a way to call an Exe (previously installed, no problem with that)
to interact with an Exe, working in IE and Chrome?

Best regards,
Marcos Douglas
___
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-Pascal] FPC Graphics options?

[James Richters]

>I cannot reproduce it on my machine after the r714 fix. Can you send me a 
>small example program, that demonstrates the problem, as well as detailed 
>steps to reproduce?

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

This is just a little program I wrote to get the ascii codes real fast off 
either the console window or graphics window.  If I recall correctly, using the 
graph unit some of the F keys were different on the graph screen than they were 
in the console screen.   This makes a good sample because it shows that the 
graph screen is responding to the keyboard, just not with what is expected.  It 
also shows that the graphic window is still actually working as well.  To 
duplicate the issue, first show that everything works as expected by switching 
between the windows by clicking on them, type some keys in each window.  Esc 
exits the program, g, G, c, & C I use to test switching windows with windows 
api calls.  

To demonstrate the problem, while on the graphics window, use alt-tab from the 
graphics window to the console window,  the keys all work as expected in the 
console window, but then if you use any method to get back to the graphics 
window, they keys reported in the graphics window are no longer correct.   
While preparing this for you I noticed that the keys reported seem to be as if 
alt is being held down when it is not and strangely, if I hold down alt and 
hit any key at all,   from that point on,  the graphic screen reacts normally 
to keystrokes.  

I will admit that I get a bit confused when it comes to manipulating units and 
things, but I'm fairly certain that I implemented r175 correctly.
I removed all copies of ptcgraph from my compiler paths and make sure I got a 
compiler error for it being not found, then put the newly compiled r175 fix in 
and compiled it. You can see I fixed my sample program to use 
Windowtitle:=Graphtitle; and that is working, so that would seem to indicate 
that I am really running r175.   

Thank you for the help with this, it is very much appreciated

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?

[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-Pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/22/2017 02:21 AM, James Richters wrote:

I have the window title working, Thank you for that.
However I still have the same issue with non-responsive keyboard when I return 
to the graph window after an ALT-TAB.  I am running on windows 10 64bit - 
program compiled for win32.
I cannot reproduce it on my machine after the r714 fix. Can you send me 
a small example program, that demonstrates the problem, as well as 
detailed steps to reproduce?


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?

[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