Recent

Author Topic: A const attribute as a new optimization  (Read 4170 times)

Basile-B

  • Sr. Member
  • ****
  • Posts: 457
    • GH...
A const attribute as a new optimization
« on: July 07, 2016, 05:14:16 am »
As seen in other languages. If a method is marked as const then the contract is put that it won't mutate the other fields, thus the compiler can create a local variable when getter functions are used:
What we do now
Code: Pascal  [Select]
  1. TFoo = class
  2. private
  3.   function getItem: string;
  4. public
  5.   property item: string read getItem;
  6. end;
  7.  
  8. procedure bar(foo: TFoo);
  9. var
  10.   item: string;
  11. begin
  12.   for i:= 0 to 10 do
  13.   begin
  14.     item := foo.item; // caches because the compiler doesnt know that the getter has no side effect
  15.     stuff[i].thing := processItemInThatWay(item);
  16.     stuff[i].otherThing := processItemInTheOtherWay(item);
  17.   end;
  18. end;
could be
Code: Pascal  [Select]
  1. TFoo = class
  2. private
  3.   function getItem: string; const; // tells the compiler it doesnt mutate the state
  4. public
  5.   property item: string read getItem;
  6. end;
  7.  
  8. procedure bar(foo: TFoo);
  9. var
  10.   i: integer;
  11. begin
  12.   for i:= 0 to 10 do
  13.   begin
  14.     stuff[i].thing := processItemInThatWay(foo.item); // the compiler actually uses a local
  15.     stuff[i].otherThing := processItemInTheOtherWay(foo.item); // the same local is used here thanks to the "const" optimization.
  16.   end;
  17. end;

Leledumbo

  • Hero Member
  • *****
  • Posts: 8112
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: A const attribute as a new optimization
« Reply #1 on: July 07, 2016, 05:47:27 am »
AFAIK only C++ has such an "optimization". TBH, I'd rather choose the first one (explicit local variable).

Basile-B

  • Sr. Member
  • ****
  • Posts: 457
    • GH...
Re: A const attribute as a new optimization
« Reply #2 on: July 07, 2016, 06:07:12 am »
D has it too and the idea comes from it.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 670
Re: A const attribute as a new optimization
« Reply #3 on: July 07, 2016, 07:39:31 am »
If it's just about optimisation: such an attribute could be automatically deduced by the compiler and subsequently be applied in a whole program optimisation pass. Any property for the purpose of optimisation that (in theory) can be automatically deduced should not be made explicit in the language.

Such "const" modifiers can also be seen as part of an interface contract though (I know that if I call this method, the state of the instance will not be changed). The optimisation opportunities this brings are then just a side effect. I don't think that this information is useful enough to warrant a language extension (ideally, the language would be reduced rather than extended in the long term, but practically that is virtually impossible -- which is one of the reasons I'm extremely hesitant to add more extensions).

Basile-B

  • Sr. Member
  • ****
  • Posts: 457
    • GH...
Re: A const attribute as a new optimization
« Reply #4 on: July 07, 2016, 08:28:46 am »
It's true that FPC could, in most of the cases, deduce the const by looking at the content of the function but as a contract, "const" would prevent all the hard work for FPC the developpers, i.e: "if you put const then we suppose that you know what you do and the compiler doesn't check if you're right or wrong".

Also "const" couldn't be deduced from dll imports or functions interface for an object that's included, so using it as an attribute would make sense.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 670
Re: A const attribute as a new optimization
« Reply #5 on: July 07, 2016, 08:41:31 am »
Preventing work for compiler developers is the worst possible argument for extending a language. Once a language is extended, this can never be rolled back and every person that afterwards wants to use the language may have to learn about this extension at some point. It makes the language harder to learn, harder to use, harder to read, harder to maintain. In programming languages, less is more. Delphi-style Pascal is already way more complex than it should be as it is.

Furthermore, adding the extension in a way that the compiler doesn't even check whether it's correct is even worse. At least (modern) C++-compilers, and presumably D-compilers too, verify that const methods indeed do not mutate the state of the instance. The most important parts about a programming language is that it makes it easy to understand an already written program, and making it difficult to write buggy code. Performance is generally a very, very distant third (or fourth or fifth or sixth, coming after "making it easy to write programs", "making it easy to automatically analyse code", "making it easy to quickly parse/compile". ...). Having all of the aforementioned properties generally also automatically makes it easier to both write and generate (correct) fast code.

Finally, whole-program optimisation information could also be generated for dlls and objects and shipped together with them if that would be critical to performance when using them.

serbod

  • Full Member
  • ***
  • Posts: 127
Re: A const attribute as a new optimization
« Reply #6 on: July 07, 2016, 10:57:34 am »
Quote
If a method is marked as const then the contract is put that it won't mutate the other fields, thus the compiler can create a local variable when getter functions are used

In Pascal, "const" modifier assumes, that value passed by reference (same as "var"), but protected from writing by compiler. So, compiler not make writable copy of passed value and it's very good for optimization.

For function result, "const" meaningless, it's already constant outsile funtion and write-protected by design. If you need to pass constant value as variable parameter, you need assign constant value to some variable, as in your first example.

Real optimization for functions can be "locked" modifier, that:
- prohibits use of any global variables and objects inside function
- allow only value parameters
- allow only use of procedures and functions with value parameters

It gives thread-safe stack-based functional programming, by design.

Thaddy

  • Hero Member
  • *****
  • Posts: 9187
Re: A const attribute as a new optimization
« Reply #7 on: July 07, 2016, 11:08:56 am »
You forgot that const parameters also prevents reference counting to mess up. Probably the most important one for features like strings and classes.
also related to equus asinus.

Basile-B

  • Sr. Member
  • ****
  • Posts: 457
    • GH...
Re: A const attribute as a new optimization
« Reply #8 on: July 07, 2016, 12:19:44 pm »
For function result, "const" meaningless, it's already constant outsile funtion and write-protected by design. If you need to pass constant value as variable parameter, you need assign constant value to some variable, as in your first example.

It's not meaningless otherwise why would it exist in other languages ? I don't know if there's a misunderstanding here but I speak well about const as a function attribute, not as an attribute of the result. This would give a hint to the compiler: "if called many times in the scope the result can be put in a local variable that's automatically created".

Leledumbo

  • Hero Member
  • *****
  • Posts: 8112
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: A const attribute as a new optimization
« Reply #9 on: July 07, 2016, 03:05:17 pm »
"const" would prevent all the hard work for FPC the developpers, i.e: "if you put const then we suppose that you know what you do and the compiler doesn't check if you're right or wrong".
Bad, really bad, very bad argumentation to incorporate a feature that might be a source of bug. Thankfully as Jonas said, C++ implementation does check whether the code really doesn't modify any of the class member and if it does, it's a compile-time error. So no burden is actually lifted, instead, it's added. I believe Florian wouldn't like to have any feature that slows down compilation time without any significant benefit.

serbod

  • Full Member
  • ***
  • Posts: 127
Re: A const attribute as a new optimization
« Reply #10 on: July 09, 2016, 12:47:38 pm »
Some "sugar" - default value for function result:

Code: Pascal  [Select]
  1. function GetIndex(): integer = -1;
  2. function GetName(): string = 'not defined';
  3. function GetObject(): TObject = nil;
  4. function GetNextDateTime(): TDateTime = Now();
  5.  

Basile-B

  • Sr. Member
  • ****
  • Posts: 457
    • GH...
Re: A const attribute as a new optimization
« Reply #11 on: July 10, 2016, 10:02:44 pm »
Some "sugar" - default value for function result:

Code: Pascal  [Select]
  1. function GetIndex(): integer = -1;
  2. function GetName(): string = 'not defined';
  3. function GetObject(): TObject = nil;
  4. function GetNextDateTime(): TDateTime = Now();
  5.  

This has nothing to do with the topic but not a bad idea. Using this would guarantee a certain degree of safety, e.g no risk to forgot to set result in the function, although the compiler detects undefined result.