[fpc-pascal] compile Link Smart option, is it -XX or -CX?

[Dennis]

According to http://www.freepascal.org/docs-html/prog/progse30.html

the smartlink option on the command line is -CX
but in Lazarus ver 1.42,
   Compilation and Linking
  Linking
  Link Smart is -XX


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

Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

Jeppe Johansen-3 wrote
> On 03/02/2016 12:48 AM, vfclists . wrote:
>>
>>
>> On 14 February 2016 at 10:06, Serguei TARASSOV <

> serge@

>  
> >  serge@

> >> wrote:
>> Another strange effect in FPC.
>> Only longint shows correct result. With the integer type the
>> optimizer seems to replace type with shortint (16-bits) and I see
>> 31902 instead of 4816030.
>>
>> Is there a reason for this, or is it a bug?
> The Integer type depends on what compiler mode you are in, and what 
> operating system. Sometimes it's 32bit and other times it's 16bit.

It was FPC 2.6.4 64 bits in FPC mode on Linux. See the sources to reproduce.
Change: 
TicketsCount: longint;
to
TicketsCount: integer;

Compile: fpc -O2 -Cr- HappyTickets.pas

Result: Found 31902 tickets. Elapsed time, msec: 203

I don't see any reason to use 16-bits integer in this code much less in
64-bits mode.

I don't test it yet in FPC 3.0 bit 3.0 has other problems with my test:
- changing the type of n1-n8 from 0..9 to longint increases the time by 10%
- changing the type of n1-n8 from 0..9 to integer doubles the time!

On the contrary, in Delphi 10 changing the type of n1-n8 from 0..9 to
integer decreases the time by 60% 




-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724403.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Jonas Maebe]

Serguei TARASSOV wrote on Thu, 03 Mar 2016:


Jeppe Johansen-3 wrote



The Integer type depends on what compiler mode you are in, and what
operating system. Sometimes it's 32bit and other times it's 16bit.


AFAIK it only depends on the compiler mode.


It was FPC 2.6.4 64 bits in FPC mode on Linux. See the sources to reproduce.
Change:
TicketsCount: longint;
to
TicketsCount: integer;

Compile: fpc -O2 -Cr- HappyTickets.pas

Result: Found 31902 tickets. Elapsed time, msec: 203

I don't see any reason to use 16-bits integer in this code much less in
64-bits mode.


The reason is, as always, compatibility. FPC mode started as an  
extension of the Turbo Pascal compatibility mode. In Turbo Pascal,  
integer is 16 bits. In Delphi, it's 32 bits, so both in Delphi and in  
ObjFPC modes, integer is 32 bits. Code that was written with integer =  
16 bits may no longer work the same if the size of the integer type is  
changed to 32 bits (especially if overflow checking is off).



I don't test it yet in FPC 3.0 bit 3.0 has other problems with my test:
- changing the type of n1-n8 from 0..9 to longint increases the time by 10%
- changing the type of n1-n8 from 0..9 to integer doubles the time!

On the contrary, in Delphi 10 changing the type of n1-n8 from 0..9 to
integer decreases the time by 60%


If you want to compare with Delphi, it's better to compile the program  
in Delphi mode. You should see the same 10% increase in FPC that you  
see when you change it to longint.



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

Re: [fpc-pascal] compile Link Smart option, is it -XX or -CX?

[Sven Barth]

Am 03.03.2016 09:26 schrieb "Dennis" :
>
> According to http://www.freepascal.org/docs-html/prog/progse30.html
>
> the smartlink option on the command line is -CX
> but in Lazarus ver 1.42,
>Compilation and Linking
>   Linking
>   Link Smart is -XX

They are different. -CX tells the compiler to compile units with smart
linking capability (though I'd need to check what exactly that entails),
while -XX enables smart linking.

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

Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

Jonas Maebe-2 wrote
> The reason is, as always, compatibility. FPC mode started as an  
> extension of the Turbo Pascal compatibility mode. In Turbo Pascal,  
> integer is 16 bits. In Delphi, it's 32 bits, so both in Delphi and in  
> ObjFPC modes, integer is 32 bits. Code that was written with integer =  
> 16 bits may no longer work the same if the size of the integer type is  
> changed to 32 bits (especially if overflow checking is off).
> ...
> If you want to compare with Delphi, it's better to compile the program  
> in Delphi mode. You should see the same 10% increase in FPC that you  
> see when you change it to longint.
> 
> Jonas

If I understood correctly, the FPC programmer in 2016 always should include
{$MODE DELPHI} or {$MODE ObjFPC} to avoid TurboPascal legacy that I use in
earlies 1990?
Ok, it's not so important, only a rhetorical question.

I retested in Delphi mode, the time is the same.
Changing type to integer with Delphi7 decrease the time from 215 to 155 msec
in my environment. FPC shows about 189 msec and the same 155 in delphi mode
with integer type.

So the default FPC mode seems to be significantly more slow than Delphi-mode
and ObjFPC-mode.



-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724406.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Jonas Maebe]

