It is nowadays enabled by default, which means that we do one full copy
per write *and* -- in cases like the ReadOnlyPointer -- we keep hold on
a sample.
My guess was that it has been turned ON so that people get
RT-friendliness even without knowing it, as connections get initialized
by the last written sample.
I implemented on rock-rtt a separation of "initialization sample" and
"last written sample" so that we don't need to copy all written samples
just to get the nice-to-RTness effect. If my guess is write, I could
turn off keeps_last_written_sample by default, and only keep the first
written sample for initialization purposes.
Would that be acceptable ? Or is there another general use-case that
mandates having keeps_last_written_value ON by default ?
About keeps_last_written_value on input ports
On Wed, Feb 2, 2011 at 12:57 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> It is nowadays enabled by default, which means that we do one full copy
> per write *and* -- in cases like the ReadOnlyPointer -- we keep hold on
> a sample.
>
> My guess was that it has been turned ON so that people get
> RT-friendliness even without knowing it, as connections get initialized
> by the last written sample.
Well, yes, keeplastwrittenvalue was (ab)used for that and that's why we turn
it on by default. Also, the taskbrowser uses this during 'ls' to learn the last
sample written to a given output port.
>
> I implemented on rock-rtt a separation of "initialization sample" and
> "last written sample" so that we don't need to copy all written samples
> just to get the nice-to-RTness effect. If my guess is write, I could
> turn off keeps_last_written_sample by default, and only keep the first
> written sample for initialization purposes.
>
> Would that be acceptable ? Or is there another general use-case that
> mandates having keeps_last_written_value ON by default ?
The taskbrowser is the only thing I can think of. I don't mind splitting both
principles (init & keep) for starters. The reason we made it 'on' a
default is that
'off' is an optimization, you'll only turn 'keep' off if you can't afford it.
In the end, I tend to think that 'keep' is a deployment choice and not so much
a component/default choice...
Peter
About keeps_last_written_value on input ports
On 02/02/2011 02:07 PM, Peter Soetens wrote:
>> I implemented on rock-rtt a separation of "initialization sample" and
>> "last written sample" so that we don't need to copy all written samples
>> just to get the nice-to-RTness effect. If my guess is write, I could
>> turn off keeps_last_written_sample by default, and only keep the first
>> written sample for initialization purposes.
>>
>> Would that be acceptable ? Or is there another general use-case that
>> mandates having keeps_last_written_value ON by default ?
>
> The taskbrowser is the only thing I can think of. I don't mind splitting both
> principles (init& keep) for starters. The reason we made it 'on' a
> default is that
> 'off' is an optimization, you'll only turn 'keep' off if you can't afford it.
My experience with RTT2 is that these "optimizations" are actually VERY
important.
We reduced our CPU load dramatically by removing most of the copying
around that
RTT2 does.
> In the end, I tend to think that 'keep' is a deployment choice and not so much
> a component/default choice...
I would agree with that.
--
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev