[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