Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[thaddy]

On 2019-11-08 22:33, Bart via fpc-devel wrote:

Hi,

 > 2.

A rather more serious issue.
Compile time errors occur with e.g.
ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc
(32-bit), objfpc (32+64-bit) and delphi (32+64-bit)
Range check error while evaluating constants (2147483648 must be
between -2147483648 and 2147483647)
Same error for AnInteger.SetBit(High(TIntegerBitIndex)) in modes
objfpc (32-bit), delphi (32-bit) and macpas (32-bit)


I broke my brains and could not conclude anything else than a compiler 
bug in these cases: setting the sign bit is all I do and the bit 
patterns are all correct.
It seems that this is also confirmed. Anyway you suggestion to do the 
internals only as unsigned types makes sense if in that case the sign 
bit is respected.

Funny how such simple code - which it is - can have so much complexity.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] inline... and philosophy

[Sven Barth via fpc-devel]

Am 10.11.2019 um 15:47 schrieb Marco van de Voort:
(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)
I don't know if that would help much, cause especially on Windows every 
application would probably provide its own set of binaries and the RTL 
package alone has a size of ~3.7 MB on Win64.


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

Re: [fpc-devel] inline... and philosophy

[Florian Klämpfl]

Am 10.11.19 um 18:01 schrieb J. Gareth Moreton:

Fair enough - thank you.

This is a bit of a micro-optimisation for the compiler in regards to 
what I've just done, but I've noticed that, a couple of times, commands 
to the effect of the following appear:


tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...

That is... dereference a label, and then do something if it turns into a 
dead label (usually remove it).  Would it be permissible to change the 
decrefs method so it returns a Boolean expression, namely True if the 
reference falls to zero and False otherwise? Given the function already 
checks to see if the reference count is less than zero (to raise an 
internal error), it should have negligable performance loss, and if 
anything, the new jump optimisations will help a lot.


In the meantime, I've just taken a quick look at my code, and noticed 
something possibly a little risky (compiler/x86/aoptx86.pas, line 3540):


{ Remove label xxx (it will have a ref of zero due to the initial check }
StripLabelFast(hp4);

{ Now we can safely decrement it }
tasmlabel(symbol).decrefs; >
There's nothing actually buggy with the code because it's known that the 
label has a reference count of 1 at this point, but "StripLabelFast" 
removes the label while it's still live, something that I even said in 
the procedure's comments that you shouldn't do!  i.e. I broke my own 
rule!  To be safe, these two commands should probably be switched 


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

Re: [fpc-devel] inline... and philosophy

[J. Gareth Moreton]

Fair enough - thank you.

This is a bit of a micro-optimisation for the compiler in regards to 
what I've just done, but I've noticed that, a couple of times, commands 
to the effect of the following appear:


tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...

That is... dereference a label, and then do something if it turns into a 
dead label (usually remove it).  Would it be permissible to change the 
decrefs method so it returns a Boolean expression, namely True if the 
reference falls to zero and False otherwise? Given the function already 
checks to see if the reference count is less than zero (to raise an 
internal error), it should have negligable performance loss, and if 
anything, the new jump optimisations will help a lot.


In the meantime, I've just taken a quick look at my code, and noticed 
something possibly a little risky (compiler/x86/aoptx86.pas, line 3540):


{ Remove label xxx (it will have a ref of zero due to the initial check }
StripLabelFast(hp4);

{ Now we can safely decrement it }
tasmlabel(symbol).decrefs;

There's nothing actually buggy with the code because it's known that the 
label has a reference count of 1 at this point, but "StripLabelFast" 
removes the label while it's still live, something that I even said in 
the procedure's comments that you shouldn't do!  i.e. I broke my own 
rule!  To be safe, these two commands should probably be switched 
around, so the label is actually dead when StripLabelFast is called.  It 
won't affect the output in any way, but will hopefully reduce the risk 
of alarming another programmer who stumbles upon it.


Gareth aka. Kit


On 10/11/2019 16:45, Florian Klämpfl wrote:

Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:


Some of the "condition_in" functions need expanding though, and I 
don't yet have an answer if it's okay to do operator overloading in 
the compiler source (so I can do things like "if (jmp1.cond in 
jmp2.cond) then", for example, instead of the more ambiguous "if 
condition_in(jmp1.cond, jmp2.cond) then".


I wouldn't do, for somebody without experience with the code, this is 
confusing. Operator overloading makes imo only sense if it effects a 
lot of code and makes it more readable because it replaces a lot of 
nested function calls.

___
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] inline... and philosophy

[Florian Klämpfl]

Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:


Some of the "condition_in" functions need expanding though, and I don't 
yet have an answer if it's okay to do operator overloading in the 
compiler source (so I can do things like "if (jmp1.cond in jmp2.cond) 
then", for example, instead of the more ambiguous "if 
condition_in(jmp1.cond, jmp2.cond) then".


I wouldn't do, for somebody without experience with the code, this is 
confusing. Operator overloading makes imo only sense if it effects a lot 
of code and makes it more readable because it replaces a lot of nested 
function calls.

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

Re: [fpc-devel] inline... and philosophy

[J. Gareth Moreton]

That seems fair, yep.  Currently, vectorcall, and the more intricate 
parts of the System V ABI, is only really beneficial when interfacing 
with third-party libraries or when programming in assembly language.


Sorry if I've given you a headache with my stubbornness and passion.  
I'll try to behave myself.  Thanks for accepting the jump optimisations, 
by the way.  I hope they perform well.


Some of the "condition_in" functions need expanding though, and I don't 
yet have an answer if it's okay to do operator overloading in the 
compiler source (so I can do things like "if (jmp1.cond in jmp2.cond) 
then", for example, instead of the more ambiguous "if 
condition_in(jmp1.cond, jmp2.cond) then".


Gareth aka. Kit

On 10/11/2019 15:33, Florian Klämpfl wrote:

Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and 
insightful than I would have given it credit for.  Thanks everybody!


I know a lot of the time, the size of binaries is just an illusion, 
along with unfair comparisons with GCC (a behemoth with corporate 
support) and Microsoft Visual C++ that often hides the size of 
binaries behind a redistributable library.  I don't ever seek to make 
binaries smaller at the expense of speed, but if I see a potential 
saving that could be done automatically, I dive for it!


On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)


I did try to start simple with the 'uComplex' unit, but concerns were 
raised because I changed the formal parameters to 'const' and aligned 
the complex type on x86-64 platforms so it can take advantage of XMM 
registers better (which, given proper optimisation, would result in 
both smaller code size and higher speed).  While I made sure that the 
interfaces would not change for Pascal code, assembler code that 
calls the functions (if it exists) might need to be changed slightly 
(something Florian raised).  I'm not quite sure what the rules are 
when it comes fo updating packages, other than the obvious one of not 
breaking old code.


Currently, there is no real gain by changing the calling conventions. 
When we have a vectorizer, we can talk about it.




I like working on optimisation because I have a morbid fascination 
with the lowest level of the CPU and I feel well-suited for it, 
although there are still some things I'm learning about it.


Gareth aka. Kit


___
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] Capturing addresses

[Marco Borsari via fpc-devel]

Il 10/11/2019 14:36, Jonas Maebe ha scritto:

Hi,

Does anyone know what the accepted/excepted behaviour is regarding the
capture of addresses of var/out/const-by-address/constref parameters?

For example:

var
   g: longint;
   p: plongint;

procedure test(var l: longint);
begin
   p:=@l;
end;

begin
   test(g);
end.

The question is: should the compiler by default assume that such
addresses are not captured, or that they are captured? Does anyone know
if a lot of code exists that does this?


To me p:=@l should be simply refused by the compiler as it happens in 
case of p:=l.

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

Re: [fpc-devel] inline... and philosophy

[Florian Klämpfl]

Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and 
insightful than I would have given it credit for.  Thanks everybody!


I know a lot of the time, the size of binaries is just an illusion, 
along with unfair comparisons with GCC (a behemoth with corporate 
support) and Microsoft Visual C++ that often hides the size of binaries 
behind a redistributable library.  I don't ever seek to make binaries 
smaller at the expense of speed, but if I see a potential saving that 
could be done automatically, I dive for it!


On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)


I did try to start simple with the 'uComplex' unit, but concerns were 
raised because I changed the formal parameters to 'const' and aligned 
the complex type on x86-64 platforms so it can take advantage of XMM 
registers better (which, given proper optimisation, would result in both 
smaller code size and higher speed).  While I made sure that the 
interfaces would not change for Pascal code, assembler code that calls 
the functions (if it exists) might need to be changed slightly 
(something Florian raised).  I'm not quite sure what the rules are when 
it comes fo updating packages, other than the obvious one of not 
breaking old code.


