64-bit SuperCore Timestamp Per Target Evaluation Request

[Sebastian Huber]

Hello,

I want to re-evaluate the change to 64-bit time stamps on nearly all architectures.

http://git.rtems.org/rtems/commit/?id=9c121991d719a37fba3a853fe43624818acbca85

It is true that the time related functions that only increment the time are 
more efficient with 64-bit time stamps, but we have severe problems if we 
operate with seconds.  One issue due to that was resolved with this patch:

http://git.rtems.org/rtems/commit/?id=c34bb0dcfa8ba1294cd5182349e1ddbe34f81bf4

Every application that uses time(), gettimeofday(), etc. must now perform at 
least one 64-bit division.  This operation is VERY expensive on some 
architectures.  The network stack uses also a seconds since boot value to do 
some timeout management (used in ether_output() for nearly each Ethernet packet).

I want to change all architectures back to (in cpu.h):

#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE

On 12/09/2008 10:26 PM, Joel Sherrill wrote:
> Hi,
>
> This is long but important so please take the time
> to read to the bottom.
>
> I just committed the last of a series of patches
> which adds the SuperCore Timestamp handler and
> the capability for a CPU port to pick one of three
> implementations of SuperCore Timestamps:
>
> + struct timespec (current implementation
> + int64_t (method not inlined)
> + int64_t (methods inlined)
>
> The int64_t is used for nanoseconds since POSIX epoch (1970)
> and can represent ~200 years.
>
> I have done extensive testing on SPARC/sis and PowerPC/psim
> to determine the impact of each implementation.  I hope the
> committed code reflects this. :)  I used tm26 (Thread Dispatch)
> and tm02 (semaphore obtain blocking as reference performance
> measurements
>
> On PowerPC/psim the following numbers are in instructions:
>
>                           timespec  int64  inlined int64
>      dispatch:              446      446      400
>      blocking sem obtain:   627      626      581
>
> On SPARC/sis, the following numbers are in microseconds:
>
>                           timespec  int64  inlined int64
>      dispatch:               59       61       53
>      blocking sem obtain:    98      100       92
>
> This means that (on THESE TARGETS) inlined int64_t results
> in ~7.5% faster blocking semaphore obtains and about 10% off
> any thread dispatch that context switches.  This impact a lot
> of thread operations.
>
> Since inlined int64_t operations appear to be faster, they
> may be a better choice on some targets.  However, there is
> a size issue I need to look into.  The minimum executable is
> slightly smaller with int64_t but ticker is larger. The timespec
> math was optimized for clock tick so maybe the int64_t math
> just is heavier there.  I don't know.
>
> The code is now committed to the CVS trunk.  It would be
> helpful to get feedback on other targets as to the impact.
> For now, you will have edit
> cpukit/score/include/rtems/score/timestamp.h to switch
> between the alternatives.
>
> I am convinced that the best choice for each target will
> need to be selected.  On targets like the PowerPC where
> code space is not an issue, inlined int64_t is probably
> the best choice.  But others may not show the performance
> benefit or memory may be at a premium (e.g. Thumb) so
> a different choice may be apprpriate.
>
> Please pitch in and provide feedback.
>


-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.