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

[Joel Sherrill]

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

I am not sure I understand the question but the answer should be no.

At the end of the day, all Classic tasks, ITRON tasks, and POSIX threads
are Score threads and interchangeable when calling services.  This is 
just a portability problem in the way POSIX defined the defualt thread
attributes. 

--joel

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

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