Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-23 Thread Benito van der Zander 

Hi,


Isn't rax needed for the call to Free?



I think self stays in rdi

Perhaps we need a new calling convention that keeps self in rax. Or the 
return value in rdi


Cheers,
Benito



Am 21.08.2017 um 15:45 schrieb Stefan Glienke:

Isn't rax needed for the call to Free?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-23 Thread Benito van der Zander 

Hi,,


  SomeProc(Builder
.Build('1')
.Build('2')
.Build('3').Value);






That's exactly what I wanted to use it for


And since a string builder is such a low level construct, mostly used 
for performance improvements, it needs to be fast without additional 
instructions




Best,
Benito



Am 22.08.2017 um 14:42 schrieb Kazantsev Alexey via fpc-devel:

On Tue, 22 Aug 2017 13:15:24 +0200 (CEST)
Michael Van Canneyt  wrote:


Call me old-fashioned, but I much prefer

With StdIO::stdOutPrinter() do
  begin
  out("Helllo World ");
  out(42);
  out("");
  hex();
  out(42);
  line();
  end;

I see no point or gain in the "fluent" code.

  SomeProc(Builder
.Build('1')
.Build('2')
.Build('3').Value);



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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Stefan Glienke 
Often a fluent API has some grammar described via different interfaces that are 
implemented by either one (in this case you always return Self) or different 
classes.

It is not just to chain methods together that you could also write like you did.

> On 22 August 2017 at 13:15 Michael Van Canneyt  wrote:
>
>
>
>
> On Tue, 22 Aug 2017, Thaddy de Koning wrote:
>
> >> On 21.08.2017 13:22, Michael Van Canneyt wrote:
> >>>
> >>>
> >>> On Mon, 21 Aug 2017, Benito van der Zander wrote:
> >>>
>  Hi,
> 
> > This pattern is not inherently efficient. Why should it be ?
> 
> 
>  It is not efficient, because of the pointless instruction!
> >>>
> >>> I am not speaking of the current FPC implementation. It may well be that
> >>> the
> >>> code is not most optimal.
> >>>
> >>> I am asking, why do you think *this pattern* (of always returning self)
> >>> should be inherently more efficient ?
> >>
> >> The pattern definitely has its uses. E.g. in the user space of our
> >> operating system at work we have a StdOutPrinter class that is used like
> >> this:
> >>
> >> === code begin ===
> >>
> >> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
> >> ")->hex()->out(42)->line();
>
> Call me old-fashioned, but I much prefer
>
> With StdIO::stdOutPrinter() do
> begin
> out("Helllo World ");
> out(42);
> out("");
> hex();
> out(42);
> line();
> end;
>
> I see no point or gain in the "fluent" code.
>
> Michael.
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Michael Van Canneyt 



On Tue, 22 Aug 2017, Kazantsev Alexey via fpc-devel wrote:


On Tue, 22 Aug 2017 13:15:24 +0200 (CEST)
Michael Van Canneyt  wrote:


Call me old-fashioned, but I much prefer

   With StdIO::stdOutPrinter() do
 begin
 out("Helllo World ");
 out(42);
 out("");
 hex();
 out(42);
 line();
 end;

I see no point or gain in the "fluent" code.



SomeProc(Builder
  .Build('1')
  .Build('2')
  .Build('3').Value);


As far as I can see, that's not really different from the example Sven gave me ?

With builder do
  begin
  Build('1');
  Build('2');
  Build('3');
  SomeProc(Value);
  end;

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Kazantsev Alexey via fpc-devel 
On Tue, 22 Aug 2017 13:15:24 +0200 (CEST)
Michael Van Canneyt  wrote:

> Call me old-fashioned, but I much prefer
> 
>With StdIO::stdOutPrinter() do
>  begin
>  out("Helllo World ");
>  out(42);
>  out("");
>  hex();
>  out(42);
>  line();
>  end;
> 
> I see no point or gain in the "fluent" code.


 SomeProc(Builder
   .Build('1')
   .Build('2')
   .Build('3').Value);

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Sven Barth via fpc-devel 
Am 22.08.2017 13:15 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 22 Aug 2017, Thaddy de Koning wrote:
>
>>> On 21.08.2017 13:22, Michael Van Canneyt wrote:



 On Mon, 21 Aug 2017, Benito van der Zander wrote:

