Re: [ST-devel] autoconf and libst

[Lev W. <vl...@ne...>]

Mike Abbott wrote:

> [I missed the original post on this subject due to @Home cratering and
> the list archive seems not to work, so sorry for the late reply.]

[skip]

> 	3.3 Performance
> 
> 	Performance is one of the library's main objectives.
> 	The State Threads library is implemented to minimize the
> 	number of system calls and to make thread creation and
> 	context switching as fast as possible. ...
> 
> 	(http://state-threads.sourceforge.net/docs/st.html)


Yes, yes, yes. But the general overhead of using a system call is
only TWO-THREE times worse of using a malloc(), for example.
There are a big area to improve, besides minimizing the number
of system calls.

> On the other hand I welcome packaging efforts.  Casual users frown on
> having to compile software so providing rpms, srpms, and other popular
> package formats will expand the project's audience.
> 
> Now to answer some specific questions:
> 
> 
>>MD_ACCEPT_NB_INHERITED:
>>Is it really such a performance hit?
>>
> 
> Yes.
> 
> 
>>MD_GET_UTIME:
>>	Use them in this order:
>>	gettimeofday
>>	read_real_time & time_base_to_time
>>	syssgi & clock_gettime
>>	gethrtime
>>	ftime
>>	fail with an error
>>
> 
> If you intend to probe for these functions in this order and to use the
> first match your performance will suffer.  clock_gettime on SGI systems
> is a memory load not a system call and is therefore much faster than
> gettimeofday.  I assume gethrtime is similar.  gettimeofday should be
> the last resort.
> 
> 
>>You should consider using internal
>>__OS_Type__ variables in header or code files to protect this place.
>>
> 
> Ugh, I strongly prefer the current scheme in md.h.  All the
> system-dependent definitions are in one place rather than scattered
> about.


It was for case of using autoconf.

>>Who is the official upstream maintainer?
>>
> 
> Please define this term.  Gene and I are the ultimate owners of the
> project.  I don't think sourceforge provides a "state-threads-owner"
> mail alias so snarf our sourceforge addresses from the project summary
> page.
> 
> 
>>poll() is faster than select() - is this wrong?
>>
> 
> In addition to the other analysis offered of relative speed, select has
> the feature that multiple threads waiting for the same fd don't change
> the system call.  With poll, each waiting thread has its own pollfd even
> if all of the fds are the same.  So the right choice (poll vs. select)
> depends on not only the total number of fds but also their expected use.


Again: if we want to make st even faster (20% to TIMES faster), we should

consider build an independent scheme, and implement a modern techniques,
like kqueue() or /dev/poll. We will give the ST the speed and the
scalability of state-driven kqueue() (or /dev/poll)'based applications.

It will be a really huge improvement, not even comparable with omission
of a system call one time per thread life.


-- 
Lev Walkin
vl...@ne...