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] Best way to check SimpleIPC for messages

[Michael Schnell]

On 17.05.2017 07:08, nore...@z505.com wrote:
 what happens when the application is not idle, but sort of idle? 


A new Queue event also only is serviced when no other previous events 
are peresent hence when the application gets "idle".


I don't know when exactly "OnIdle" is called. It can't be in a closed 
loop otherwise any application would always use 100% CPU.


Hence "OnIdle" is bound to work with an even greater latency than a 
decent queue entry like TThread.Queue or Application.QueueAsyncCall.


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

[fpc-pascal] Ignoring function results

[Mark Morgan Lloyd]

According to the Programmer's Guide 1.3.41, {$EXTENDEDSYNTAX OFF} has 
the effect of permitting the result of a function to be ignored.


However it also appears to (at least) prohibit functions/procedures with 
optional parameters: can these be controlled separately?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
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 64bit for windows

[Lukasz Sokol]

On 19/05/17 16:15, Sven Barth via fpc-pascal wrote:
> Am 19.05.2017 14:53 schrieb "Lukasz Sokol"
>  >:
>> 
>> On 19/05/17 13:33, Sven Barth via fpc-pascal wrote:
>> 
> You don't have to build a 32-bit FPC because an official 
> released installer exists. So this is no problem at all. But 
> seeing as pretty much everything is moving (or already has
> moved) to 64-bit, why bother with 32-bit these days.
> [referring to desktop and server applications - not embedded
> devices]
> 
 
 Is there a way for native 64bit application to load a 32bit 
 library, that then can talk to a 32bit USB driver ? (on
 Windows)
>>> 
>>> Drivers (at least kernel mode drivers) must be 64-bit on 64-bit 
>>> Windows (and also basically every other system I'm aware of).
>>> However it's perfectly possible to talk with a 64-bit driver from
>>> a 32-bit application. And no, you can't load a 32-library from a
>>> 64-bit process.
>> 
>> This one is not a kernel-mode (at least so I think because the
>> same installation succeeds both on 32bit XPSP3, and in recent Win10
>> 64bit)...
>> 
>> (it's the old old Microchip MCHPFUSB driver used e.g. with
>> PIC18F4550, driver version 1.3; it's probably not as much a
>> 'driver' as a way to register the PID and VID with the system, more
>> or less; but the library interfacing it, is 32bit only)
> 
> From what I can see from their site version 1.3 is the first that
> supports 64-bit and it indeed includes a 64-bit driver (and a 32-bit
> one as well). Also if I understand that correctly the source and API
> information to access the driver is provided as well, so you could
> either compile the library for 64-bit or port it to FPC to solve
> this.
> 

Thanks for diving into this :) even though you didn't have to.

Confirmed, the distribution of this driver I am using, 
does contain the 64bit .sys file... and the source code (made in Borland C)
for the .dll. They only provided precompiled 32bit dll by default though. 
At least in the download I currently use.

I will come back to this, when I have some time freed after the current 32bit
backend I am writing now, hits a certain milestone ;)

> Regards, Sven

Kind Regards
-L.

___
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 64bit for windows

[Sven Barth via fpc-pascal]

Am 19.05.2017 14:53 schrieb "Lukasz Sokol" :
>
> On 19/05/17 13:33, Sven Barth via fpc-pascal wrote:
>
> >>> You don't have to build a 32-bit FPC because an official
> >>> released installer exists. So this is no problem at all. But
> >>> seeing as pretty much everything is moving (or already has moved)
> >>> to 64-bit, why bother with 32-bit these days. [referring to
> >>> desktop and server applications - not embedded devices]
> >>>
> >>
> >> Is there a way for native 64bit application to load a 32bit
> >> library, that then can talk to a 32bit USB driver ? (on Windows)
> >
> > Drivers (at least kernel mode drivers) must be 64-bit on 64-bit
> > Windows (and also basically every other system I'm aware of). However
> > it's perfectly possible to talk with a 64-bit driver from a 32-bit
> > application. And no, you can't load a 32-library from a 64-bit
> > process.
>
> This one is not a kernel-mode (at least so I think because the same
> installation succeeds both on 32bit XPSP3, and in recent Win10 64bit)...
>
> (it's the old old Microchip MCHPFUSB driver used e.g. with PIC18F4550,
driver version 1.3;
>  it's probably not as much a 'driver' as a way to register the PID and
VID with the system,
>  more or less; but the library interfacing it, is 32bit only)

>From what I can see from their site version 1.3 is the first that supports
64-bit and it indeed includes a 64-bit driver (and a 32-bit one as well).
Also if I understand that correctly the source and API information to
access the driver is provided as well, so you could either compile the
library for 64-bit or port it to FPC to solve this.

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:16:28 +0100
Graeme Geldenhuys  wrote:

> Again, what does that say about FPC generated binary performance.
That we get a performance boost when we can compile FPC to JS?
You should try to compile graemecraft with FPC for the JVM, perhaps it boosts 
performance. ^^

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

Re: [fpc-pascal] FPC 64bit for windows

[Lukasz Sokol]

On 19/05/17 13:33, Sven Barth via fpc-pascal wrote:

>>> You don't have to build a 32-bit FPC because an official
>>> released installer exists. So this is no problem at all. But
>>> seeing as pretty much everything is moving (or already has moved)
>>> to 64-bit, why bother with 32-bit these days. [referring to
>>> desktop and server applications - not embedded devices]
>>> 
>> 
>> Is there a way for native 64bit application to load a 32bit
>> library, that then can talk to a 32bit USB driver ? (on Windows)
> 
> Drivers (at least kernel mode drivers) must be 64-bit on 64-bit
> Windows (and also basically every other system I'm aware of). However
> it's perfectly possible to talk with a 64-bit driver from a 32-bit
> application. And no, you can't load a 32-library from a 64-bit
> process.

This one is not a kernel-mode (at least so I think because the same
installation succeeds both on 32bit XPSP3, and in recent Win10 64bit)...

(it's the old old Microchip MCHPFUSB driver used e.g. with PIC18F4550, driver 
version 1.3;
 it's probably not as much a 'driver' as a way to register the PID and VID with 
the system,
 more or less; but the library interfacing it, is 32bit only)

-L.

> 
> Regards, Sven
> 
> 
> 
> ___ 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?

[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 64bit for windows

[Sven Barth via fpc-pascal]

Am 19.05.2017 13:54 schrieb "Lukasz Sokol" :
>
> On 19/05/17 11:15, Graeme Geldenhuys wrote:
> > On 2017-05-19 00:38, Nikolay Nikolov wrote:
> >> windows OS - there are simply no known issues with that under any
> >> 64-bit windows version that I know of. snip... It won't work
> >> from the IDE, though, but compiling your program from the command
> >> line, when you want to build a 64-bit .exe shouldn't be hard.
> >
> > So you are contradicting your self a bit. No known problems, and then
> > two paragraphs later... but there is this known problem with the IDE.
> > ;-)
> >
> >
> >> Because it is inferior, since it cannot build a 32-bit FPC.
> >
> > You don't have to build a 32-bit FPC because an official released
> > installer exists. So this is no problem at all. But seeing as pretty
> > much everything is moving (or already has moved) to 64-bit, why
> > bother with 32-bit these days. [referring to desktop and server
> > applications - not embedded devices]
> >
>
> Is there a way for native 64bit application to load a 32bit library,
> that then can talk to a 32bit USB driver ?
> (on Windows)

Drivers (at least kernel mode drivers) must be 64-bit on 64-bit Windows
(and also basically every other system I'm aware of).
However it's perfectly possible to talk with a 64-bit driver from a 32-bit
application.
And no, you can't load a 32-library from a 64-bit process.

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?

[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 
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 64bit for windows

[Lukasz Sokol]

On 19/05/17 11:15, Graeme Geldenhuys wrote:
> On 2017-05-19 00:38, Nikolay Nikolov wrote:
>> windows OS - there are simply no known issues with that under any
>> 64-bit windows version that I know of. snip... It won't work
>> from the IDE, though, but compiling your program from the command
>> line, when you want to build a 64-bit .exe shouldn't be hard.
> 
> So you are contradicting your self a bit. No known problems, and then
> two paragraphs later... but there is this known problem with the IDE.
> ;-)
> 
> 
>> Because it is inferior, since it cannot build a 32-bit FPC.
> 
> You don't have to build a 32-bit FPC because an official released
> installer exists. So this is no problem at all. But seeing as pretty
> much everything is moving (or already has moved) to 64-bit, why
> bother with 32-bit these days. [referring to desktop and server
> applications - not embedded devices]
> 

Is there a way for native 64bit application to load a 32bit library,
that then can talk to a 32bit USB driver ?
(on Windows)

-L.

> 
> 
> 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?

[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 64bit for windows

[Graeme Geldenhuys]

On 2017-05-18 23:14, James Richters wrote:

That would be very much appreciated,



  http://geldenhuys.co.uk/~graemeg/fpc-3.0.2-win64.7z

It's a 53MB download. It includes the 3.0.2 64-bit Windows compiler and 
source code, as well as the binutils and the go.bat batch file I used to 
compile the 3.0.2 version.


NOTE:
  Not quite ideal, but the fpc.cfg file is referencing the FPC locations
  as c:\lazarus\fpc\\
  So if you unpack this archive to any other location, please adjust the
  paths in the fpc.cfg file. For some reason the Windows VM I used
  installed FPC inside the c:\Lazarus directory. Normally I use c:\fpc\
  instead.

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 64bit for windows

[Graeme Geldenhuys]

On 2017-05-19 00:38, Nikolay Nikolov wrote:

windows OS - there are simply no known issues with that under any 64-bit
windows version that I know of.
snip...
It won't work from the
IDE, though, but compiling your program from the command line, when you
want to build a 64-bit .exe shouldn't be hard.


So you are contradicting your self a bit. No known problems, and then 
two paragraphs later... but there is this known problem with the IDE. ;-)




Because it is inferior, since it cannot build a 32-bit FPC.


You don't have to build a 32-bit FPC because an official released 
installer exists.
So this is no problem at all. But seeing as pretty much everything is 
moving (or already has moved) to 64-bit, why bother with 32-bit these 
days. [referring to desktop and server applications - not embedded devices]




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