RTEMS vs Linux : Performance analysis : Comments andSuggestions Please

[Joel Sherrill]

One thing to note is that a serious optimization occurred
to mutexes and semaphores around July 2000 which resulted
in about 1/2'ing the execution times for simple
uncontested locks and unlocks.  This code is NOT
in 4.5.0.

--joel

Joel Sherrill wrote:

> Ranjith Mukundan wrote:
> 
>> and i guess this is without the RT or RTAI patch?? as ralf indicated,
>> please provide the details (kernel version, patches & patch levels used
>> etc)..
> 
> 
> Is caching on with the RTEMS BSP?
> 
> Ralf.. you are right.. I need to cut a 4.6.1.  There haven't
> been any new 4.6.0 problems reported in the past coup[le of
> weeks.
> 
> --joel
> 
>> -----Original Message-----
>> From: Ralf Corsepius [mailto:ralf_corsepius at rtems.org] Sent: Friday, 
>> March 19, 2004 4:20 PM
>> To: sashti srinivasan
>> Cc: RTEMS Users
>> Subject: Re: RTEMS vs Linux : Performance analysis : Comments
>> andSuggestions Please
>>
>>
>> On Fri, 2004-03-19 at 10:47, sashti srinivasan wrote:
>>
>>> Hello All,
>>>
>>>       Because of the full fledged support from the
>>> list, I am now able to measure time accurately with 1
>>> microsecond accuracy on PC386.  I have got some
>>> figures of merit, based on this I want to improve the
>>> performance of rtems.  Here are the results for
>>> discussion.  This is a comparison between linux and
>>> rtems on pc386 platform.  POSIX api is used for the
>>> measurement and to the best possible extent same code
>>> has been used in both. 
>>
>>
>>
>> More details, please.
>>
>> How did you measure these figures?
>>
>> Which CPU has been used?
>>
>> Which compilers, which flags have been used to compile the Linux-Kernel,
>> Linux-libc, Linux-application, RTEMS and your RTEMS application?
>>
>>
>>> Please suggest some way of
>>> improving the performance of rtems in these aspects.
>>
>>
>> Number one source of improvement for RTEMS: The compiler flags.
>> There, choosing the appropriate set of flags can result into huge
>> differences in performance.
>>
>>
>>> (All Times are in microseconds : Average of some large
>>> number of operations)
>>>
>>>                              Linux   RTEMS
>>>       Time To Lock a Mutex =  0.12   0.30
>>>     Time To Unlock a Mutex =  0.12   0.28
>>>     Initialize a Semaphore =  0.31   0.99
>>>        Destroy a Semaphore =  0.10   1.46
>>>             Semaphore Wait =  0.20   0.24
>>>             Semaphore Post =  0.19   0.31
>>
>>
>>
>> These figures are no actual surprize to me, because Linux pthread
>> implementation is pretty low-level, lean and highly optimized for speed,
>> while RTEMS's pthreads/posix implementation is a wrapper to RTEMS native
>> mechanisms and therefore is comparatively heavy weighted.
>>
>>
>>>     Thread Switching Time =  9.85   1.81
>>
>>
>> Note this figure above. mutexes and semaphores are only one side of the
>> medal ;)
>>
>>
>>>    Please suggest some ideas regarding improvement of
>>> mutex and semaphore performance of rtems.
>>
>>
>>
>> Ralf
>>
>>
>>
>> Confidentiality Notice
>> The information contained in this electronic message and any 
>> attachments to this message are intended
>> for the exclusive use of the addressee(s) and may contain confidential 
>> or privileged information. If
>> you are not the intended recipient, please notify the sender at Wipro 
>> or Mailadmin at wipro.com immediately
>> and destroy all copies of this message and any attachments.
> 
> 
> 


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