POSIX performance

[Till Straumann]

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++.

-- T.

> 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, 
> task
> 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.
>>>
>>> See
>>>
>>> http://www.slac.stanford.edu/econf/C011127/WEBI001.shtml
>>>
>>> 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 
>> helper
>> routines.
>> 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.
>>
>> --joel
>>
>>> -- Till
>>
>>
>>
>>
>