Mail Archives: cygwin/2001/06/25/20:24:18
With Robert Collins' latest patches, the Cygwin pthreads implementation,
as far as I can tell, seems functional (Thanks Rob!!). However, its
performance, in the words of an old friend of mine, `sucks dead bears'
(he's a Hokie, which probably explains his phrasing ;-)
My (heavily threaded) application runs approximately 100x slower than under
linux and proceeds to the point where the program thrashes because it is
calling pthreads functions faster than the pthreads implementation can
deliver (we're talking _mutex_lock/unlock and _cond_wait/signal here).
I realize very well that in a development scenario functionality should
come first and performance second. However, one of our developers is
insisting on writing his own pthreads implementation for the application
(it's not really mine, I'm just a minor developer) on the Win32 side.
As a programmer, I hate to see dual pathing based on platform in the code;
hence this prod (er post).
I also know that Rob is fully aware of the performance problem and
has ideas he wishes to implement, when he can spare some moments of his
valuable time. However, as of 1.3, our application doesn't run on Win32
without kluging the threads implementation (by using a pthreads implementation
from ftp://sources.redhat.com/pub/pthreads-win32). I am anxious to see
pthreads `right' on Cygwin.
I am willing to act as guinea pig or to contribute code myself. Alas, I am
a procedural programmer and not an OOPer; although I understand the concept
of classes, objects and methods, some of the syntax and methodolgy eludes
me. However, ignorance has never stopped me from jumping in and getting wet
before. I learned a long time ago that when you jump into water where you
don't know how deep it is, you don't jump in head first, and not feet first,
but butt first (the reader is free to deduce any insights this analogy
provides, if any ;-)
Greg
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -