Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 21:30 GMT+02:00 Michael Van Canneyt :

> I can imagine that checking such a field will be more fast than actually
>>> calling a routine. This is just a thought, if you had already considered
>>> such a thing, I would like to hear why you discarded it, for my
>>> education.
>>>
>>
>>
>> this is exactly what is done in FastRTTI
>>
>
> Yes, I imagined this answer. Allow me to ask further questions:
>
> You are adding - please correct me if I am wrong - a complete new table
> to the binary, for every class. What does this table contain if no
> management operators are used ?


Dear Sir, all was explained in core mailing list (about FastRTTI) and in
fpc-devel (about management operators), even if some detail was not clear
enough you had many occasions to ask.

If you was able to imagine previous answer I think that you can imagine my
next answer so let me not answering on your request because you already
know the answer (the answer already exist in your imagination). First you
told that my solution is :

 - simply not convincing
 - FastRTTI is tricky
 - I should find a solution just a little harder
 - you are talking that: things are rammed through our throat which we
didn't ask for
 - you are asking for a solution that satisfies everyone (finally every
other person can contribute)

After something like this, without basic knowledge about my work, now you
are asking for details ? In addition :

 - in core and in public lists you are writing many strange things all the
time, like for example that I am drunk, etc (about other topics but this is
general manner of your personal culture)
 - I had ban from you on G+ in "FreePascal Foundation" group (some time
ago, only because I was author of NewPascal)
 - you are thinking that all my work for FPC is bad (or most of work,
without basic knowledge about details)

I have one clear answer for you (especially that you are the "core member")
:

I have no time for you anymore because I have more important things to do
than blabbing with you.

Best wishes and good luck!

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Michael Van Canneyt]

On Mon, 30 Apr 2018, Anthony Walter wrote:


Okay, I found a nice work around to allow for circular references on record
types:

record helpers

type
 JSValue = record
 ...
 end;

 JSObject = record
 ...
 end;

 JSValueHelper = record helper for JSValue
   function AsObject: JSObject;
 end;

 JSObjectHelper= record helper for JSObject
   function GetProperty(const Name: string): JSValue;
   procedure SetProperty(const Name: string; Value: JSValue);
 end;



Clever thinking :)

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

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Okay, I found a nice work around to allow for circular references on record
types:

record helpers

type
  JSValue = record
  ...
  end;

  JSObject = record
  ...
  end;

  JSValueHelper = record helper for JSValue
function AsObject: JSObject;
  end;

  JSObjectHelper= record helper for JSObject
function GetProperty(const Name: string): JSValue;
procedure SetProperty(const Name: string; Value: JSValue);
  end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Thanks for replying. I'd like to chime in with a few thoughts..

I believe manged types beyond string, dynamic array, and interface as
important. In my use case worked around the problem by using records with
private interface as I already mentioned. This solution is less than
optimal as it requires defining 3 types when 1 would do. Also, stakc based
types like record and object are useful because they don't require dynamic
allocation, but have some serious drawback because they do not support
forward declaration.

Consider this situation I am currently working though. I have script
context, object, and value types. both objects and values need to know
about their context, and both value and objects need to know about each
other.

function JSValue.IsObject: Boolean;
function JSValue.ToObject: JSObject;

-and -

procedure JSObject.SetProperty(const Name: string; Value: JSValue);
function JSObject.GetProperty(const Name: string): JSValue;

In this design a value can contain and object, and an object can have
properties that are values. When using records to represent JSValue and
JSObject, this design is simply not possible, because you cannot forward
declare a record.

To work around this using classes (which can be forward declared)  without
a management instead of records is more than cumbersome because of the need
to track all intermediate busy data and manually free each one.

Interfaces by themselves aren't optimal either because you cannot define
conversions or operators on them.

Consider this:

  JSString = record
  ...
  public
class operator Implicit(const S: string): JSString;
class operator Implicit(S: JSString): string;
class operator Equal(A, B: JSString) : Boolean;
class operator Equal(A: JSString; const B: string) : Boolean;
property Length: Integer read GetLength;
  end;

- or -

  JSContext = record
  ...
  public
class operator Implicit(C: JSContext): JSContextRef;
  end;

If I were to use interfaces exclusively, it would be more cumbersome to
work with the JSC API, as it requires ObjectRef types for everything,
including strings. I would have to call methods to convert to, and a
separate set of method to convert from. Where as with records, objects, and
classes, you can write implicit conversions when no data loss takes places,
but types are converted implicitly, removing a lot of needless code
complexity.

In short, because you cannot forward declare record or object types,
because you would to free classes manually in many places, and because
interface types cannot convert to intrinsic types like string or pointer,
managed types for classes is the best solution in this use case.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Michael Van Canneyt]

On Mon, 30 Apr 2018, Maciej Izak wrote:


I can imagine that checking such a field will be more fast than actually
calling a routine. This is just a thought, if you had already considered
such a thing, I would like to hear why you discarded it, for my education.



this is exactly what is done in FastRTTI


Yes, I imagined this answer. Allow me to ask further questions:

You are adding - please correct me if I am wrong - a complete new table
to the binary, for every class. What does this table contain if no
management operators are used ?

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

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 20:56 GMT+02:00 Michael Van Canneyt :

> There is no agression. There is critique.
>
> Maybe the others were satisfied with your solution I am not. So I brought
> it
> again to everyone's attention.


There is difference between rudeness and critique. You are just rude, for
someone from core team I have greater demands.


> I can imagine that checking such a field will be more fast than actually
> calling a routine. This is just a thought, if you had already considered
> such a thing, I would like to hear why you discarded it, for my education.


this is exactly what is done in FastRTTI

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Michael Van Canneyt]

On Mon, 30 Apr 2018, Maciej Izak wrote:


2018-04-30 14:59 GMT+02:00 Michael Van Canneyt :


Maybe because your solution is simply not convincing and I wish to try and
find a solution just a little harder ?

Allow me to exaggerate the point a little:

A bunch of changes are introduced, things are rammed through our throat
which we didn't ask for and then we're told "this is the price for
progress'.



Management operators feature was one of the point from Sven's TODO list and
was consulted with Sven, Florian and Jonas. If Sven, Florian or Jonas likes
to remove this idea I have no objections it was not my idea I am just a
modest contractor.

The FastRTTI was created on your request (not directly) because you asked
about speed comparison between FPC 1.0 and 3.0/trunk in core mailing list.
Florian asked for patch and FastRTTI is the answer for Florian request,
checked also by Sven. I don't understand your aggression and the whole
message. You was informed all the time like others in core team.


There is no agression. There is critique.

Maybe the others were satisfied with your solution I am not. So I brought it
again to everyone's attention.



Maybe other people can contribute to a solution that satisfies everyone.




Maybe yes, probably I am too stupid :)


I didn't want to imply that at all. 
As you know, 2 pairs of eyes see more than 1 pair.


All I am saying is that what I consider an important principle is being violated, 
namely that a feature you do not use should not influence your code:
If I use plain pascal, then the fact that we have advanced records does 
not influence the speed of my code.


Here something is introduced that, even if I do not use it, will influence
my code, and I cannot avoid it. (provided I understood your design right)

That is what I am pointing out, and it is what I want to draw attention to.

And PLEASE don't take this personal. I am not attacking you, I am pointing
out what I consider flaws in a design/implementation/whatever you want to
call it. You may or may not agree, I'm fine with that, but please treat the
subject in an impersonal manner. Because so do I.

As for solutions: Can we not add a class field or class method to the VMT or
some new table (typeinfo, whatever) that shows whether a class needs extra 
initialization or not.


I can imagine that checking such a field will be more fast than actually 
calling a routine. This is just a thought, if you had already considered 
such a thing, I would like to hear why you discarded it, for my education.


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

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 14:59 GMT+02:00 Michael Van Canneyt :
>
> Maybe because your solution is simply not convincing and I wish to try and
> find a solution just a little harder ?
>
> Allow me to exaggerate the point a little:
>
> A bunch of changes are introduced, things are rammed through our throat
> which we didn't ask for and then we're told "this is the price for
> progress'.


Management operators feature was one of the point from Sven's TODO list and
was consulted with Sven, Florian and Jonas. If Sven, Florian or Jonas likes
to remove this idea I have no objections it was not my idea I am just a
modest contractor.

The FastRTTI was created on your request (not directly) because you asked
about speed comparison between FPC 1.0 and 3.0/trunk in core mailing list.
Florian asked for patch and FastRTTI is the answer for Florian request,
checked also by Sven. I don't understand your aggression and the whole
message. You was informed all the time like others in core team.

Maybe other people can contribute to a solution that satisfies everyone.
>

Maybe yes, probably I am too stupid :)

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 15:05 GMT+02:00 Mattias Gaertner :

> Does that mean fpc 3.0.x had an unneeded overhead for classes without
> managed types and 3.1 fixes this?
>

No, small unneeded overhead exist in both.

The situation is different when managed types are used. FPC has similar
solution for RTTI like Delphi. FastRTTI (not merged yet into trunk) is
something new (optimized layout of RTTI). In the short all managed fields
are initialized in one call instead of recursion (one call to
FPC_INITIALIZE instead of many calls). It saves many of
initialization/finalization time.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Michael Van Canneyt]

On Mon, 30 Apr 2018, Maciej Izak wrote:


2018-04-30 13:53 GMT+02:00 Michael Van Canneyt :


You mean that a constructor call for a program that does not uses
pointers/management operators also gets slower ?

Can we solve this _without_ additional tricks ?

Because the fact that a feature you do not use slows down your code is not
really acceptable in my opinion.



It was discussed some time ago on core so I have no idea why you are asking
for this again.


Maybe because your solution is simply not convincing and I wish to try and
find a solution just a little harder ?

Allow me to exaggerate the point a little:

A bunch of changes are introduced, things are rammed through our throat 
which we didn't ask for and then we're told "this is the price for progress'.


It should come as no surprise that questions are asked, in such a situation.


This is the price of managed types. FastRTTI is significant step forward
for more performant and extensive usage of managed types (also for smart
pointers).


The point is that when you use the other features, you know and accept the
consequences. I only use strings & dynamic arrays as managed types. 
The benefits are clear, so I accept the management overhead they incur. 
I don't use interfaces (except Corba interfaces, no overhead there).


So I can perfectly estimate the impact of managed types on my code.

This is different: I don't want/need this feature, but I am hit by the
overhead anyway, if I understand you correctly. I cannot avoid it.

So yes, I definitely think that this question needs to be asked again.

Note that I am not asking you to revert the situation, but I would like to
see a little more effort to ensure the impact on people that do not use a
feature, is as small as technically possible.

Maybe other people can contribute to a solution that satisfies everyone.

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

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 13:53 GMT+02:00 Michael Van Canneyt :
>
> You mean that a constructor call for a program that does not uses
> pointers/management operators also gets slower ?
>
> Can we solve this _without_ additional tricks ?
>
> Because the fact that a feature you do not use slows down your code is not
> really acceptable in my opinion.
>

It was discussed some time ago on core so I have no idea why you are asking
for this again. The "slower" is too strong word. RTL must to call internal
int_initialize in TObject.InitInstance and this is required for management
operators. The similar operation was always executed for destructors in
TObject.CleanupInstance: "int_finalize" even without new feature
"management operator" for all managed types.

With FastRTTI additional call to int_initialize is omitted when
possible. Furthermore
with FastRTTI all code is executed faster (much faster than in 3.0.x)
because all info about managed fields (for classes, objects and records) is
aggregated in single array for faster initialization/finalization. By
managed fields I mean all managed types (strings, interfaces, etc.)

So: no we can't solve this without FastRTTI (or without significant part of
FastRTTI) and this is not additional trick but new feature.

This is the same for any string and interface (or any other managed type)
inside classes. Your code is already "slows down" even when you don't use
managed types for fields (even in 3.0.x or in any previous version).
Nothing new here so probably you should change your opinion.

This is the price of managed types. FastRTTI is significant step forward
for more performant and extensive usage of managed types (also for smart
pointers).

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Michael Van Canneyt]

On Mon, 30 Apr 2018, Maciej Izak wrote:


2018-04-30 13:15 GMT+02:00 Anthony Walter :


Okay great. Thanks for the information. I'll experiment with the smart
pointers and their potential performance impact. In the interim I've
created a solution using the approach of records containing private
reference counted interfaces. Here is an example of my JSContext record:



Internal interface is also proper solution, all depends on use-case. Anyway
in my previous post I mean that every execution of constructor in trunk
(even without smart pointers/management operators in any place) is slower
than in 3.0.* (in most of cases the difference is very subtle, just
additional call to "int_initialize" in TObject.InitInstance
(rtl\inc\objpas.inc file) - with FastRTTI this problem is solved).


You mean that a constructor call for a program that does not uses 
pointers/management operators also gets slower ?


Can we solve this _without_ additional tricks ?

Because the fact that a feature you do not use slows down your code is 
not really acceptable in my opinion.


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

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-30 13:15 GMT+02:00 Anthony Walter :

> Okay great. Thanks for the information. I'll experiment with the smart
> pointers and their potential performance impact. In the interim I've
> created a solution using the approach of records containing private
> reference counted interfaces. Here is an example of my JSContext record:
>

Internal interface is also proper solution, all depends on use-case. Anyway
in my previous post I mean that every execution of constructor in trunk
(even without smart pointers/management operators in any place) is slower
than in 3.0.* (in most of cases the difference is very subtle, just
additional call to "int_initialize" in TObject.InitInstance
(rtl\inc\objpas.inc file) - with FastRTTI this problem is solved).

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Okay great. Thanks for the information. I'll experiment with the smart
pointers and their potential performance impact. In the interim I've
created a solution using the approach of records containing private
reference counted interfaces. Here is an example of my JSContext record:


   1.   JSContext = record
   2.   private
   3. FRef: IJSContext;
   4.   public
   5. class function Create: JSContext; static;
   6. class function Retain(C: JSContextRef): JSContext; static;
   7. class operator Implicit(C: JSContext): JSContextRef;
   8. function EvaluateScript(const Script: string): JSValue;
   9. function CreateFunction(const Name: string; Callback: JSFunction):
JSObject;
   10. function CreateMethod(const Name: string; Callback: JSMethod):
   JSObject;
   11. function CreateUndefined: JSValue;
   12. function CreateNull: JSValue;
   13. function CreateBoolean(Value: Boolean): JSValue;
   14. function CreateNumber(Value: Double): JSValue;
   15. function CreateString(const Value: string): JSValue;
   16. function CreateJSON(const Value: string): JSValue;
   17.   end;

So you could use it to embed a javascript engine in your free pascal
application like so:


   1. function TestCallback(Context: JSContext; Args: JSValues): JSValue;
   2. begin
   3.   Result := JSContext.CreateString('You passed ' + IntToStr(Args.
   Length) + ' arguments');
   4. end;
   5.
   6. function MessageBoxCallback(Context: JSContext; Args: JSValues):
   JSValue;
   7. begin
   8.   if Args.Length > 0 then
   9. ShowMessage(Args[0].AsString);
   10.   Result := JSContext.CreateUndefined;
   11. end;
   12.
   13. procedure TForm1.Button1Click(Sender: TObject);
   14. var
   15.   C: JSContext;
   16.   R: JSValue;
   17. begin
   18.   C := JSContext.Create;
   19.   C.CreateFunction('test', TestCallback);
   20.   C.CreateFunction('messageBox', MessageBoxCallback);
   21.   R := C.ExecuteScript(
   22. 'let s = test(123, "hello");' +
   23. 'messageBox("test gave us:" + s);' +
   24. 'let result = "okay, we are done.";');
   25.   Caption := R.AsString;
   26. end;

Note, using my records with interfaces we don't have to clean up anything,
and the javascript context is destroyed when Button1Click exits. The only
problem I have right now is you cannot forward declare records, so with
pascal it's not possible for two records to use each other in their type
definitions.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-29 21:26 GMT+02:00 Anthony Walter :

> I wanted to know from the people who make decision about what to merge,
> what's the status of rolling his enhancements at following location into
> FPC trunk?
>

The key part of smart pointers (management operators) is already in trunk
(as Sven said). Btw. you forgot about AddRef operator ;)

The problem is more complicated than just "merge" for "default field".

*** part 1 ***

The first problem is slowdown for constructors for classes (which already
is part of trunk, trunk is a little slower than 3.0.x for constructors).
The main reason of " slowdown" is new feature "management operators". The
solution (and improvement) is FastRTTI which is designed for management
operators and all managed types:

https://github.com/maciej-izak/freepascal/tree/fastrtti

with these patch FPC is faster for all classes/records/objects with managed
types. This patch is not only designed as patch for constructors but the
gain is more general, for all managed types the result is really good - the
execution of code is even few times faster when you use a lot of managed
types. Compiler compilation with FastRTTI is always faster around 1%-3%
(where usage of managed types is rather rare). The hardest part for me of
implementation of FastRTTI was testing (I don't use AVR nor i8086 nor m68k)
, but this is ready:

https://travis-ci.org/maciej-izak/fpc-ci-tests/builds/320484
786?utm_source=email_medium=notification

this part was really depressing :P. The last thing what I must finish is
renaming "holes" to "unmanaged_spaces" x) (personally I prefer the "holes"
but I must agree with Sven that the "holes" term is not perfect).

*** part 2 ***

The default field. The topic is complicated on many fields, but generally
we have 2 issues, raised by Jonas :

- existence of @@ and @@@ operators:

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield6.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield14.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield21.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield22.pp

- handling procedures/methods parameters (especially for var/out which is
not listed below)

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield25.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield26.pp

as solution was proposed new type kind, but IMO new kind just for default
field is redundant. What with further usage of "default field" for classes
and objects (maybe now it looks like nonsense but should be usefully with
ARC combination with classes)? Again new types? I don't wan't to lock this
path (default field for classes and objects).

possible alternative is "strict" modifier

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield30.pp

"strict default" may be the solution, the record with "strict default" may
have more strict policy in compiler to make all of us happy. If someone
needs to use "default field" as more advanced precise helpers - just use
"default". If strict policy is more important (like for Jonas, some part of
me agree with him) then use "strict default".

Technically all for smart pointers is ready.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Sven Barth via fpc-devel]

Anthony Walter  schrieb am So., 29. Apr. 2018, 21:27:

> I've run into an almost must have use case for FPC smart pointers as
> described and implemented by Maciej. I wanted to know from the people who
> make decision about what to merge, what's the status of rolling his
> enhancements at following location into FPC trunk?
>
> svn ls https://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers/
>

The management operators are already part of trunk for more than a year,
see here:
http://lists.freepascal.org/pipermail/fpc-announce/2017-February/000600.html

Regards,
Sven

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