Currently, there is no real gain by changing the calling conventions. 
When we have a vectorizer, we can talk about it.




I like working on optimisation because I have a morbid fascination with 
the lowest level of the CPU and I feel well-suited for it, although 
there are still some things I'm learning about it.


Gareth aka. Kit


___
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] inline... and philosophy

[Michael Van Canneyt]

On Sun, 10 Nov 2019, J. Gareth Moreton wrote:

This message chain has proven to be a lot more educational and 
insightful than I would have given it credit for.  Thanks everybody!


I know a lot of the time, the size of binaries is just an illusion, 
along with unfair comparisons with GCC (a behemoth with corporate 
support) and Microsoft Visual C++ that often hides the size of binaries 
behind a redistributable library.  I don't ever seek to make binaries 
smaller at the expense of speed, but if I see a potential saving that 
could be done automatically, I dive for it!


On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)


I did try to start simple with the 'uComplex' unit, but concerns were 
raised because I changed the formal parameters to 'const' and aligned 
the complex type on x86-64 platforms so it can take advantage of XMM 
registers better (which, given proper optimisation, would result in both 
smaller code size and higher speed).  While I made sure that the 
interfaces would not change for Pascal code, assembler code that calls 
the functions (if it exists) might need to be changed slightly 
(something Florian raised).  I'm not quite sure what the rules are when 
it comes fo updating packages, other than the obvious one of not 
breaking old code.


I think Marco referred to dynamically loadable packages (aka run-time
packages)

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

Re: [fpc-devel] inline... and philosophy

[J. Gareth Moreton]

This message chain has proven to be a lot more educational and 
insightful than I would have given it credit for.  Thanks everybody!


I know a lot of the time, the size of binaries is just an illusion, 
along with unfair comparisons with GCC (a behemoth with corporate 
support) and Microsoft Visual C++ that often hides the size of binaries 
behind a redistributable library.  I don't ever seek to make binaries 
smaller at the expense of speed, but if I see a potential saving that 
could be done automatically, I dive for it!


On 10/11/2019 14:47, Marco van de Voort wrote:
(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)


I did try to start simple with the 'uComplex' unit, but concerns were 
raised because I changed the formal parameters to 'const' and aligned 
the complex type on x86-64 platforms so it can take advantage of XMM 
registers better (which, given proper optimisation, would result in both 
smaller code size and higher speed).  While I made sure that the 
interfaces would not change for Pascal code, assembler code that calls 
the functions (if it exists) might need to be changed slightly 
(something Florian raised).  I'm not quite sure what the rules are when 
it comes fo updating packages, other than the obvious one of not 
breaking old code.


I like working on optimisation because I have a morbid fascination with 
the lowest level of the CPU and I feel well-suited for it, although 
there are still some things I'm learning about it.


Gareth aka. Kit


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

Re: [fpc-devel] inline... and philosophy

[Marco van de Voort]

Op 09/11/2019 om 15:51 schreef J. Gareth Moreton:


Competitions aside, there are times where space is a premium, whether 
it be from distributing an application on a DVD, bandwidth or data 
limits (even some first world countries are still on dial-up in 
places, or are otherwise monopolised by a single, bad-quality 
provider), the smaller capacity of solid-state hard drives (especially 
on some laptops) and can otherwise be a money saver sometimes.


Maybe. But what the faq warnes against is in using these kind of 
scenarios to retroactive justify old dos era sentiments.  Even small 
SSDs are huge compared to FPC binaries, and the possible gains are 
really not that high. Constrained pipes usually already employ 
compression, and a few percent really doesn't save that much anyway.


It is not a bad thing to dive into binary sizes, but keep it to the 
point, and try to quantify savings in larger programs (e.g. the compiler 
or lazarus). Get a feel for what changes are worth it and what not, but 
be warned, there is much less to gain than people think.


(and btw, if you are serious about these scenarios, drop all 
optimization work immediately, and start working on packages :-)




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

Re: [fpc-devel] Capturing addresses

[Martin Frb]

On 10/11/2019 15:05, Jonas Maebe wrote:

On 10/11/2019 14:58, Martin Frb wrote:

So I am trying to understand what the difference (in terms of safety)
is? (except that the none "var param" is always unsafe, the "var param"
is only sometimes unsafe)?

If you are talking about the safety of accesses after the capturing
routine has exited, then that is indeed the only difference.

Ok then I am missing some (maybe internal?) detail. Not to important, 
just curiosity.

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

Re: [fpc-devel] Capturing addresses

[Jonas Maebe]

On 10/11/2019 14:58, Martin Frb wrote:
> So I am trying to understand what the difference (in terms of safety)
> is? (except that the none "var param" is always unsafe, the "var param"
> is only sometimes unsafe)?

If you are talking about the safety of accesses after the capturing
routine has exited, then that is indeed the only difference.

> Also out of interest, what would change if you ...
>> teach the compiler to be able to assume that addresses
>> of variables are not captured merely because they are passed by
>> reference 

It should allow the compiler to get rid of a lot of temporary function
results (and copying those temporary results to their final
destination), in particular for shortstring and set operations, and for
overloaded operators that work with records.


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

Re: [fpc-devel] inline... and philosophy

[Marco van de Voort]

Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel

 Most processors have a fairly large uop cache (up to 2048 for the newest

generations iirc), so this would only be for the first iteration? Do you
have a reference (agner fog page or so) or more explanation for this
that describes this?)

I have to revoke my statement. Don't have evidence to back up. Code, that lead 
me to thous conclusions, has been discarded.
  I have read most whats published in agner's fog page. There nothing to 
pinpoint as reference.
No prob. Was just interested, I had to do some sse/avx code the last 
years, and hadn't heard of this.

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

Re: [fpc-devel] Capturing addresses

[Martin Frb]

On 10/11/2019 14:36, Jonas Maebe wrote:

For example:

var
   g: longint;
   p: plongint;

procedure test(var l: longint);
begin
   p:=@l;
end;

begin
   test(g);
end.

After test() executes, p now contains the address of g (the '@' operator
does not return the address of g's address on the stack; it returns the
actual address of g). This means that g's address has been captured by
test(). This can obviously lead to wrong/dangerous situations, e.g. if g
was not a global variable, but a local variable of another procedure.
That said, it is a legal expression.


Your example shows the safe case (p is and will continue to be safe).

In the unsafe case (g to be a local var), this is similar to none "var 
param"


var
  p: plongint;
procedure test(l: longint);
begin
  p:=@l;
end;

p will be a dangling pointer, after "test" exited.
The same as in your example, but with the case that "g" is local, p 
becomes dangling when "g" goes out of scope.


So I am trying to understand what the difference (in terms of safety) 
is? (except that the none "var param" is always unsafe, the "var param" 
is only sometimes unsafe)?


Also out of interest, what would change if you ...

teach the compiler to be able to assume that addresses
of variables are not captured merely because they are passed by
reference


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

Re: [fpc-devel] inline... and philosophy

[Mattias Gaertner via fpc-devel]

On Sun, 10 Nov 2019 02:23:03 +
"J. Gareth Moreton"  wrote:

> Does the smart linker strip out LCL components that are not used, or 
> must everything that's registered in a package or unit be included? 

If you mean with "registered" the RegsiterClass or RegisterComponents
functions:
If it is registered the compiler must include it.
Usually the LCL components are only registered by designtime code.


> Granted, since forms are being read from a resource file, I doubt it
> can really be tied into the compiler that closely.


Mattias


> 
> Gareth aka. Kit
> 
> On 09/11/2019 15:50, Sven Barth via fpc-devel wrote:
> > J. Gareth Moreton  > > schrieb am Sa., 9. Nov. 2019,
> > 16:20:
> >
> >
> > On 09/11/2019 15:14, Michael Van Canneyt wrote:  
> > >
> > >
> > > On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
> > >  
> > >> Competitions aside, there are times where space is a
> > >> premium,  
> > whether  
> > >> it be from distributing an application on a DVD, bandwidth
> > >> or data limits (even some first world countries are still on
> > >> dial-up in places, or are otherwise monopolised by a single,
> > >> bad-quality provider), the smaller capacity of solid-state
> > >> hard drives (especially on some laptops) and can otherwise
> > >> be a money saver sometimes.  
> > >
> > > I tend to think more size gains can be obtained from more  
> > aggressive  
> > > smartlinking.
> > > The smartlinking is sometimes disabled by the way code is
> > > written.
> > >
> > > To give an example, pas2js has a switch to convert published
> > > to  
> > public  
> > > sections. As a result, the published sections are suddenly  
> > reduced to  
> > > what is actually used in code. This produces significant size
> > > gains.
> > >
> > > Michael.
> > > ___
> > > fpc-devel maillist  - fpc-devel@lists.freepascal.org  
> >   
> > > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> > >  
> > That's true.  That's mentioned in the "size matters" article. I
> > didn't
> > know about 'published' until then.  Presumably, if that switch
> > doesn't
> > exist (like with most of the LCL), I gather the only way to
> > strip out those unused published sections is some very intelligent
> > whole-program
> > optimisation, and even then it may not work if a string (to
> > access a property name) is not deterministic.
> >
> >
> > For the LCL it's simply not possible, because it relies heavily on
> > the RTTI. And in the future that will only increase with extended
> > RTTI.
> >
> > Regards,
> > Sven
> >
> >
> > ___
> > 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] Capturing addresses

