[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 27 Jul 2006 10:31:06 -0700
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: POSIX performance
Alexander I. Shaykhrazeev wrote:
> Thanks for help. :-)
> I have additional question about using C++ under RTEMS. Did somebody
> use C++ to create applications for RTEMS?
Yes. EPICS is a fairly large and complex application with parts (alas)
written in C++.
> We have a task better to solve using C++ and mechanism of abstraction,
> but the task need great performance. All task must complete for 1 sec,
> called every 1 sec.
> There are any profiler for RTEMS to see process on time diagram? (Such
> instrument was very useful on WindRiver Workbench)
> Joel Sherrill wrote:
>> Till Straumann wrote:
>>> Alexander I. Shaykhrazeev wrote:
>>>> Did somebody check performance of POSIX semaphores and other
>>>> functions against RTEMS own?
>>> A while ago I compared vxworks, rtems and RT-linux regarding
>>> interrupt and thread dispatching latency.
>>> Both, rtems native and posix APIs were used.
>>> Note, however, that the paper incorrectly reports poor pthread
>>> performance under RTEMS. This was due to a programming error
>>> (incorrect task priority assignment). A repeated test using with
>>> the correct pthread priority yielded no significant difference in
>>> performance between RTEMS native and pthreads (for the
>>> latency benchmark - this was not a comprehensive comparison
>>> of all features or primitives, however).
>> From a design viewpoint, there should be little difference between
>> the POSIX and Classic API objects performance. Many are
>> based upon the same underlying SuperCore support and the API
>> code is just a thin wrapper.
>> + POSIX threads and Classic tasks are SuperCore threads
>> + POSIX mutex --> SuperCore Mutex
>> + POSIX semaphore --> SuperCore Semaphore
>> + Classic Semaphore --> SuperCore Mutex or Semaphore
>> + POSIX and Classic message queues are SuperCore message queues
>> All blocking code is the same. All delays/sleeps end up in the same
>> The primary difference is going to be the overhead of translating the
>> API into SuperCore calls -- which should be in the noise as far as
>> differences. The other thing to watch out for is semantic differences
>> which means that one API might actually have more functionality
>> required from what appears to be the same call. For example,
>> POSIX message queues allow for priority based messages and
>> Classic API message queues are FIFO or LIFO.
>>> -- Till