> Hi,
>
>> This pattern is not inherently efficient. Why should it be ?
>
>
>
> It is not efficient, because of the pointless instruction!


 I am not speaking of the current FPC implementation. It may well be
that
 the
 code is not most optimal.

 I am asking, why do you think *this pattern* (of always returning self)
 should be inherently more efficient ?
>>>
>>>
>>> The pattern definitely has its uses. E.g. in the user space of our
>>> operating system at work we have a StdOutPrinter class that is used like
>>> this:
>>>
>>> === code begin ===
>>>
>>> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
>>> ")->hex()->out(42)->line();
>
>
> Call me old-fashioned, but I much prefer
>
>   With StdIO::stdOutPrinter() do
> begin
> out("Helllo World ");
> out(42);
> out("");
> hex();
> out(42);
> line();
> end;
>
> I see no point or gain in the "fluent" code.

First C++ has no with-statement and second I definitely prefer my output to
be on one line. :)
Also in other cases fluent interfaces are rather nice to have.
Though they also don't force you to be used in that way :) (at least if
they really only return Self/This).

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Michael Van Canneyt 



On Tue, 22 Aug 2017, Thaddy de Koning wrote:


On 21.08.2017 13:22, Michael Van Canneyt wrote:



On Mon, 21 Aug 2017, Benito van der Zander wrote:


Hi,


This pattern is not inherently efficient. Why should it be ?



It is not efficient, because of the pointless instruction!


I am not speaking of the current FPC implementation. It may well be that
the
code is not most optimal.

I am asking, why do you think *this pattern* (of always returning self)
should be inherently more efficient ?


The pattern definitely has its uses. E.g. in the user space of our
operating system at work we have a StdOutPrinter class that is used like
this:

=== code begin ===

StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
")->hex()->out(42)->line();


Call me old-fashioned, but I much prefer

  With StdIO::stdOutPrinter() do
begin
out("Helllo World ");
out(42);
out("");
hex();
out(42);
line();
end;

I see no point or gain in the "fluent" code.

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-22 Thread Thaddy de Koning 
> On 21.08.2017 13:22, Michael Van Canneyt wrote:
>>
>>
>> On Mon, 21 Aug 2017, Benito van der Zander wrote:
>>
>>> Hi,
>>>
 This pattern is not inherently efficient. Why should it be ?
>>>
>>>
>>> It is not efficient, because of the pointless instruction!
>>
>> I am not speaking of the current FPC implementation. It may well be that
>> the
>> code is not most optimal.
>>
>> I am asking, why do you think *this pattern* (of always returning self)
>> should be inherently more efficient ?
>
> The pattern definitely has its uses. E.g. in the user space of our
> operating system at work we have a StdOutPrinter class that is used like
> this:
>
> === code begin ===
>
> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
> ")->hex()->out(42)->line();
>
> === code end ===
>
> Each function returns again the instance that was returned by
> StdIO::stdOutPrinter().
>
> The whole pattern is called method chaining or fluent interface:
> - https://en.wikipedia.org/wiki/Method_chaining
> - https://en.wikipedia.org/wiki/Fluent_interface
>
> Regards,
> Sven
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
E.g. KOL is based on this (or very close). The core methods always return
self.

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Sven Barth via fpc-devel 
On 21.08.2017 21:15, Marco van de Voort wrote:
> In our previous episode, Sven Barth via fpc-devel said:
>>> I am asking, why do you think *this pattern* (of always returning self)
>>> should be inherently more efficient ?
>>
>> The pattern definitely has its uses. E.g. in the user space of our
>> operating system at work we have a StdOutPrinter class that is used like
>> this:
> 
> No need to look so far, just look at TV/FV dialog construction.

I've never really worked with TV/FV, so I can't use that as an example ^^'

