RTEMS pthread performance is GOOD (was Re: Fwd: RTEMS pthreadsperformance)

[Angelo Fraietta]

Does this issue effect the native RTEMS method of using threads / tasks 
i.e. non-posix methods?

Joel Sherrill wrote:

>
>Till Straumann wrote:
>
>>MEA CULPA.
>>
>>Ooops, I'm to blame for a really bad one, sorry.
>>Obviously, I'm not too experienced with the pthread API :-(
>>
>
>Don't feel bad, even after having reviewed and commented
>upon various drafts of the pthreads spec, implementing most of
>it in RTEMS, porting GNAT to RTEMS pthreads, and implementing
>applications using it, I still find it obtuse and confusing.
>It is VERY easy to make mistakes. :(
>
>>My benchmark code fails to set PTHREAD_EXPLICIT_SCHED and hence
>>the benchmark task runs at the wrong priority. I had developed the
>>pthread stuff for RT-Linux (where EXPLICIT_SCHED is the default,
>>as it is on some other systems, it seems).
>>
>
>I searched some last night
> 
>
>>After fixing this, it looks like pthread performance is very similar
>>to using RTEMS native threads.
>>
>>An updated version is available at
>>
>>http://www.slac.stanford.edu/~strauman/rtoslat/index.html
>>
>
>Not to pick but could you update the table in the paper and post
>a corrected version of it?  I would like to see a complete corrected
>version of at least the data.  From what I can tell, the paper itself
>wouldn't be terribly difficult to update either.
>
>You mentioned using various blocking mechanisms.  Did any of them
>show any discrepancies?
> 
>
>>My sincere apologies
>>
>
>No problem.  I was concerned enough to hunt for it anyway. :)
>
>Besides benchmarking is difficult to do correctly.  Greg Menke went to
>a lot of trouble and ended up with a scaling error in his initial 
>reported results.
> 
>
>>-- Till
>>
>>Joel Sherrill wrote:
>>
>>>Till Straumann wrote:
>>>
>>>>Joel Sherrill wrote:
>>>>
>>>>
>>>>>Till Straumann wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Kamen Penev wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi!
>>>>>>>
>>>>>>>Looking at your work comparing RTEMS, RTLinux and vxWorks, I am wondering
>>>>>>>about the unusually poor RTEMS+pthreads result for context switching on a
>>>>>>>loaded system. Has this been explained (better yet fixed)by the RTEMS
>>>>>>>development team?
>>>>>>>
>>>>>>>
>>>>>Which RTEMS version/target CPU/configuration?
>>>>>
>>>>I believe it was ss-20011025 (I can re-run the test later today on a
>>>>later version).
>>>>
>>>
>>>That is pretty old and I am 100% positive it predates the work
>>>I did to improve results on your benchmark.  The ChangeLog entry
>>>for that is 2002-07-01.
>>>
>>>
>>>>The target was a 604 series PowerPC on a Motorola MVME23xx board.
>>>>
>>>
>>>Do you know what the test is doing?  Is it the same as yours?  Saying
>>>something is slow doesn't help me much.  RTEMS usually performs
>>>comparable to VxWorks on benchmarks.  But each time we hit a new
>>>benchmark comparison, there is new data to optimize against.
>>>
>>>
>>>>-- Till
>>>>
>>>>
>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>Kamen Penev
>>>>>>>Adept Technology
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Good question. I am not using pthreads and the honest answer is "I dont
>>>>>>know".
>>>>>>I remember, however having brought this to Joel Sherrill's attention
>>>>>>(back in 2001
>>>>>>when I did the tests) and I believe he had some ideas about the cause...
>>>>>>
>>>>>>-- Till
>>>>>>
>>>>>>
>>>>>
>>>>>
>

-- 
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page


http://www.users.bigpond.com/angelo_f/

There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20021205/6e18da72/attachment-0001.html>