[Jonas Maebe]

Hi,

Does anyone know what the accepted/excepted behaviour is regarding the
capture of addresses of var/out/const-by-address/constref parameters?

For example:

var
  g: longint;
  p: plongint;

procedure test(var l: longint);
begin
  p:=@l;
end;

begin
  test(g);
end.

After test() executes, p now contains the address of g (the '@' operator
does not return the address of g's address on the stack; it returns the
actual address of g). This means that g's address has been captured by
test(). This can obviously lead to wrong/dangerous situations, e.g. if g
was not a global variable, but a local variable of another procedure.
That said, it is a legal expression.

I would like to teach the compiler to be able to assume that addresses
of variables are not captured merely because they are passed by
reference. There will also be a switch to toggle this assumption,
because fortunately it the behaviour is completely defined by the callee
side (so if you know that a unit does this, compiling that unit
appropriately is sufficient to ensure it will always work correctly).

The question is: should the compiler by default assume that such
addresses are not captured, or that they are captured? Does anyone know
if a lot of code exists that does this?


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

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Florian Klämpfl]

Am 10.11.19 um 11:45 schrieb Jonas Maebe:

On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the 
sources.

See my mail to Florian. I have 1 application that has all the tests. It's
easy to navigate & whatnot.


The nice thing about your punit-based tests is that they can just as 
easily be used in a single test application as in multiple individual 
test applications. Since the testsuite only tries to compile and execute 
source files starting with "t", there would be no problem with also 
adding your single top-level application there as long as its name 
starts with another character.


We could even have just the single top-level application in the 
testsuite (along with all of the individual subject tests as units, like 
it was in the code you added to svn), since for testing unit 
functionality having separate test programs is indeed less important 
(and it's still very easy to make one if it is necessary for some reason 
at one point).


The funny part of this discussion is: if we add all system unit tests 
into Michael's scheme and his single test application, running this 
single test would probably more time than running currently all 
regression tests. theapthread testing heap management and threading 
takes alone 35 sec :)

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

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Florian Klämpfl]

Am 10.11.19 um 10:54 schrieb Michael Van Canneyt:



On Sat, 9 Nov 2019, Jonas Maebe wrote:


On 09/11/2019 20:17, Michael Van Canneyt wrote:



On Sat, 9 Nov 2019, Jonas Maebe wrote:


I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.


With parallel compilation, it will be barely slower.


home:~/rtl> time retest Classes > out
3.400u 0.628s 0:04.02 100.0%    0+0k 0+33872io 0pf+0w

retest is the command I use. I redirected output. 3 seconds, and that
includes recompiling the RTL. All classes tests run.

home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out


As I mentioned, we could change it so that for running the hypothetical
tests_rtl target in tests directory, you would only have to compile 
the RTL.


No.

It's not just the waste of time, it's also the origanization of the 
sources.

See my mail to Florian. I have 1 application that has all the tests. It's
easy to navigate & whatnot. In the testsuite the tests are scattered 
over 100-ds of applications in which a cat cannot find her kitten. I 
wouldn't know how to find all tests

for a particular function apart from a grep X *.* */*.* */*/*.* etc. Not
particularly efficient.


All tests written for a certain unit written as "unit unit tests" are in 
tests/test/units/ (actually, tests/test contains in general 
unit tests - unit in the sense of testing - all other dirs are 
regression tests). Your test app could easily live there e.g. in 
tests/test/rtl if it is not split between different units. All test runs 
(nightly or manual) would pick it up.

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

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Jonas Maebe]

On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the 
sources.
See my mail to Florian. I have 1 application that has all the tests. 
It's

easy to navigate & whatnot.


The nice thing about your punit-based tests is that they can just as 
easily be used in a single test application as in multiple individual 
test applications. Since the testsuite only tries to compile and execute 
source files starting with "t", there would be no problem with also 
adding your single top-level application there as long as its name 
starts with another character.


We could even have just the single top-level application in the 
testsuite (along with all of the individual subject tests as units, like 
it was in the code you added to svn), since for testing unit 
functionality having separate test programs is indeed less important 
(and it's still very easy to make one if it is necessary for some reason 
at one point).



It's clear we won't find each other. I have removed the sources from
SVN since Florian didn't want the rtl cluttered and we'll leave it at
that.


The problems with this are
1) your tests never get run on all platforms, so things may be broken on 
platforms other than the ones you test
2) when someone else fixes a bug in or improves one of the tested 
routines, they may break on of your tests without realising (and without 
being able to easily test their changes, unless they write a test 
program similar to one you may already have and then add that to the 
testsuite themselves)



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

Re: [fpc-devel] inline... and philosophy

[Marģers . via fpc-devel]

> Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel:
> >
> > 3) it changes code location (code cross page boundaries). For my particular 
> > cpu there are 64 byte code page. If loop can fit in it, speed is twice as 
> > it overlaps even one byte over page boundary. Jumping forward is ok (as 
> > expected code flow is always forward). And there is lager page few kb - 
> > calling outside - small penalty.

> Most processors have a fairly large uop cache (up to 2048 for the newest
> generations iirc), so this would only be for the first iteration? Do you
> have a reference (agner fog page or so) or more explanation for this
> that describes this?)

I have to revoke my statement. Don't have evidence to back up. Code, that lead 
me to thous conclusions, has been discarded. 
 I have read most whats published in agner's fog page. There nothing to 
pinpoint as reference.

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

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Michael Van Canneyt]

On Sat, 9 Nov 2019, Jonas Maebe wrote:


On 09/11/2019 20:17, Michael Van Canneyt wrote:



On Sat, 9 Nov 2019, Jonas Maebe wrote:


I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.


With parallel compilation, it will be barely slower.


home:~/rtl> time retest Classes > out
3.400u 0.628s 0:04.02 100.0%    0+0k 0+33872io 0pf+0w

retest is the command I use. I redirected output. 3 seconds, and that
includes recompiling the RTL. All classes tests run.

home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out


As I mentioned, we could change it so that for running the hypothetical
tests_rtl target in tests directory, you would only have to compile the RTL.


No.

It's not just the waste of time, it's also the origanization of the sources.
See my mail to Florian. I have 1 application that has all the tests. It's
easy to navigate & whatnot. 
In the testsuite the tests are scattered over 100-ds of applications in 
which a cat cannot find her kitten. I wouldn't know how to find all tests

for a particular function apart from a grep X *.* */*.* */*/*.* etc. Not
particularly efficient.

You guys run & debug the compiler. I run & debug the test app. 
This is a fundamental difference in work cycle.


The compiler way is no way of working for me. 
I understand it suits you: fine, I don't stop you.


But please, never mind.

It's clear we won't find each other. I have removed the sources from SVN 
since Florian didn't want the rtl cluttered and we'll leave it at that.


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

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Michael Van Canneyt]

On Sat, 9 Nov 2019, Jonas Maebe wrote:


On 09/11/2019 20:17, Michael Van Canneyt wrote:

home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out
/usr/bin/ld: warning: x86_64/bin/x86_64-linux/link.res contains output
sections; did you forget -T?
119.139u 11.763s 1:47.32 121.9% 0+0k 179800+1292024io 2pf+0w

home:~/fpc> time make clean rtl packages > out
61.289u 4.929s 0:31.64 209.2%   0+0k 0+728024io 0pf+0w
home:~/fpc>

with -J7 and not even testuite run.


BTW, I don't see a -j 7 in the above commands. You should also add
FPMAKEOPT="-T 7" to parallises the compilation of the packages and utils
directories.


I have environment variables set so I don't need to specify that.

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

Re: [fpc-devel] inline... and philosophy

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am So., 10. Nov.
2019, 03:23:

> Does the smart linker strip out LCL components that are not used, or must
> everything that's registered in a package or unit be included? Granted,
> since forms are being read from a resource file, I doubt it can really be
> tied into the compiler that closely
>

As long as one doesn't include the function that does the Registration then
components that are not used should be smart linked away. Cause even if
you're reading from a resource file there is still the use of the component
inside the form's declaration and thus the compiler as its usage reference.
The only problematic part might be the widgetset backend itself where
things might not be able to be smartlinked away that nicely.

Regards,
Sven

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