Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-07-02 Thread Marco van de Voort 


Op 2019-06-27 om 15:12 schreef George Bakhtadze:


Volatile (I assume you mean a C-like volatile) is usable in very rare 
special cases. Such as work with hardware buffers.


(in embedded targets it is not that rare. E.g. variables/state shared 
between interrupts handlers and main program)


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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-29 Thread Sven Barth via fpc-devel 
Florian Klaempfl  schrieb am Sa., 29. Juni 2019,
15:52:

> Am 28.06.2019 um 11:24 schrieb George Bakhtadze:
> > This assumption is *not* incorrect. Only on the LLVM based Delphi
> > NewGen and FPC's LLVM backend the assumption is incorrect which can
> > be seen by them having added "volatile" mechanisms.
> >
> > I believe this assumption incorrect because it's not stated in
> > documentation as correct.
>
> It is not true, if possible, FPC puts global variables into registers.
>

Okay, then I stand corrected. 路‍♀️

Regards,
Sven

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-29 Thread Florian Klaempfl 

Am 28.06.2019 um 11:24 schrieb George Bakhtadze:

This assumption is *not* incorrect. Only on the LLVM based Delphi
NewGen and FPC's LLVM backend the assumption is incorrect which can
be seen by them having added "volatile" mechanisms. 

I believe this assumption incorrect because it's not stated in 
documentation as correct.


It is not true, if possible, FPC puts global variables into registers.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-29 Thread Sven Barth via fpc-devel 
George Bakhtadze  schrieb am Sa., 29. Juni 2019,
09:32:

>
>
> This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen
> and FPC's LLVM backend the assumption is incorrect which can be seen by
> them having added "volatile" mechanisms.
>
>
> I believe this assumption incorrect because it's not stated in
> documentation as correct.
> If FPC somehow guarantees that a global field (even only of simple types)
> can be atomically read and written from any thread for ANY platform that is
> a very strong guarantee and worth mention in documentation.
>

It does not guarantee atomicity and it's not mentioned in the
documentation, but the non-LLVM backends *always* reaccess global variables
- and there is enough code out there, both FPC and Delphi/TP that (ab)use
this so that it can be considered pseudo documented.

Regards,
Sven

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-29 Thread George Bakhtadze 
 This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms.  I believe this assumption incorrect because it's not stated in documentation as correct.If FPC somehow guarantees that a global field (even only of simple types) can be atomically read and written from any thread for ANY platform that is a very strong guarantee and worth mention in documentation.  ---Best regards, George
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-29 Thread George Bakhtadze 
> As an side since you’re talking about optimizations what would it take to 
> make the copy/addref record operators be inline? Unless I’m mistaken that’s 
> one of the bigger issues that makes custom ref counted objects slower than 
> built in compiler types. Just curious...

I believe counter's atomicity there is a much more heavyweight factor.

---
Best regards, George
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-28 Thread Sven Barth via fpc-devel 
George Bakhtadze  schrieb am Fr., 28. Juni 2019,
08:26:

> Hello,
>
> > One thing I have been considering is to promote fields and global
> variables to local registers to reduce memory accesses.
>
> That would be great. But multithreaded code which assume (incorrectly)
> that those fields and globals are in memory may be broken.
>

This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen
and FPC's LLVM backend the assumption is incorrect which can be seen by
them having added "volatile" mechanisms.

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-28 Thread George Bakhtadze 
Hello, > One thing I have been considering is to promote fields and global variables to local registers to reduce memory accesses. That would be great. But multithreaded code which assume (incorrectly) that those fields and globals are in memory may be broken.Other languages don't allow to assume anything about such entities in multithreaded code.From the other side, such languages do have a memory model which tells when a assignment result will become visible to other threads (if ever). > However, it would make multi-threaded code a bit trickier to write and demand the use of the "volatile" intrinsic on things like the conditions of while loops. Volatile (I assume you mean a C-like volatile) is usable in very rare special cases. Such as work with hardware buffers. In optimization sphere FPC can be improved in many ways. For example, expressions like: x + y * Ord(x > y)FPC 3.0.4 does use IMUL instruction. But it can be compiled much more effective with cmov:cmp     edi, esimov     eax, 0cmovle  esi, eaxadd     edi, esihttps://godbolt.org/z/Cf-AQE Don't know how hard is to implement such oiptimization though.  ---Best regards, George___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread J. Gareth Moreton 
In the meantime, I have some optimisations that I would be grateful 
could be evaluated - two of them are specific to the compiler, but one 
is much more general-purpose, relating to case blocks.


https://bugs.freepascal.org/view.php?id=34859
https://bugs.freepascal.org/view.php?id=35346
https://bugs.freepascal.org/view.php?id=35433

Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Sven Barth via fpc-devel 

Am 27.06.2019 um 20:40 schrieb Ryan Joseph:

As an side since you’re talking about optimizations what would it take to make 
the copy/addref record operators be inline? Unless I’m mistaken that’s one of 
the bigger issues that makes custom ref counted objects slower than built in 
compiler types. Just curious...

That is something that is currently simply not possible.

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Ryan Joseph 
As an side since you’re talking about optimizations what would it take to make 
the copy/addref record operators be inline? Unless I’m mistaken that’s one of 
the bigger issues that makes custom ref counted objects slower than built in 
compiler types. Just curious...

Regards,
Ryan Joseph

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Ben Grasset 
On Thu, Jun 27, 2019 at 8:15 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

> I think having record fields in registers would already go a long way.
> Global variables aren't used /that/ often in modern, object oriented code
> anyway.
>

Aren't they already?


As far as I've ever been able to surmise, the general problem is more that
people continue to think they can pass records by value and have the
compiler optimize the access for them, which it just simply doesn't.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Sven Barth via fpc-devel 
J. Gareth Moreton  schrieb am Do., 27. Juni
2019, 12:18:

> One thing I have been considering is to promote fields and global
> variables to local registers to reduce memory accesses.  However, it would
> make multi-threaded code a bit trickier to write and demand the use of the
> "volatile" intrinsic on things like the conditions of while loops.
>

I think having record fields in registers would already go a long way.
Global variables aren't used /that/ often in modern, object oriented code
anyway.

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread J. Gareth Moreton 
One thing I have been considering is to promote fields and global 
variables to local registers to reduce memory accesses.  However, it 
would make multi-threaded code a bit trickier to write and demand the 
use of the "volatile" intrinsic on things like the conditions of while 
loops.


Before I start anything though, I need to put together a schedule or a 
to-do list to work out what to play with first.  A lot of the time, I go 
by my whims and think "I fancy playing with the Free Pascal Compiler 
today" or I see something and think 'I could improve that' - 
unfortunately it's led me to mix fixes and changes into the same patch, 
which has been problematic before, so I'm trying to be more disciplined 
about it.


Gareth aka. Kit

On 27/06/2019 11:07, Benito van der Zander wrote:

Hi Gareth,

there are more optimizations to look at

An user could write custom string enumerators to replace such 
assignments in loops and try to manually solve that issue.



But then

https://bugs.freepascal.org/view.php?id=34915

the enumerators are stored in memory rather than registers, so it is 
always slower than a normal loop



Or since you like case; a case of strings should use a hashmap or 
something rather than doing one by one comparisons


Cheers,
Benito

Am 27.06.19 um 09:27 schrieb J. Gareth Moreton:

https://bugs.freepascal.org/view.php?id=35775

I'm both honoured and amused!  Thank you.

Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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


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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Benito van der Zander 

Hi Gareth,

there are more optimizations to look at

An user could write custom string enumerators to replace such 
assignments in loops and try to manually solve that issue.



But then

https://bugs.freepascal.org/view.php?id=34915

the enumerators are stored in memory rather than registers, so it is 
always slower than a normal loop



Or since you like case; a case of strings should use a hashmap or 
something rather than doing one by one comparisons


Cheers,
Benito

Am 27.06.19 um 09:27 schrieb J. Gareth Moreton:

https://bugs.freepascal.org/view.php?id=35775

I'm both honoured and amused!  Thank you.

Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread J. Gareth Moreton 

I figured you were serious with it.  I've garned a reputation, it seems!

I have some organisation to figure out first, since I've got to fix a 
bug , begin development 
of pure functions and update my patches for the x86-64 optimiser 
overhaul so it will still merge.


Granted, loop optimisaion is something that's cropped up a few times, 
both in terms of vectorisation and also taking advantage of pure 
functions.  I can't promise anything, but I'll certainly take a look.


As for learning new things... it's true.  I learnt so much about nodes 
while developing the XML node dump feature.


Gareth


On 27/06/2019 08:38, Michael Van Canneyt wrote:



On Thu, 27 Jun 2019, J. Gareth Moreton wrote:


https://bugs.freepascal.org/view.php?id=35775

I'm both honoured and amused!  Thank you.


Well, it was meant seriously. You mentioned more than once that you like
optimizations. This one would be a real big improvement for a pattern 
that

is often encountered.

It's also probably technically challenging, so you will learn a lot 
(or so I

assume).

Seems like a perfect fit to me...

Michael.

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



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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

2019-06-27 Thread Michael Van Canneyt 



On Thu, 27 Jun 2019, J. Gareth Moreton wrote:


https://bugs.freepascal.org/view.php?id=35775

I'm both honoured and amused!  Thank you.


Well, it was meant seriously. You mentioned more than once that you like
optimizations. This one would be a real big improvement for a pattern that
is often encountered.

It's also probably technically challenging, so you will learn a lot (or so I
assume).

Seems like a perfect fit to me...

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