Ruby Forum Ruby-core > Sparc architecture optimizations

Someone at Sun has been looking at Ruby on Sparc:

http://blogs.sun.com/d/entry/ruby_performance_gains_on_sparc

Not sure if he has contacted any core devs about this so I thought I
would forward the link.

-Tom

Thomas Enebo wrote:
> Someone at Sun has been looking at Ruby on Sparc:
>
> http://blogs.sun.com/d/entry/ruby_performance_gains_on_sparc
>
> Not sure if he has contacted any core devs about this so I thought I 
> would forward the link.
>

 Miriam and Darryl are in the compiler team at Sun - I gave their
changes a spin with some micro-benchmarks of my own + the Debian
benchmarks, and there are between 5-13% in optimizations to be had here.

 Looking at Darryl's blog entry, I see that Matz has expressed interest
in merging the |FLUSH_REGISTER_WINDOWS| changes - so Darryl may already
be in touch?

 -ps

Hello Ruby-core,

 Can I request incorporation of this patch into the ruby_1_8 branch?

 The patch concerns a performance enhancement for SPARC based systems,
which I've tested, using self written tests and the Debian benchmarks.
It removes some unnecessary register window flush calls, and gives
between 5 and 13% improvement on SPARC - and does not affect other
platforms.

 This patch is not directly applicable to Ruby 1.9, and the use of
register window flushes seems limited to the gc and thread context
related code - which are appropriate uses to flush register windows.

 Please find the patch inlined below -

Index: defines.h
===================================================================
--- defines.h   (revision 15899)
+++ defines.h   (working copy)
@@ -227,12 +227,18 @@
        ;
 }
 #  define FLUSH_REGISTER_WINDOWS flush_register_windows()
+#  define EXEC_FLUSH_REGISTER_WINDOWS ((void)0)
+#  define SWITCH_FLUSH_REGISTER_WINDOWS ((void)0)
 #elif defined(__ia64)
 void *rb_ia64_bsp(void);
 void rb_ia64_flushrs(void);
 #  define FLUSH_REGISTER_WINDOWS rb_ia64_flushrs()
+#  define EXEC_FLUSH_REGISTER_WINDOWS FLUSH_REGISTER_WINDOWS
+#  define SWITCH_FLUSH_REGISTER_WINDOWS FLUSH_REGISTER_WINDOWS
 #else
 #  define FLUSH_REGISTER_WINDOWS ((void)0)
+#  define EXEC_FLUSH_REGISTER_WINDOWS FLUSH_REGISTER_WINDOWS
+#  define SWITCH_FLUSH_REGISTER_WINDOWS FLUSH_REGISTER_WINDOWS
 #endif

 #if defined(DOSISH)
Index: eval.c
===================================================================
--- eval.c      (revision 15899)
+++ eval.c      (working copy)
@@ -1025,7 +1025,7 @@
 #define PROT_LAMBDA INT2FIX(2) /* 5 */
 #define PROT_YIELD  INT2FIX(3) /* 7 */

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

 #define JUMP_TAG(st) do {              \
     ruby_frame = prot_tag->frame;      \
@@ -10330,7 +10330,7 @@
 }

 #define THREAD_SAVE_CONTEXT(th) \
-    (rb_thread_switch((FLUSH_REGISTER_WINDOWS,
ruby_setjmp(rb_thread_save_context(th), (th)->context))))
+    (rb_thread_switch((SWITCH_FLUSH_REGISTER_WINDOWS,
ruby_setjmp(rb_thread_save_context(th), (th)->context))))

 NORETURN(static void rb_thread_restore_context _((rb_thread_t,int)));
 NORETURN(NOINLINE(static void
rb_thread_restore_context_0(rb_thread_t,int,void*)));


Thanks,
 -ps

Hi,

In message "Re: [PATCH] SPARC architecture optimizations"
    on Fri, 4 Apr 2008 09:06:39 +0900, Prashant Srinivasan 
