Discussion:
Attn Sven: New flags related to management operators
(too old to reply)
Maciej Izak
2018-06-20 21:41:52 UTC
Permalink
Hi Sven,

I saw the new commits related to Management Operators (I mean new flags
riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what
next.

When I was developing management operators (and FastRTTI related to speed
up things) I had in mind extensive expansion for management types in many
directions (nullable types, smart pointers and so one, FastRTTI is also
related to all managed types not only to management operators) and
optimizations to speed up things (in the final, generated code can be
faster even few times than current code, here I mean code with standard
managed types without any management operators).

The FastRTTI covers the needs of the optimization for constructors but also
moves things much forward (it depends on use case: from my tests is never
slower but always faster, for some cases even few times).

For example the new flags (riifNonTrivialChild and
riifParentHasNonTrivialChild) works good only when none of record with
"Initialize operator" is used as field, also worth to note that new
solution will be much slower in the future than FastRTTI when users will
decide to use more types backed by management operators (and the topic will
back again...).

Current flags are temporary solution or final thing? I have few things to
say

A. we have ready to use better/faster solution than riifNonTrivialChild
riifParentHasNonTrivialChild
B. current solution probably means also waste of memory for
TRecordInfoInitFlags when in the future someone decide to introduce other
optimizations related to RTTI and managed types (similar to FastRTTI)
C. also is possible to use less invasive version of FastRTTI (for example
can be used part related to Initialize operator only (this part is already
exposed outside FastRTTI structures and is generated always even when fast
RTTI is off) and the way for full FastRTTI will be opened without wast of
space for new flags...
D. Do we really want to use temporary solution? I think no - we should
looks forward.
E. FastRTTI is just beginning and can be expanded to more optimizations
F. if for some reasons you want to keep current solution (anyway IMO very
unwelcome for future things) may be worth to rename
TRecordInfoInitFlags because can be also used for other purposes not
related to initialization only. For example all flags defined for FastRTTI
can be moved into this flag... Anyway TRecordInfoInitFlags will be still
less efficient than FastRTTI for 8 and 16 bit platforms...
--
Best regards,
Maciej Izak
Sven Barth via fpc-devel
2018-06-21 20:09:45 UTC
Permalink
Post by Maciej Izak
Hi Sven,
I saw the new commits related to Management Operators (I mean new
flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I
wonder what next.
When I was developing management operators (and FastRTTI related to
speed up things) I had in mind extensive expansion for management
types in many directions (nullable types, smart pointers and so one,
FastRTTI is also related to all managed types not only to management
operators) and optimizations to speed up things (in the final,
generated code can be faster even few times than current code, here I
mean code with standard managed types without any management operators).
The FastRTTI covers the needs of the optimization for constructors but
also moves things much forward (it depends on use case: from my tests
is never slower but always faster, for some cases even few times).
For example the new flags (riifNonTrivialChild and
riifParentHasNonTrivialChild) works good only when none of record with
"Initialize operator" is used as field, also worth to note that new
solution will be much slower in the futurethan FastRTTI when users
will decide to use more types backed by management operators (and the
topic will back again...).
Current flags are temporary solution or final thing? I have few things
to say
A. we have ready to use better/faster solution
than riifNonTrivialChild riifParentHasNonTrivialChild
B. current solution probably means also waste of memory for
TRecordInfoInitFlags when in the future someone decide to introduce
other optimizations related to RTTI and managed types (similar to
FastRTTI)
C. also is possible to use less invasive version of FastRTTI (for
example can be used part related to Initialize operator only (this
part is already exposed outside FastRTTI structures and is generated
always even when fast RTTI is off) and the way for full FastRTTI will
be opened without wast of space for new flags...
D. Do we really want to use temporary solution? I think no - we should
looks forward.
E. FastRTTI is just beginning and can be expanded to more optimizations
F. if for some reasons you want to keep current solution (anyway IMO
very unwelcome for future things) may be worth to rename
TRecordInfoInitFlags because can be also used for other purposes not
related to initialization only. For example all flags defined for
FastRTTI can be moved into this flag... Anyway TRecordInfoInitFlags
will be still less efficient than FastRTTI for 8 and 16 bit platforms...
We don't really know when your FastRTTI changes are going to be
integrated or if they are going to be integrated at all; the performance
of classes that don't have fields that use an Initialize operator needed
to be restored sooner rather than later. This is especially important as
on Core we've recently started talking about branching of 3.2 and even
though I've implemented my Flags based solution before that discussion
was started it's definitely an important point.
Also your FastRTTI approach and the Flags can coexist without problems
(and even complement each other) from what I've read in the thread where
you introduced your idea. That said I seriously doubt that the flags are
less efficient than FastRTTI for 8 and 16 bit platforms (where we had
said that FastRTTI isn't used by default) or even the 32 or 64 bit ones,
because with the flags no initialization aside from FillChar() is
executed at all for classes that contain managed types, but no types
with an initialize operator (while with the FastRTTI disabled the record
initialization would still be executed).

Regards,
Sven
Maciej Izak
2018-06-21 20:50:37 UTC
Permalink
2018-06-21 22:09 GMT+02:00 Sven Barth via fpc-devel <
We don't really know when your FastRTTI changes are going to be integrated
or if they are going to be integrated at all; the performance of classes
that don't have fields that use an Initialize operator needed to be
restored sooner rather than later. This is especially important as on Core
we've recently started talking about branching of 3.2 and even though I've
implemented my Flags based solution before that discussion was started it's
definitely an important point.
Also your FastRTTI approach and the Flags can coexist without problems
(and even complement each other) from what I've read in the thread where
you introduced your idea. That said I seriously doubt that the flags are
less efficient than FastRTTI for 8 and 16 bit platforms (where we had said
that FastRTTI isn't used by default) or even the 32 or 64 bit ones, because
with the flags no initialization aside from FillChar() is executed at all
for classes that contain managed types, but no types with an initialize
operator (while with the FastRTTI disabled the record initialization would
still be executed).
Sven you are wrong, flags for this case are less efficient for 8 and 16 bit
platforms and not only for this platforms. This is also true even for other
platforms even when FastRTTI is off. This is because

RecordRTTI(Instance,Temp,@int_initialize);

is never called even for disabled FastRTTI. Instead of this in the place of
current RecordRTTI call is used

https://github.com/maciej-izak/freepascal/blob/fastrtti/rtl/inc/objpas.inc#L392-L396

here is used simple table of all initialize operators to call. This table
is always generated as special part of INIT RTTI (independent from other
FastRTTI stuff) for maximal performance of this critical RTL part. The
pointer to table of all initialize operators is in the place of current new
field "Flags: TRecordInfoInitFlags;". No need for redundant call to RecordRTTI
which dose many redundant things like initialization for already
initialized managed fields and many potential calls to next RecordRTTI...

Coexistence of both has no sense - information stored in Flags will be
useless, this info is for sure not complement :( .

I can propose to adjust all needed things in FastRTTI patch before 3.2
branching, I think this will be good for all (FPC will be much faster in
many areas than Delphi!) . I have just few minor things to finish (one day
of work?).

The patch was tested for all platforms: 8bit, 16bit, 32, 64 also for big
endian without single regression. Additionally patch was tested with all
available very strict mORMot tests, so I think FastRTTI is really stable.
--
Best regards,
Maciej Izak
Maciej Izak
2018-06-22 19:08:48 UTC
Permalink
Post by Maciej Izak
Coexistence of both has no sense - information stored in Flags will be
useless, this info is for sure not complement :( .
I see 4 options:

1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" branch (only table with
initialization operators and related compiler and RTL part)
3. moving "Flags: TRecordInfoInitFlags;" into private section of record in
TypInfo module, it can be removed in the future (if needed) without
breaking backward compatibility for users code
4. all will stay as-is (the worst scenario)

The option 2 seems optimal (no redundant/useless actions/calls in
constructors).
--
Best regards,
Maciej Izak
Maciej Izak
2018-06-27 11:02:17 UTC
Permalink
Post by Maciej Izak
1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" branch (only table with
initialization operators and related compiler and RTL part)
3. moving "Flags: TRecordInfoInitFlags;" into private section of record in
TypInfo module, it can be removed in the future (if needed) without
breaking backward compatibility for users code
4. all will stay as-is (the worst scenario)
The option 2 seems optimal (no redundant/useless actions/calls in
constructors).
Ping? Would be good to know what you decide.
--
Best regards,
Maciej Izak
Sven Barth via fpc-devel
2018-06-28 20:10:20 UTC
Permalink
Post by Maciej Izak
1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" branch (only table
with initialization operators and related compiler and RTL part)
3. moving "Flags: TRecordInfoInitFlags;" into private section of
record in TypInfo module, it can be removed in the future (if
needed) without breaking backward compatibility for users code
4. all will stay as-is (the worst scenario)
The option 2 seems optimal (no redundant/useless actions/calls in
constructors).
Ping? Would be good to know what you decide.
Sorry that it took me so long, but I wanted to reread your proposed
FastRTTI changes before deciding and I only found the time this evening.

I'm currently indeed leaning towards option 2.
If you want to prepare this you can of course do it in a way that allows
to easily add in your other FastRTTI changes at a later date (though
those are still a bit up for debate (lessthe principal idea, more the
concrete implementation)).

Regards,
Sven
Maciej Izak
2018-06-29 09:53:52 UTC
Permalink
2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel <
Post by Sven Barth via fpc-devel
Sorry that it took me so long, but I wanted to reread your proposed
FastRTTI changes before deciding and I only found the time this evening.
I'm currently indeed leaning towards option 2.
This is good info.
Post by Sven Barth via fpc-devel
If you want to prepare this you can of course do it in a way that allows
to easily add in your other FastRTTI changes at a later date (though those
are still a bit up for debate (lessthe principal idea, more the concrete
implementation)).
This is good info too. So we can keep all gathered information about
"managed things" in compiler without producing final FastRTTI (only
mentioned table of initialization operators - which is special).

I agree that implementation in details may change and is for debate.

In early July I will prepare code base for both : FPC trunk and NewPascal,
and I will continue development of FastRTTI:

- integration with NewPascal for current layout of FastRTTI, which can be
changed/adjusted at any time.

also some new directions (also partially related to FastRTTI):

- inline management operators
- inline initialization for managed fields, local managed variables
(probably this can provide a lot of additional performance on user request).

This shows that NewPascal as "bleeding edge technology" (anyway tested with
all available tests) is a good idea. :)

I will for sure adjust FastRTTI, when I will get any feedback from you (or
any other core developer). It is very good that will be possible to keep
single code base in this matter.
--
Best regards,
Maciej Izak
Loading...