Peter Soetens wrote:
> On Fri, May 14, 2010 at 15:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>> wrote:
>
> Peter Soetens wrote:
>
> On Fri, May 14, 2010 at 10:10, Sylvain Joyeux
> <sylvain [dot] joyeux [..] ... sylvain [dot] joyeux [..] ...>
> <mailto:sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>> wrote:
>
> Peter Soetens wrote:
>
> These three points combined allow for very powerful
> introspection, but also a
> combinatory(!) explosion of generated code. The
> remedies are few:
>
> 1) play with 'extern template' definitions for each type T.
> This will reduce
> amount of generated code in user code (ie components), but
> won't stop the
> emission when building the typekits
> 2) hide internal data structures behind a void* api,
> such that
> less templated
> classes are needed. This has the disadvantage that you
> can't
> copy void* data
> (no access to copy constructor), only pass the pointer,
> which
> limits its
> applicability.
> 3) Rework the datasource API such that the [const] T [&]
> variants are no longer
> needed. This is basically changing the return type of
> DataSource<T>::get() to
> const& T instead of T.
>
> Even with these changes, it's now clear that the
> Method/Operation API produces
> more code than the Method/Command API of 1.x. It's more
> powerful, at a price. I
> think this change was the 'tipping point' that caused the
> slow-downs to get
> annoying.
>
> For the record, oroGen already uses "extern template" to reduce
> code and compilation size. I had to make it emit the bunch of
> templates on a per-type file (i.e. there is one file that emits
> all the needed templates for one type). It has multiple
> advantages: each file requires less code, and -jX speeds up
> compilation.
>
> All and all, maybe we should investigate how to reduce the
> amount
> of templating. I know that templating is cool, but it has a
> lot of
> drawbacks as well (obviously).
>
>
> I'd like to use templates as 'code generators' but only for
> type specific stuff, ie, for stuff for which a real code
> generator would generate code too anyway. Basically, this
> boils down to putting as much as possible in template-less
> base classes and write infrastructure code (like transports)
> that is type independent.
>
> The new data flow code actually violated this rule, since
> channels, factories and channels are type specific, while only
> the port and the storage should be. We're suffering from the
> rule that user data must be usable, even when it's not in the
> type system. The only solution to that are dropping that
> 'freedom' OR using external templates and then linking with
> the typekit, as orogen does.
>
> Maybe we should consider dropping that.
>
>
>
> That's 4917 functions generated for 1 user type (in 463
> classes). This is
> without the serialization or transport but with scripting
> support. All the
> numbers (except class count) above go in half if you enable
> -O3. It's still
> huge.
> I wonder which priority should be set first now. I'm very
> close to the serialization code generation now,
> tackling the
> above issue first would delay
> that again with a week. On the other hand, I find
> myself more
> and more applying
> tricks (disable tests or functionality) to speed up
> compilation time when
> iterating.
>
> I'll play the devil's advocate, but maybe introducing yet
> another
> templating engine (boost serialization) is not really the best
> thing ever, since we already have this problem, no ?
>
> Moreover, I just realized something:
>
> template<class Archive>
> void serialize(Archive& a, Mystruct& m) {
> a & BOOST_NVP("a",m.a);
> a & BOOST_NVP("b",m.b);
> a & BOOST_NVP("c",m.c);
> a & BOOST_NVP("stamps", boost::make_array(m.stamps,10) );
> }
>
> *is* a template !
>
> It means that, if we want to reuse the serialize methods across
> typekit (and we want to !), we will have to get all the
> serialize
> methods in headers and recompile them for every typekit.
> *Really*
> not nice. Or not reuse them, but that stinks a bit.
>
>
> The default typekit can offer this functionality to all other
> extensions such as transports. Serialization to/from binary is
> now done in the MQueue transport, but we could migrate it to
> the typekit. Mqueue is a good example of a pain point: we need
> to compile an mqueue type transport for every user type, ie a
> lot of duplication, what we want is that mqueue should just be
> able to get the data in a binary form from the typekit itself.
> If we solve this, the boost::serialization template is only
> used by the typekit, so not much duplication there anymore.
> But I 100% share your concerns...
>
> Not true.
>
> The issue is that we combine types. I.e. one will have *in one
> typekit* to generate the serialize method for, let's say, an
> image. Then, in another toolkit, it will desire to transmit two
> frames for a stereocamera. Ideally, the second typekit should be
> able to reuse the serialize methods from the first typekit.
>
>
> well, that's what the serialize() function certainly does, it reuses
> the serialize() methods from each contained type. It's also how the
> typekits work, ie, that's why we had to register both Points32 and
> ChannelFloat32 in the example. On the other hand, on the ros-dev
> mailinglist, it was said that the best performance was obtained when
> the whole type serialization was inlined as much as possible, which is
> what they obtained on the 1.1 development branch.
What I was talking about is reusing serialize<> methods *across
typekits*. The only way to do that would be to have all serialize
methods available at compile time, which will probably lead to a code
explosion.

As for the efficiency. My POV there is that, when serializing small
types, it does not really matter (very fast to serialize anyway). If
you serialize big types, most of the performance cost will be
concentrated in one big "thing" (array, vector, data structure), which
is serialized by one serialization method anyway.

I.e. I am a bit skeptical about the "best performance" claim above. Did
they give you real numbers ?

Peter Soetens wrote:
> On Fri, May 14, 2010 at 15:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>> wrote:
>
> Peter Soetens wrote:
>
> On Fri, May 14, 2010 at 10:10, Sylvain Joyeux
> <sylvain [dot] joyeux [..] ... sylvain [dot] joyeux [..] ...>
> <mailto:sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>> wrote:
>
> Peter Soetens wrote:
>
> These three points combined allow for very powerful
> introspection, but also a
> combinatory(!) explosion of generated code. The
> remedies are few:
>
> 1) play with 'extern template' definitions for each type T.
> This will reduce
> amount of generated code in user code (ie components), but
> won't stop the
> emission when building the typekits
> 2) hide internal data structures behind a void* api,
> such that
> less templated
> classes are needed. This has the disadvantage that you
> can't
> copy void* data
> (no access to copy constructor), only pass the pointer,
> which
> limits its
> applicability.
> 3) Rework the datasource API such that the [const] T [&]
> variants are no longer
> needed. This is basically changing the return type of
> DataSource<T>::get() to
> const& T instead of T.
>
> Even with these changes, it's now clear that the
> Method/Operation API produces
> more code than the Method/Command API of 1.x. It's more
> powerful, at a price. I
> think this change was the 'tipping point' that caused the
> slow-downs to get
> annoying.
>
> For the record, oroGen already uses "extern template" to reduce
> code and compilation size. I had to make it emit the bunch of
> templates on a per-type file (i.e. there is one file that emits
> all the needed templates for one type). It has multiple
> advantages: each file requires less code, and -jX speeds up
> compilation.
>
> All and all, maybe we should investigate how to reduce the
> amount
> of templating. I know that templating is cool, but it has a
> lot of
> drawbacks as well (obviously).
>
>
> I'd like to use templates as 'code generators' but only for
> type specific stuff, ie, for stuff for which a real code
> generator would generate code too anyway. Basically, this
> boils down to putting as much as possible in template-less
> base classes and write infrastructure code (like transports)
> that is type independent.
>
> The new data flow code actually violated this rule, since
> channels, factories and channels are type specific, while only
> the port and the storage should be. We're suffering from the
> rule that user data must be usable, even when it's not in the
> type system. The only solution to that are dropping that
> 'freedom' OR using external templates and then linking with
> the typekit, as orogen does.
>
> Maybe we should consider dropping that.
>
>
>
> That's 4917 functions generated for 1 user type (in 463
> classes). This is
> without the serialization or transport but with scripting
> support. All the
> numbers (except class count) above go in half if you enable
> -O3. It's still
> huge.
> I wonder which priority should be set first now. I'm very
> close to the serialization code generation now,
> tackling the
> above issue first would delay
> that again with a week. On the other hand, I find
> myself more
> and more applying
> tricks (disable tests or functionality) to speed up
> compilation time when
> iterating.
>
> I'll play the devil's advocate, but maybe introducing yet
> another
> templating engine (boost serialization) is not really the best
> thing ever, since we already have this problem, no ?
>
> Moreover, I just realized something:
>
> template<class Archive>
> void serialize(Archive& a, Mystruct& m) {
> a & BOOST_NVP("a",m.a);
> a & BOOST_NVP("b",m.b);
> a & BOOST_NVP("c",m.c);
> a & BOOST_NVP("stamps", boost::make_array(m.stamps,10) );
> }
>
> *is* a template !
>
> It means that, if we want to reuse the serialize methods across
> typekit (and we want to !), we will have to get all the
> serialize
> methods in headers and recompile them for every typekit.
> *Really*
> not nice. Or not reuse them, but that stinks a bit.
>
>
> The default typekit can offer this functionality to all other
> extensions such as transports. Serialization to/from binary is
> now done in the MQueue transport, but we could migrate it to
> the typekit. Mqueue is a good example of a pain point: we need
> to compile an mqueue type transport for every user type, ie a
> lot of duplication, what we want is that mqueue should just be
> able to get the data in a binary form from the typekit itself.
> If we solve this, the boost::serialization template is only
> used by the typekit, so not much duplication there anymore.
> But I 100% share your concerns...
>
> Not true.
>
> The issue is that we combine types. I.e. one will have *in one
> typekit* to generate the serialize method for, let's say, an
> image. Then, in another toolkit, it will desire to transmit two
> frames for a stereocamera. Ideally, the second typekit should be
> able to reuse the serialize methods from the first typekit.
>
>
> well, that's what the serialize() function certainly does, it reuses
> the serialize() methods from each contained type. It's also how the
> typekits work, ie, that's why we had to register both Points32 and
> ChannelFloat32 in the example. On the other hand, on the ros-dev
> mailinglist, it was said that the best performance was obtained when
> the whole type serialization was inlined as much as possible, which is
> what they obtained on the 1.1 development branch.
>
>
>
> I know that it sounds like I'm pushing for my own solution, but I
> think you should consider using typelib. Typelib is *not*
> template-based *at all*: it gets a in-memory representation of the
> types it manipulates and *dynamically* manipulates it. There is no
> representation needed at compile time.
>
>
> Typelib is certainly more advanced than the type system in RTT, but
> the only reason it doesn't use templates is because it relies on a
> code generator to emit that introspection code. Typelib knows that
> will be emitted in one compilation unit, the C++ template system we
> have today doesn't (Visual Studio has something like that though), so
> it emits code in every cu, with the known consequences.
No it does not.

