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

[Joel Sherrill]

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

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