[fpc-devel] Class field reordering

[Skybuck Flying]

>>> I don't think this is a good idea.
>>>
>>> For example while debugging and looking at the memory in raw this would 
>>> lead to confusion.
>>
>> By knowing the order of the fields, you still don't know their exact 
>> offsets. If you want to know their address, print 
>> @classinstance.fieldname
>
> Yes but I do know the order of the fields which does help make some sense 
> of it. With your suggested optimizations it would become much more 
> confusing/mixed/shuffled.
>
> I also find it slightly strange how there is now an even bigger disconnect 
> between records and classes.

"
The whole point of classes is to offer abstraction. Again: if you don't want 
abstraction, don't use data structures that offer an abstraction.
"

I have a different view on programming languages and pascal. It's a tool to 
help generate code. The abstraction is to prevent tieing to a single 
instruction set/cpu/computer, but it's always nice if the 
result/instructions/data field can be compared to the high level code.

> I also wonder how much of an optimization it actually is ? Maybe 0.000001% 
> more performance ?

"
1) as mentioned in the original mail, the current transformation is 
implemented for saving memory, not for improving performance
"

This wasn't clear, it only mentions gaps. What kind of gaps ? Apperently you 
ment to minimize memory size, the opposite could also have been ment in the 
sense of optimizations to make fields fall on memory boundaries for perhaps 
increased fetch speed or something else.

Later performance optimization possibilities for the future are mentioned as 
well.

"
2) if it was done for performance reasons, some people already got up to 34% 
extra performance by doing exactly that: 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4009 (download 
the cached version of the paper, the original link no longer works)
"

I scanned over this document and it seems to mention "profiling 
information", it also mentions "compilers which can then use this profiling 
information to re-arrange fields".

To me it seems this optimization idea belongs in the realm of "profilers". 
It should be easy for a programmer to use such a profiling tool and make the 
necessary changes him/herself instead of complexifieing the compiler.

Perhaps someday these kinds of "complex optimization tricks" might backfire 
as well, because of different runs of the program or so, though usually 
there is some redline in a program.

How do you envision this profiling to be done with the free pascal compiler 
or did you think about "some kind of static offline optimization" ?

If the later how about this:

"
setup code:

access field 2.

access field 2

red loop:

forever access field1 then field2.
"

Without actually running the code and profiling it or analyzing the for 
loop, the static offline optimization trick would believe field2 is accessed 
the most while field1 is actually accessed the most first.

So could lead to wrong optimization results.

> I rarely inspect the binary equivalent of a class instance, so your 
> supposedly optimization is probably not a big deal, for records that would 
> be a different matter since these are used in all kinds of api's and 
> input/output situations.

"
As mentioned in the original mail, the transformation would only be applied 
to classes.
"

How is a record not an abstraction and a class is an abstraction, that's 
kinda weird/inconsistent ?!

>>> It's already bad that Delphi adds invisible fields to classes so they 
>>> cannot be simply dumped to disk... (virtual method table pointers ?) 
>>> this would make it even worse.
>>
>> If you want to program at an assembler level of abstraction, don't use 
>> high level language features.
>
> I see no reason why a high level language could not be used to produce 
> binary instructions and or files/data.

"
It can be used for that, as long as you don't use high level abstractions. 
The whole point of abstractions to get rid of any guarantees a far as 
implementation is concerned, in order to increase portability, programmer 
productivity and compiler optimization opportunities.
"

How about instead extending the pascal language description and specifieing 
that the order of the fields in the class and records must be the same in 
binary as well. This seems nice and constant and might allow some other 
functionalities in the future.

That is not to say that this supposedly optimization could be done and later 
then removed if this order extension is introduced.

Finally I do see some merit for free pascal compiler or any other compiler 
to generate some helpfull (debugging?) / profiling information (?) so that a 
profiler can report back to the user what source code fields are accessed 
and in what order... and how often to give some hints or suggestions to the 
programmer how to make the optimizations him/herself.

Some might even take fun in optimization code, but it can also be boring 
work, then again, after having done it a few times, perhaps programmers 
learn from it and become better programmers, instead of being left in the 
dark. That in itself being a better programmer is also a lovety goal and 
tools which stimulate that would have my preference then just a blackbox ;) 
:)

Bye,
  Skybuck :)