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 :)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
