RTEMS Applications Supplement - timing figures for rtems_message_queue_receive

[Joel Sherrill]

On 02/21/2011 09:45 AM, Matthew McBraida wrote:
>
> Hi All,
>
> I am confused with the timing figures for rtems_message_queue_receive 
> given in section 10.11 of the “RTEMS SPARC Applications Supplement”. 
>   (Actually, the format is similarly puzzling in the versions of this 
> document for all CPU architectures that I checked).  – This function 
> performs a memcpy of the message data to the user provided buffer, 
> which presumably will be the main driver of the execution time for 
> this function.  Can anyone clarify?  (e.g. What is the message size 
> assumed in these timing figures?)
>
The code is in testsuites/tmtests in a handful of tests.  The message
size is 16 bytes.

Yes if you send around VERY large messages the time will vary quite
a bit.  Although not in the current tree, we did experiments early on
that showed that the time does not grow as fast as you would expect.
There was not that much difference between a 16-byte message and
a 128 byte message in time.  In a simple but decent memcpy, the loop is:

ld
st
inc
cmp/be

5 pseudo-instructions per 4-bytes.
16 bytes takes 4 * 5 =20 instructions.
128 bytes takes 32 * 5 = 160 instructions.

That's 140 instructions.  For cycles, on an ERC32 this
is what the C compiler generates for a crude loop.

.LL3:
         ld      [%o1+%g2], %g1
         st      %g1, [%o0+%g2]
         addcc   %o2, -1, %o2
         bne     .LL3
          add    %g2, 4, %g2

3 cycles for ld, 2 for st, 2 for branch with
the add in the delay slot.  Total is 7 cycles
per 4 bytes.

28 cycles for 16-bytes
224 for 128 bytes

At 10 Mhz, that's 2.8 usecs and 22.4 usecs

Unless your messages are huge or your CPU is incredibly
slow, the variation just wasn't worth benchmarking.

But we would be happy to have tests submitted
that show the increase.  It is a change but across what
I would consider the "normal and reasonable" size of
messages is pretty small.


> Thanks,
>
> Matt
>
> SciSys UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
> Before printing, please think about the environment.
> <#>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985