Regards,
Sven

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Marco van de Voort 
In our previous episode, Sven Barth via fpc-devel said:
> > I am asking, why do you think *this pattern* (of always returning self)
> > should be inherently more efficient ?
> 
> The pattern definitely has its uses. E.g. in the user space of our
> operating system at work we have a StdOutPrinter class that is used like
> this:

No need to look so far, just look at TV/FV dialog construction.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Sven Barth via fpc-devel 
On 21.08.2017 13:22, Michael Van Canneyt wrote:
> 
> 
> On Mon, 21 Aug 2017, Benito van der Zander wrote:
> 
>> Hi,
>>
>>> This pattern is not inherently efficient. Why should it be ? 
>>
>>
>> It is not efficient, because of the pointless instruction!
> 
> I am not speaking of the current FPC implementation. It may well be that
> the
> code is not most optimal.
> 
> I am asking, why do you think *this pattern* (of always returning self)
> should be inherently more efficient ?

The pattern definitely has its uses. E.g. in the user space of our
operating system at work we have a StdOutPrinter class that is used like
this:

=== code begin ===

StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
")->hex()->out(42)->line();

=== code end ===

Each function returns again the instance that was returned by
StdIO::stdOutPrinter().

The whole pattern is called method chaining or fluent interface:
- https://en.wikipedia.org/wiki/Method_chaining
- https://en.wikipedia.org/wiki/Fluent_interface

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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Florian Klämpfl 
Am 21.08.2017 um 12:12 schrieb Benito van der Zander:
> Hi,
> 
>> This pattern is not inherently efficient. Why should it be ? 
> 
> 
> It is not efficient, because of the pointless instruction!

Well, a register-register move can be considered almost as a nop on modern 
architectures. If you
really think it is important just provide a patch which eliminates such 
instructions.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Stefan Glienke 
Isn't rax needed for the call to Free?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Ondrej Pokorny 

On 21.08.2017 13:22, Michael Van Canneyt wrote:
I am asking, why do you think *this pattern* (of always returning 
self) should be inherently more efficient ?


Benito didn't state it is more efficient (than something else). He said 
it is popular and not optimized in fpc.


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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Michael Van Canneyt 



On Mon, 21 Aug 2017, Benito van der Zander wrote:


Hi,

This pattern is not inherently efficient. Why should it be ? 



It is not efficient, because of the pointless instruction!


I am not speaking of the current FPC implementation. It may well be that the
code is not most optimal.

I am asking, why do you think *this pattern* (of always returning self) should 
be inherently more efficient ?


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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Benito van der Zander 

Hi,

This pattern is not inherently efficient. Why should it be ? 



It is not efficient, because of the pointless instruction!



Bye,
Benito



Am 21.08.2017 um 08:39 schrieb Michael Van Canneyt:



On Sun, 20 Aug 2017, Benito van der Zander wrote:


Hi,

why does fpc not remove the calculation of the return value of inline 
functions, when the return value is unused?


For example

type TUtility = class
 function doSomething: TUtility; inline;
end;


It is a popular pattern to add result := self; to _every_ method (or 
result := @self in objects/records), so it can be chained as 
dosomething().dosomething().dosomething(),.
but one cannot use it with fpc efficiently, when it inserts too many 
unnecessary instructions


A strange statement.

This pattern is not inherently efficient. Why should it be ?

It's just something that boiled over from other languages and some people
see it as a nifty way of writing code.

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


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

Re: [fpc-devel] Optimizing unused return values of inline functions

2017-08-21 Thread Michael Van Canneyt 



On Sun, 20 Aug 2017, Benito van der Zander wrote:


Hi,

why does fpc not remove the calculation of the return value of inline 
functions, when the return value is unused?


For example

type TUtility = class
 function doSomething: TUtility; inline;
end;


It is a popular pattern to add result := self; to _every_ method (or result 
:= @self in objects/records), so it can be chained as 
dosomething().dosomething().dosomething(),.
but one cannot use it with fpc efficiently, when it inserts too many 
unnecessary instructions


A strange statement.

This pattern is not inherently efficient. Why should it be ?

It's just something that boiled over from other languages and some people
see it as a nifty way of writing code.

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