[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RTEMS vs Linux : Performance analysis : Comments andSuggestions Please
- Date: Fri, 19 Mar 2004 11:58:38 -0600
- From: joel at OARcorp.com (Joel Sherrill)
- Subject: RTEMS vs Linux : Performance analysis : Comments andSuggestions Please
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
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
> -----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:
>> 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.
> 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