Typelib is purely dynamic. You can load C type definitions (plus some
other stuff) *dynamically* and without any code generation. I originally
wrote typelib to interface *dynamically* with Genom components (at LAAS)
without requiring another code generation engine (which was the way to
go at LAAS).

The only thing for which typelib would require code generation is
writing C++ containers as std::map and std::set (reading them would
probably be OK though).

As for the Ruby/C++ discussion: typelib is *all* C++, there is only a
Ruby binding that makes its use easier. oroGen uses that binding to
access Typelib's functionality.

The only functionality that I plan to have only on the Ruby side is
gccxml import. But that would be to translate it into typelib's own XML
format so that the C++ side can read it.

On May 14, 2010, at 12:27 , Peter Soetens wrote:

> On Fri, May 14, 2010 at 15:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> Peter Soetens wrote:
>
> On Fri, May 14, 2010 at 10:10, Sylvain Joyeux <sylvain [dot] joyeux [..] ... sylvain [dot] joyeux [..] ...>> wrote:
>
> Peter Soetens wrote:
>
> These three points combined allow for very powerful
> introspection, but also a
> combinatory(!) explosion of generated code. The remedies are few:
>
> 1) play with 'extern template' definitions for each type T.
> This will reduce
> amount of generated code in user code (ie components), but
> won't stop the
> emission when building the typekits
> 2) hide internal data structures behind a void* api, such that
> less templated
> classes are needed. This has the disadvantage that you can't
> copy void* data
> (no access to copy constructor), only pass the pointer, which
> limits its
> applicability.
> 3) Rework the datasource API such that the [const] T [&]
> variants are no longer
> needed. This is basically changing the return type of
> DataSource<T>::get() to
> const& T instead of T.
>
> Even with these changes, it's now clear that the
> Method/Operation API produces
> more code than the Method/Command API of 1.x. It's more
> powerful, at a price. I
> think this change was the 'tipping point' that caused the
> slow-downs to get
> annoying.
>
> For the record, oroGen already uses "extern template" to reduce
> code and compilation size. I had to make it emit the bunch of
> templates on a per-type file (i.e. there is one file that emits
> all the needed templates for one type). It has multiple
> advantages: each file requires less code, and -jX speeds up
> compilation.
>
> All and all, maybe we should investigate how to reduce the amount
> of templating. I know that templating is cool, but it has a lot of
> drawbacks as well (obviously).
>
>
> I'd like to use templates as 'code generators' but only for type specific stuff, ie, for stuff for which a real code generator would generate code too anyway. Basically, this boils down to putting as much as possible in template-less base classes and write infrastructure code (like transports) that is type independent.
>
> The new data flow code actually violated this rule, since channels, factories and channels are type specific, while only the port and the storage should be. We're suffering from the rule that user data must be usable, even when it's not in the type system. The only solution to that are dropping that 'freedom' OR using external templates and then linking with the typekit, as orogen does.
> Maybe we should consider dropping that.

Better not, not without providing some extremely simple system to get user types across the wire. I suspect that you will get a user revolt otherwise ...

>
> That's 4917 functions generated for 1 user type (in 463
> classes). This is
> without the serialization or transport but with scripting
> support. All the
> numbers (except class count) above go in half if you enable
> -O3. It's still
> huge.
> I wonder which priority should be set first now. I'm very
> close to the serialization code generation now, tackling the
> above issue first would delay
> that again with a week. On the other hand, I find myself more
> and more applying
> tricks (disable tests or functionality) to speed up
> compilation time when
> iterating.
>
> I'll play the devil's advocate, but maybe introducing yet another
> templating engine (boost serialization) is not really the best
> thing ever, since we already have this problem, no ?
>
> Moreover, I just realized something:
>
> template<class Archive>
> void serialize(Archive& a, Mystruct& m) {
> a & BOOST_NVP("a",m.a);
> a & BOOST_NVP("b",m.b);
> a & BOOST_NVP("c",m.c);
> a & BOOST_NVP("stamps", boost::make_array(m.stamps,10) );
> }
>
> *is* a template !
>
> It means that, if we want to reuse the serialize methods across
> typekit (and we want to !), we will have to get all the serialize
> methods in headers and recompile them for every typekit. *Really*
> not nice. Or not reuse them, but that stinks a bit.
>
>
> The default typekit can offer this functionality to all other extensions such as transports. Serialization to/from binary is now done in the MQueue transport, but we could migrate it to the typekit. Mqueue is a good example of a pain point: we need to compile an mqueue type transport for every user type, ie a lot of duplication, what we want is that mqueue should just be able to get the data in a binary form from the typekit itself. If we solve this, the boost::serialization template is only used by the typekit, so not much duplication there anymore. But I 100% share your concerns...
> Not true.
>
> The issue is that we combine types. I.e. one will have *in one typekit* to generate the serialize method for, let's say, an image. Then, in another toolkit, it will desire to transmit two frames for a stereocamera. Ideally, the second typekit should be able to reuse the serialize methods from the first typekit.
>
> well, that's what the serialize() function certainly does, it reuses the serialize() methods from each contained type. It's also how the typekits work, ie, that's why we had to register both Points32 and ChannelFloat32 in the example. On the other hand, on the ros-dev mailinglist, it was said that the best performance was obtained when the whole type serialization was inlined as much as possible, which is what they obtained on the 1.1 development branch.

Performance isn't everything. A super fast product is useless if it doesn't do the job, or is too damn hard to use.

>
> I know that it sounds like I'm pushing for my own solution, but I think you should consider using typelib. Typelib is *not* template-based *at all*: it gets a in-memory representation of the types it manipulates and *dynamically* manipulates it. There is no representation needed at compile time.
>
> Typelib is certainly more advanced than the type system in RTT, but the only reason it doesn't use templates is because it relies on a code generator to emit that introspection code. Typelib knows that will be emitted in one compilation unit, the C++ template system we have today doesn't (Visual Studio has something like that though), so it emits code in every cu, with the known consequences.
>
> It will be certainly a topic at the rtt-dev meeting.

IIRC, typelib et al use Ruby. That for me is a strike against it, simply because my team members don't need yet another language to learn.

Only one of my several projects is truly CPU and/or RAM limited, so extra code (generated or template-related) isn't a huge deal for us. Yes, it is a pain, but we will live with it for an easily used tool.

YMMV
Stephen