Serguei TARASSOV wrote on Thu, 03 Mar 2016:


If I understood correctly, the FPC programmer in 2016 always should include
{$MODE DELPHI} or {$MODE ObjFPC} to avoid TurboPascal legacy that I use in
earlies 1990?


FPC mode started in those same early 1990s. The first code that was  
written for this mode dates from that period as well.



Ok, it's not so important, only a rhetorical question.


On the contrary, it is fundamental. Changing defaults in existing  
language modes, or changing the default language mode that is used,  
would break existing code with as only reason that we wouldn't want to  
look bad when people use the compiler for the first time and don't  
realise what the default mode is/entails. We're not about projecting a  
particular image, we're about trying not to break things that already  
work as far as the language is concerned.


Look at how Inprise/CodeGear/... alienated many developers by (a.o.)  
breaking backwards compatibility all the time and pushing what was  
supposed to be the next greatest thing instead. It's just not fair to  
existing users, who mainly don't want their code to break (just like  
you with the with/property problem earlier on). Any improvements on  
top of that is gravy, but it's not the most important.



So the default FPC mode seems to be significantly more slow than Delphi-mode
and ObjFPC-mode.


It's unrelated to the compiler mode. However, performing 16 bit  
integer arithmetical instructions on a processor that is very  
inefficient at doing so (such as 32 and 64 bit Intel x86 processors  
running in 32 or 64 bit mode -- I don't know about AMD) can indeed be  
quite slow. Ideally, the compiler would internally "upgrade" those  
operations to 32/64 bit where possible, but it doesn't do so. The  
amount of 16 bit integer code that should run as fast as possible on  
32/64 bit x86 Intel processors is probably not that big either.



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

Re: [fpc-pascal] compile Link Smart option, is it -XX or -CX?

[Dennis Poon]

Sven Barth wrote:


Am 03.03.2016 09:26 schrieb "Dennis" >:

>
> According to http://www.freepascal.org/docs-html/prog/progse30.html
>
> the smartlink option on the command line is -CX
> but in Lazarus ver 1.42,
>Compilation and Linking
>   Linking
>   Link Smart is -XX

They are different. -CX tells the compiler to compile units with smart 
linking capability (though I'd need to check what exactly that 
entails), while -XX enables smart linking.


Regards,
Sven



Would you kindly elaborate?
If -XX is not set, does that mean Smart Link is disabled and even if -CX 
is set, it is ignored?


Dennis



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


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

Re: [fpc-pascal] compile Link Smart option, is it -XX or -CX?

[Tomas Hajny]

On Thu, March 3, 2016 12:12, Dennis Poon wrote:
> Sven Barth wrote:
>> Am 03.03.2016 09:26 schrieb "Dennis" > >:
>> >
>> > According to http://www.freepascal.org/docs-html/prog/progse30.html
>> >
>> > the smartlink option on the command line is -CX
>> > but in Lazarus ver 1.42,
>> >Compilation and Linking
>> >   Linking
>> >   Link Smart is -XX
>>
>> They are different. -CX tells the compiler to compile units with smart
>> linking capability (though I'd need to check what exactly that
>> entails), while -XX enables smart linking.
>>
>>
> Would you kindly elaborate?
> If -XX is not set, does that mean Smart Link is disabled and even if -CX
> is set, it is ignored?

Let's imagine a program consisting of unit Unit1 and the main program
ProgX. You need to add -CX when compiling Unit1 (either standalone or
implicitly together with ProgX) if you want to make sure that the compiled
binary representation of Unit1 allows smartlinking its code and data (i.e.
only including the needed parts of its code and data in the final program
using this unit). When compiling a program, -XX asks the linker to perform
smartlinking for all units (including e.g. RTL units, etc.) which are
compiled in a way allowing this. -XX has no effect if the units are not
prepared in a way allowing smartlinking (i.e. not compiled with -CX). At
the same time, -CX has no effect on the final program by itself.

Hope this helps

Tomas


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

Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

Jonas Maebe-2 wrote
> On the contrary, it is fundamental. Changing defaults in existing  
> language modes, or changing the default language mode that is used,  
> would break existing code with as only reason that we wouldn't want to  
> look bad when people use the compiler for the first time and don't  
> realise what the default mode is/entails. We're not about projecting a  
> particular image, we're about trying not to break things that already  
> work as far as the language is concerned.

I agree your point but with some limitations.
IMHO, the period of 10 years as a maximum is very sufficient for migration
or we stay with the old version of compiler and common libraries.
On other hands, there are different breaks of compatibility.
The TP mode can be applied globally by compiler switch and it solve the
problem of default mode.
But adding the functions/methods/properties to existing classes of common
libraries breaks the old code that should be rewritten (if the error is
detected by compiler).
The second case is really important because there is no workaround.




-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724410.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-02 23:12 GMT-03:00 silvioprog :

> On Tue, Mar 1, 2016 at 12:08 AM, Mazola Winstrol 
> wrote:
> [...]
>>
>> I apologize, it works.
>>
>
> Do you have plan to share it in some place like Github, Lazarus-CCR or as
> Lazarus generics demo? Just a idea, because this implementation sounds good.
>
>
Yes, sure! I dont know where to place yet. What you suggests?

I will send to list the final version in the next days for discussion.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[silvioprog]

On Thu, Mar 3, 2016 at 10:16 AM, Mazola Winstrol 
wrote:

> 2016-03-02 23:12 GMT-03:00 silvioprog :
>
>> On Tue, Mar 1, 2016 at 12:08 AM, Mazola Winstrol 
>> wrote:
>> [...]
>>>
>>> I apologize, it works.
>>>
>>
>> Do you have plan to share it in some place like Github, Lazarus-CCR or as
>> Lazarus generics demo? Just a idea, because this implementation sounds good.
>>
>>
> Yes, sure! I dont know where to place yet. What you suggests?
>
> I will send to list the final version in the next days for discussion.
>

I can ask FPC/Lazarus team to distribute it as a FPC, Lazarus or
Lazarus-CCR generics demo, otherwise you can send it to Github, something
like "github.com/mazofeifer/fpc-prw". :-)

-- 
Silvio Clécio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Access violation in an empty project declaring heaptrc

[silvioprog]

On Thu, Mar 3, 2016 at 4:05 AM, Sven Barth 
wrote:
[...]

> That is the memory that had been used before the memory manager of the
> heaptrc unit had been setup. Remember that there's first the System unit
> initialization and only then the initialization of the heaptrc unit.
>
Indeed. About the AV, I'm not sure if it is related to #29558
, because it happens even
with a empty project just declaring the heap unit.

-- 
Silvio Clécio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fpc 3.0 ansistring codepage behavior

[Seth Grover]

I am debugging an issue (x86_64 Linux platform) which I have in FPC 3.0
which I didn't have in 2.6.4. It is a complex project with a lot of
threading, custom memory management, etc., so it's not something I can
easily boil down at the moment. Generally it manifests itself in memory
corruption.

As I'm eliminating possibilities, I see often my crashes happen when
various ansistring conversions/setlengths/etc. are happening. As I read
http://wiki.freepascal.org/FPC_Unicode_support I can see that there were a
lot of changes that went into unicode support in 3.0, particularly with
making ansistrings codepage-aware.

I understand that if I'm doing things "right" with ansistrings, everything
will work correctly and transparently. However, I worry that there may be
places in our code where we are doing bad things with ansistrings that may
be the root of my problem.

To identify whether or not this is really the case, is there some way I can
use the  FPC compiler but have the behavior of ansistrings act like it did
in fpc 2.6.4? For example, can I do:

SetMultiByteConversionCodePage(CP_NONE);

or is there some kind of compiler flag I can set in my project? Or even if
I have to rebuild the compiler itself, can I have the old 2.6.4 ansistring
behavior in FPC 3.0?

Even if I had to change all of my ansistring declarations to rawbytestring
I could do that, although that would require me to touch more code and I'd
prefer to find some sort of flip-a-switch way to do it.

Thanks for your input,

-SG

--
Seth Grover

Be kind to all of your neighbors
Because they're just like you.
And you're nothing special
Unless they are too.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal