Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 3:35 PM, Benito van der Zander via fpc-pascal 
>  wrote:
> 
> But it is not calling the method, it is calling the wrapper function

what you say wrapper function do you mean the ref counting functions when you 
pass around the interface?

I guess for ref counting you're supposed to cast the class to the interface 
(which is an expensive runtime lookup) and then pass that thing around? That 
seems like a crazy way to get ref counting plus you need to cast the interface 
back to the class if you want to call other methods? I still don't get this 
pattern. ARC should be handled by the compiler and be on the class itself, not 
some additional object you need to create and then store. 

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 2:43 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> FPC currently does not yet support class types not to mention records and 
> objects which is what I had mentioned earlier already.

Yes I see this on https://freepascal.org/docs-html/ref/refse47.html. Why isn't 
this supported? I guess as part of this proposal we need to implement this 
feature as well?  I'm not familiar with this area of the language so I'm not 
sure what this entails.

> 
>> It's a strange syntax compared to anything else we allow in classes and the 
>> boiler plate is really adding up now. "procedure Draw" is going to be in 4 
>> lines now!
>> 
>> It would be nicer if they made this into one line so we don't have yet 
>> another set of duplicate method signatures, i.e.:
>> 
>>   procedure Draw as ICircle.Draw;
> 
> I can't shake the feeling that all you complain about is writing even a 
> little bit too much. Pascal is *not* about using as less code as possible, 
> but to be as correct as possible and the syntax of interface delegation 
> allows exactly that.

Being too verbose is clunky in my opinion. That method resolution syntax is 
just kind of an odd addition for classes to my eyes. "procedure Type.Name = 
Name;" doesn't have any precedence inside classes/records so it stands out.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Benito van der Zander via fpc-pascal]

Hi,


And there often is a lot of unintentional deep copying. This is also 
why a property returning a record is fairly useless except for 
extremely small records like TPoint (and even that is not optimal no 


But a managed record to replace an interface, would only contain a 
single pointer/class ref. That can be copied fast




Bye,
Benito
On 16.02.21 21:49, Marco van de Voort via fpc-pascal wrote:


Op 2021-02-16 om 21:33 schreef Ryan Joseph via fpc-pascal:


On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal 
 wrote:


And there often is a lot of unintentional deep copying. This is also 
why a property returning a record is fairly useless except for 
extremely small records like TPoint (and even that is not optimal no
deep copying? You mean from ref counted types like "array of" and 
ansistring?


No, use of TP objects and records in e.g. properties in not carefully 
crafted code. They are a lot less userfriendly.



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

Re: [fpc-pascal] Traits Proposal

[Sven Barth via fpc-pascal]

Benito van der Zander via fpc-pascal 
schrieb am Di., 16. Feb. 2021, 23:35:

> Interfaces are not slow because they are are interfaces! When you call a
> interface method it has the same costs as a virtual method call! And the
> cost for reference counting that interfaces have right now would be there
> for ARC as well.
>
>
> But it is not calling the method, it is calling the wrapper function
>
> That is a additional second method call/jump for every interface method
> call.
>
>
> E.g. _AddRef on TInterfacedObject as an interface, does not call
> TInterfacedObject._AddRef, it calls this:
> WRPR_$SYSTEM_$$_TINTERFACEDOBJECT_$_IUNKNOWN_$_1_$_SYSTEM$_$TINTERFACEDOBJECT_$__$$__ADDREF$$LONGINT
>
> 00424600 4883ef10 sub$0x10,%rdi
> 00424604 e997f8feff   jmpq   0x413ea0
> 
>

It's an *unconditional* jump. The branch prediction of the CPU should
handle this without much penalty.

Regards,
Sven

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

Re: [fpc-pascal] Traits Proposal

[Benito van der Zander via fpc-pascal]

Hi,

If you need to create 1000 class instances each frame then you have a 
flaw in your logic in my opinion.



I have more like a million class instances

For my XPath stuff, and every returned value is put in a variant-like 
class. Selecting all nodes on an GB large XML, could even create almost 
a billion class instances



I once did a benchmark. It is 10% faster to reuse the class instances 
rather than recreating them, my commit log says. And I only implemented 
one interface (actually, two interfaces, since IUnknown always gets 
pulled in, too. )



Interfaces are not slow because they are are interfaces! When you call 
a interface method it has the same costs as a virtual method call! And 
the cost for reference counting that interfaces have right now would 
be there for ARC as well.



But it is not calling the method, it is calling the wrapper function

That is a additional second method call/jump for every interface method 
call.



E.g. _AddRef on TInterfacedObject as an interface, does not call 
TInterfacedObject._AddRef, it calls this:


WRPR_$SYSTEM_$$_TINTERFACEDOBJECT_$_IUNKNOWN_$_1_$_SYSTEM$_$TINTERFACEDOBJECT_$__$$__ADDREF$$LONGINT 


00424600 4883ef10 sub    $0x10,%rdi
00424604 e997f8feff   jmpq   0x413ea0 




Bye,
Benito
On 16.02.21 19:48, Sven Barth via fpc-pascal wrote:
Ryan Joseph via fpc-pascal > schrieb am Di., 16. Feb. 
2021, 19:21:


>
> There we have:
>
> * slower creation of the class, because each implemented
interface adds another VMT reference to the class which needs to
be initialized.

How bad is this? We need to make a test case we can profile. For
example if you have a game that creates 1000 classes 60 frames per
second. If adding interfaces to the classes hurts this process we
may have a deal breaker.


If you need to create 1000 class instances each frame then you have a 
flaw in your logic in my opinion.



> * slow reference counting. Especially if it is thread safe and
exception safe with the implicit exception block

It's a whole other topic but FPC needs opt-in ARC at the language
level for classes. Interfaces are not only slow but then you need
to pass around a reference to the interface instead of the class
you actually care about. It makes no sense to me whatsoever.


Interfaces are not slow because they are are interfaces! When you call 
a interface method it has the same costs as a virtual method call! And 
the cost for reference counting that interfaces have right now would 
be there for ARC as well.


Regards,
Sven


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

Re: [fpc-pascal] Traits Proposal

[Sven Barth via fpc-pascal]

Am 16.02.2021 um 19:53 schrieb Ryan Joseph via fpc-pascal:



On Feb 16, 2021, at 11:44 AM, Sven Barth  wrote:

I wasn't saying anything that contradicts this, only that the original 
mechanism of the delegation will be available even with the default modifier 
and this mechanism will in fact be necessary to access them through RTTI.


Can you give an example of this syntax? I get errors like Interface "ICircle" cannot be 
delegated by "TMyShape", it already has method resolutions.


FPC currently does not yet support class types not to mention records 
and objects which is what I had mentioned earlier already.



It's a strange syntax compared to anything else we allow in classes and the boiler plate 
is really adding up now. "procedure Draw" is going to be in 4 lines now!

It would be nicer if they made this into one line so we don't have yet another 
set of duplicate method signatures, i.e.:

   procedure Draw as ICircle.Draw;


I can't shake the feeling that all you complain about is writing even a 
little bit too much. Pascal is *not* about using as less code as 
possible, but to be as correct as possible and the syntax of interface 
delegation allows exactly that.


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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-16 om 21:33 schreef Ryan Joseph via fpc-pascal:



On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal 
 wrote:

And there often is a lot of unintentional deep copying. This is also why a 
property returning a record is fairly useless except for extremely small 
records like TPoint (and even that is not optimal no

deep copying? You mean from ref counted types like "array of" and ansistring?


No, use of TP objects and records in e.g. properties in not carefully 
crafted code. They are a lot less userfriendly.



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

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal 
>  wrote:
> 
> And there often is a lot of unintentional deep copying. This is also why a 
> property returning a record is fairly useless except for extremely small 
> records like TPoint (and even that is not optimal no

deep copying? You mean from ref counted types like "array of" and ansistring?

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-16 om 19:21 schreef Ryan Joseph via fpc-pascal:

Interfaces are extremely slow. Virtual method calls are also slow. I have been 
using interfaces for reference counting, and have been thinking to replace it 
all with managed records because they are so slow (unfortunately records can 
also be slow because fpc does not always keep them in registers even if they 
are pointer sized)


And there often is a lot of unintentional deep copying. This is also why 
a property returning a record is fairly useless except for extremely 
small records like TPoint (and even that is not optimal no



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

Re: [fpc-pascal] Traits Proposal

[Ralf Quint via fpc-pascal]

On 2/16/2021 10:48 AM, Sven Barth via fpc-pascal wrote:
Ryan Joseph via fpc-pascal > schrieb am Di., 16. Feb. 
2021, 19:21:


>
> There we have:
>
> * slower creation of the class, because each implemented
interface adds another VMT reference to the class which needs to
be initialized.

How bad is this? We need to make a test case we can profile. For
example if you have a game that creates 1000 classes 60 frames per
second. If adding interfaces to the classes hurts this process we
may have a deal breaker.


If you need to create 1000 class instances each frame then you have a 
flaw in your logic in my opinion.


Yup, that would be a deal breaker right from the get go...

Ralf




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 11:48 AM, Sven Barth  wrote:
> 
> If you need to create 1000 class instances each frame then you have a flaw in 
> your logic in my opinion. 
> 

You can reuse classes and reset fields but getting a new piece of memory could 
be faster. These things do happen and adding on class allocation performance 
penalties could be a problem. I need to profile first to know what we're 
talking about here.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 11:44 AM, Sven Barth  wrote:
> 
> I wasn't saying anything that contradicts this, only that the original 
> mechanism of the delegation will be available even with the default modifier 
> and this mechanism will in fact be necessary to access them through RTTI. 
> 

Can you give an example of this syntax? I get errors like Interface "ICircle" 
cannot be delegated by "TMyShape", it already has method resolutions.


It's a strange syntax compared to anything else we allow in classes and the 
boiler plate is really adding up now. "procedure Draw" is going to be in 4 
lines now!

It would be nicer if they made this into one line so we don't have yet another 
set of duplicate method signatures, i.e.:

  procedure Draw as ICircle.Draw;


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Sven Barth via fpc-pascal]

Ryan Joseph via fpc-pascal  schrieb am
Di., 16. Feb. 2021, 19:21:

> >
> > There we have:
> >
> > * slower creation of the class, because each implemented interface adds
> another VMT reference to the class which needs to be initialized.
>
> How bad is this? We need to make a test case we can profile. For example
> if you have a game that creates 1000 classes 60 frames per second. If
> adding interfaces to the classes hurts this process we may have a deal
> breaker.
>

If you need to create 1000 class instances each frame then you have a flaw
in your logic in my opinion.


> > * slow reference counting. Especially if it is thread safe and exception
> safe with the implicit exception block
>
> It's a whole other topic but FPC needs opt-in ARC at the language level
> for classes. Interfaces are not only slow but then you need to pass around
> a reference to the interface instead of the class you actually care about.
> It makes no sense to me whatsoever.
>

Interfaces are not slow because they are are interfaces! When you call a
interface method it has the same costs as a virtual method call! And the
cost for reference counting that interfaces have right now would be there
for ARC as well.

Regards,
Sven

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

Re: [fpc-pascal] Traits Proposal

[Sven Barth via fpc-pascal]

Ryan Joseph via fpc-pascal  schrieb am
Di., 16. Feb. 2021, 19:22:

>
>
> > On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Again, the point of the interface would be to control which methods and
> properties of the delegated  type would be available. Also it would allow
> for seamless integration with the RTTI as it's possible to query the
> implemented interface of a class and to retrieve a reference to it, thus it
> would be possible to access this at runtime as well.
> >
> > The compiler will generate a VMT for the interface with method thunks
> that adjust the Self pointer so that it works correctly. The
> GetInterfaceByEntry function uses this static data to generate an adjusted
> Self value that callers can use.
>
> As far as the "default implements property" is concerned we don't actually
> need, or even want to utilize the interfaces themselves. The idea of
> leveraging the interface syntax for exporting method names is one thing but
> if we actually have to use the interfaces internally then we open a whole
> can of worms in terms of performance.  Class instantiation may be taking on
> some significant baggage now also as the compiler sets up these interface
> VMT tables, even if the user never needs or wants them.
>
> For example this code should be a compile time indirection instead of a
> hidden interface cast, right? The method forwarding syntax which works by
> modifying the VMT can hopefully be done at compile time for the default
> property also.
>

I wasn't saying anything that contradicts this, only that the original
mechanism of the delegation will be available even with the default
modifier and this mechanism will in fact be necessary to access them
through RTTI.

Regards,
Sven

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

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 16, 2021, at 6:51 AM, Benito van der Zander via fpc-pascal 
>  wrote:
> 
> Interfaces are extremely slow. Virtual method calls are also slow. I have 
> been using interfaces for reference counting, and have been thinking to 
> replace it all with managed records because they are so slow (unfortunately 
> records can also be slow because fpc does not always keep them in registers 
> even if they are pointer sized)

It's a real concern indeed. What we're proposing with a default property 
doesn't need to have these impacts but the class instantiation is going to be 
affected I think. 

> 
> There we have:
> 
> * slower creation of the class, because each implemented interface adds 
> another VMT reference to the class which needs to be initialized.

How bad is this? We need to make a test case we can profile. For example if you 
have a game that creates 1000 classes 60 frames per second. If adding 
interfaces to the classes hurts this process we may have a deal breaker.

> 
> * slower method calling because of the wrapper function

You mean for fields? We can inline those I believe but it's not fun boiler 
plate for sure.

> 
> * extremely slow casting an interface to the class. Never cast an interface, 
> better add a method to the interface returning a class reference
> 

We can avoid casting using the default property but it will still be possible 
to cast the class if you want to. 


> * slow reference counting. Especially if it is thread safe and exception safe 
> with the implicit exception block

It's a whole other topic but FPC needs opt-in ARC at the language level for 
classes. Interfaces are not only slow but then you need to pass around a 
reference to the interface instead of the class you actually care about. It 
makes no sense to me whatsoever.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Ryan Joseph via fpc-pascal]

> On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Again, the point of the interface would be to control which methods and 
> properties of the delegated  type would be available. Also it would allow for 
> seamless integration with the RTTI as it's possible to query the implemented 
> interface of a class and to retrieve a reference to it, thus it would be 
> possible to access this at runtime as well.
> 
> The compiler will generate a VMT for the interface with method thunks that 
> adjust the Self pointer so that it works correctly. The GetInterfaceByEntry 
> function uses this static data to generate an adjusted Self value that 
> callers can use.

As far as the "default implements property" is concerned we don't actually 
need, or even want to utilize the interfaces themselves. The idea of leveraging 
the interface syntax for exporting method names is one thing but if we actually 
have to use the interfaces internally then we open a whole can of worms in 
terms of performance.  Class instantiation may be taking on some significant 
baggage now also as the compiler sets up these interface VMT tables, even if 
the user never needs or wants them.

For example this code should be a compile time indirection instead of a hidden 
interface cast, right? The method forwarding syntax which works by modifying 
the VMT can hopefully be done at compile time for the default property also. 

type
  ICircle = interface
procedure Draw;
  end;

type
  TCircle = record
procedure Draw;
  end;

type
  TMyShape = class(ICircle)
private
  FCircle: TCircle;
public
  property Circle: TCircle read FCircle implements ICircle; default;
  end;

var
  shape: TMyShape;
begin
  shape := TMyShape.Create;
  { calls shape.FCircle.Draw instead of ICircle(shape).Draw }
  shape.Draw;
end.


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Traits Proposal

[Benito van der Zander via fpc-pascal]

There are no significant performance implications of interfaces. 
They're essentially a virtual method call, something that one is doing 
all day long with Object Pascal classes. 



Interfaces are extremely slow. Virtual method calls are also slow. I 
have been using interfaces for reference counting, and have been 
thinking to replace it all with managed records because they are so slow 
(unfortunately records can also be slow because fpc does not always keep 
them in registers even if they are pointer sized)


There we have:

* slower creation of the class, because each implemented interface adds 
another VMT reference to the class which needs to be initialized.


* slower method calling because of the wrapper function

* extremely slow casting an interface to the class. Never cast an 
interface, better add a method to the interface returning a class reference


* slow reference counting. Especially if it is thread safe and exception 
safe with the implicit exception block



On 14/02/2021 11:31, Sven Barth via fpc-pascal wrote:

Am 14.02.2021 um 01:09 schrieb Ben Grasset via fpc-pascal:
This seems possibly a *little* too similar to the existing Interface 
type in Object Pascal, however, I *would* really like to see some 
kind of functionality that basically amounts to "has the same 
capabilities as Interfaces and works on records and objects too, but 
does NOT require any kind of heap allocation".


My personal idea for this would be to allow for duck typing regarding 
interfaces: as long as the methods of the class, object or record 
satisfy those of the interface then it's possible to assign it. In 
case of objects and records one would mainly use raw interfaces (aka 
corba ones) instead of reference counted one as otherwise one would 
need to provide the methods of IInterface as well though one might not 
be able to implement them in a usable way as stack objects simply 
don't work that way.


So whether it be this, or just an improvement on the Interfaces we 
already have, I'd definitely personally be in favor of something that 
"works like Interfaces except minus the negative performance 
implications."


There are no significant performance implications of interfaces. 
They're essentially a virtual method call, something that one is doing 
all day long with Object Pascal classes.


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

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

Re: [fpc-pascal] compiling on command line linux

[duilio foschi via fpc-pascal]

very good.

I created the new directories

./synapse   and
./lazutils

in

/usr/lib/fpc/3.2.0/units/x86_64-linux

It worked like a charm.

It seems that all the units in that directory are searched by default.

Thank you

Duilio

On Tue, Feb 16, 2021 at 7:29 AM Sven Barth 
wrote:

> Am 15.02.2021 um 22:54 schrieb Alexander Grotewohl via fpc-pascal:
>
> There's a command line parameter.. try something like
>
> fpc -FU~/.units.lnx yourapp.pp
>
>
> Just to explain what -FUxxx does: this sets the unit output path. If you
> have precompiled units (or source files) in a different location you need
> to use -Fuxxx which sets the unit search path.
>
>
> Of course you would have to remember to do that for EVERY compile (I set
> my text editor to do it) but you could probably add it to your fpc.cfg too.
>
>
> You can add additional parameters to a custom file (just like you'd do
> with the global fpc.cfg) and then add it using the @ parameter:
>
> fpc @your.cfg yourapp.pp
>
> Regards,
> Sven
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal