64-bit SuperCore Timestamp Per Target Evaluation Request
sebastian.huber at embedded-brains.de
Fri Nov 16 10:00:03 UTC 2012
I want to re-evaluate the change to 64-bit time stamps on nearly all architectures.
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:
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:
> 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
> 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.
More information about the users