RTEMS vs Linux : Performance analysis : Comments and Suggestions Please

[Joel Sherrill]

sashti srinivasan wrote:

>Hello,
>  
>
>>More details, please.
>>Which CPU has been used?
>>    
>>
>      Lots of thanks for various suggestions.  I
>compare linux running on x86 pc and rtems on the same
>pc386(same machine).
>  Linux Kernel : 2.4.18
>  CPU          : Pentium III
>  Clock speed  : 733 MHz
>
>  
>
>>How did you measure these figures?
>>    
>>
>    I wrote a program using POSIX api that repeats all
>these operations a large number of times and took the
>average.  For time measurement I used gettimeofday(). 
>I learnt from Dr. Joel that this routine has only the
>resolution of clock ticks.  And accurate routines
>Timer_initialize and Read_timer did not work on PC386.
> Best support from list helped me read the hardware
>8254 timer (counter0) to measure the time since last
>tick.  If a tick occurs while reading the counter0, I
>read counter0 again.
>  
>
I haven't looked at your benchmark at all but here are some semi-random
comments.

Unless you modified it, gettimeofday()  (cpukit/libcsupport/src/__gettod.c)
doesn't account for time between ticks at all.

Did you explicitly set all attributes of all posix threads, mutexes, etc.? 

Were you root on the Linux box?

--joel

>>Which compilers, which flags have been used to
>>compile the Linux-Kernel,
>>Linux-libc, Linux-application, RTEMS and your RTEMS
>>application?
>>    
>>
>   glibc        : 2.2.93
>   linux kernel : 2.4.18
>   RTEMS        : 4.5 distributed with LECCS by
>Gaisler Research.  I could not succeed in building
>rtems 4.6.  Does it matter in a significant way for
>pc386?  The error reported while building was someway
>related to PTHREAD_CANCELLED macro.  I found somebody
>reporting same problem in archives and also found the
>reply suggesting to define PTHREAD_CANCELLED to
>arbitrary value.  It was also said that it is a bad
>idea to do so.  In order to be clear, I used 4.5 which
>built successfully.
>
>  I configured rtems in this manner:
>   $(rtemssrc)/configure --target=i386-rtems 
>--enable-rtemsbsp="pc386" --enable-posix=yes
>--prefix=$(insdir) 
>
>  
>
>>> 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.
>>    
>>
>     I find it very difficult to follow the configure
>scripts and makefiles.  Please guide me in setting the
>compiler flags and also suggest me appropriate
>compiler flags that will improve the performance.  
>
>     If possible also guide me in generating configure
>and Makefile.in from original scripts.  This will help
>me in a great way in having a deep understanding of
>components of rtems.  My understanding of autoconf and
>automake is very poor.  Please forgive me for requests
>unrelated to rtems.
>
>     One more request:
>  
>
>>>(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.
>>    
>>
>       Is it possible to improve the performance of
>mutexes and semaphores in such a way that is close to
>linux?  Please guide me in going about it.
>  
>
>>>     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
>>
>>
>>    
>>
>
>With Best Regards
>Srinivasan
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - More reliable, more storage, less spam
>http://mail.yahoo.com
>  
>