[ruby-core:19634] performance issues with --enable-pthread on Solaris.

Introduction
------------

We are experiencing performance issues when running ruby. That is if  
this binary was created with the --enable-pthread option.  Executing  
these tests with ruby 1.8.7 does not show this performance degradation.
This made me compare the sources of both ruby versions. Since it was  
soon obvious that there was a strong relation between this degradation  
and the set/getcontext functions I focussed on where these two  
functions were used. This happens to be the case in eval.c

In this file I found  __builting_setjmp and __builtin_longjmp being  
used in 1.8.7. But not in 1.8.6.
Besides that it also turned out that the use of both xxxcontext  
functions was triggered by a #define in config.h.



Source code changes and results
-------------------------------

The following tests were done with:

ruby runner.rb -b BinaryTrees

in different settings. Both on a SPARC IV 1350MHz V890 box (16 cores)  
and a V20Z (4 cores AMD), and a 8 core AMD 4600

The results are (total time reported):

Name_____ThreadChoice_____ SPARC IV_____V20Z______4600___
baseline      --disable-pthread           25.02               
8.63             7.15
basethread --enable-pthread            43.67             
26.76           11.71
editConfig   --enable-pthread            25.33               
8.62             7.32
builtin          --enable-pthread            26.38               
8.71             7.31
builtinFlush --enable-pthread            24.58               
8.62             7.29

OS used:

SPARC IV:   5.11 snv_79a
4600:           5.11 snv_70b
V20Z:           5.11 snv_86

All binaries were configured with the following flags:

./configure <thread choise> --disable-shared CC=cc "CFLAGS=-O4 -g -v - 
V -DRUBY_EXPORT" --prefix=$HOME/<name>

Ruby version: 1.8.6 p286

The baseline and basethread and editConfig version used the source  
without modification.
The others had some tweaks in the file eval.c

editConfig: after running configure the following lines were removed  
from config.h:

#define HAVE_GETCONTEXT 1
#define HAVE_SETCONTEXT 1


Both builtin and builtinFlush had the following two lines (depicted by  
<----------)  added:

> #else
> #  if !defined(setjmp) && defined(HAVE__SETJMP)
> #    define ruby_setjmp(just_before_setjmp, env) \
>       ((just_before_setjmp), _setjmp(env))
> #    define ruby_longjmp(env,val) _longjmp(env,val)
> #  else
> #    define ruby_setjmp(just_before_setjmp, env) \
>       ((just_before_setjmp), setjmp(env))
> #    define ruby_longjmp(env,val) longjmp(env,val)
> #  endif
> #endif
>
> #define ruby_setjmp(a,b)     
> __builtin_setjmp(b)                                 <-------------
> #define ruby_longjmp(a,b)  
> __builtin_longjmp(a,b)                             <-------------
>
> #include <sys/types.h>
> #include <signal.h>
> #include <errno.h>
>


BuiltinFlash has a different definition for a macro. The following  
macro:

#define EXEC_TAG()    (FLUSH_REGISTER_WINDOWS, ruby_setjmp(((void)0),  
prot_tag->buf))

is redefined in BuiltinFlash  by (as found in the 1.8.7 source) :

#define EXEC_TAG()    (ruby_setjmp(((void)0), prot_tag->buf))

These are all runs on dedicated systems. Nothing else running besides  
the standard background processes.


Stability
---------

I ran make test-all to see if these changes would break anything. This  
seems not to be the case.


Request
-------

I would like to hear from the community if these changes would be  
acceptable. And if  there is a preference for one of them.
Any further insight, recommendation or feedback is, of course, welcome.


Thanks,
Paul



---------------------------------------------------------------------------------------------
Paul van den Bogaard                               [e-mail]
ISV-E  -- ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc                              phone:        +31  
334 515 918
Saturnus 1                                                 extentsion:  
x (70)15918
3824 ME Amersfoort                                 mobile:       +31  
651 913 354
The Netherlands                                        fax:             
[phone]