<Prashant.Srinivasan@Sun.COM> writes:

|Hello Ruby-core,
|
| Can I request incorporation of this patch into the ruby_1_8 branch? 

I am happy to merge the patch, but is it really OK to remove
FLUSH_REGISTER_WINDOWS from THREAD_SAVE_CONTEXT()?

              matz.

Yukihiro Matsumoto wrote:
> FLUSH_REGISTER_WINDOWS from THREAD_SAVE_CONTEXT()?
>
>   

Hello Matz,

 Thank you for the response.

 Yes, it is indeed okay to remove that particular invocation to
FLUSH_REGISTER_WINDOWS, since it is redundant.  Another call to
FLUSH_REGISTER_WINDOWS is made in rb_thread_save_context as a part of
THREAD_SAVE_CONTEXT.

ie., in rb_thread_save_context(), the following exists.

[snipped code here]

static void
rb_thread_save_context(th)
    rb_thread_t th;
{

[snipped code here]
    FLUSH_REGISTER_WINDOWS;
    MEMCPY(th->stk_ptr, th->stk_pos, VALUE, th->stk_len);
[snipped code here]


Thanks,
 -ps

Prashant Srinivasan wrote:
> Hello Matz,
> 
> Thank you for the response.
> 
> Yes, it is indeed okay to remove that particular invocation to 
> FLUSH_REGISTER_WINDOWS, since it is redundant.  Another call to 
> FLUSH_REGISTER_WINDOWS is made in rb_thread_save_context as a part of 
> THREAD_SAVE_CONTEXT.
> ie., in rb_thread_save_context(), the following exists.

So has this been included? I saw some perf numbers relating to this and
the gains were pretty substantial.

- Charlie

Charles Oliver Nutter wrote:
>
> So has this been included? I saw some perf numbers relating to this 
> and the gains were pretty substantial.

Hey Charlie,
 The above mentioned change has not made it in . . . but another flush
call(the one in EXEC_TAG) has been removed.  It'll be really cool if
someone can commit this  change - the call to flush windows here is
unnecessary - and it's quite an expensive call to have redundant
invocations.

thanks,
 -ps

Prashant Srinivasan wrote:
>>> ie., in rb_thread_save_context(), the following exists.
>>
>> So has this been included? I saw some perf numbers relating to this 
>> and the gains were pretty substantial.
> 
> Hey Charlie,
> The above mentioned change has not made it in . . . but another flush 
> call(the one in EXEC_TAG) has been removed.  It'll be really cool if 
> someone can commit this  change - the call to flush windows here is 
> unnecessary - and it's quite an expensive call to have redundant 
> invocations.

Maybe if you could quantify expensive with some before/after numbers?

- Charlie

Charles Oliver Nutter wrote:
>>>> of THREAD_SAVE_CONTEXT.
>> invocations.
>
> Maybe if you could quantify expensive with some before/after numbers?
>

Here is data obtained from running the Computer language shootout tests
on a V490 running OpenSolaris.  A couple of tests are home grown.
We're seeing between 4.88% - 12.74% increase in performance(ie., a
decrease in latency) with Ruby patched with the flush patch I sent on
this thread.

TraverseXmlDom 4.88%
SpectralNorm 6.18%
BinaryTrees 6.59%
ParseXmlData 4.41%
Nsievebits 7.44%
Nsieve 1.46%
Fasta 8.11%
Recursive 7.62%
PartialSums 6.44%
Nbody 6.59%
SumCol 12.74%
Fannkuch 7.12%


Cheers,
 -ps

Prashant Srinivasan wrote:
> Nsievebits 7.44%
> Nsieve 1.46%
> Fasta 8.11%
> Recursive 7.62%
> PartialSums 6.44%
> Nbody 6.59%
> SumCol 12.74%
> Fannkuch 7.12%

Very nice, seems pretty worthwhile to include it, especially if it's 
safe.

- Charlie