[#16116] RCRchive shutting down — "David A. Black" <dblack@...>

Hi everyone --

22 messages 2008/04/03
[#16119] Re: [ANN] RCRchive shutting down — "Robert Dober" <robert.dober@...> 2008/04/03

This is quite sad news, I feel that a mailing list does not offer all

[#16121] Re: [ANN] RCRchive shutting down — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16122] Re: [ANN] RCRchive shutting down — "Robert Dober" <robert.dober@...> 2008/04/03

On Thu, Apr 3, 2008 at 12:01 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#16123] issue tracking (Re: [ANN] RCRchive shutting down) — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16124] Re: issue tracking (Re: [ANN] RCRchive shutting down) — "Meinrad Recheis" <meinrad.recheis@...> 2008/04/03

On Thu, Apr 3, 2008 at 1:13 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#16128] RUBY_IMPLEMENTATION — Yukihiro Matsumoto <matz@...>

Hi,

60 messages 2008/04/03
[#16139] Re: RUBY_IMPLEMENTATION — Paul Brannan <pbrannan@...> 2008/04/03

On Thu, Apr 03, 2008 at 11:41:41PM +0900, Yukihiro Matsumoto wrote:

[#16143] Re: RUBY_IMPLEMENTATION — Eric Hodel <drbrain@...7.net> 2008/04/03

On Apr 3, 2008, at 10:59 AM, Paul Brannan wrote:

[#16146] Re: RUBY_IMPLEMENTATION — Yukihiro Matsumoto <matz@...> 2008/04/03

Hi,

[#16147] Re: RUBY_IMPLEMENTATION — Ezra Zygmuntowicz <ezmobius@...> 2008/04/03

[#16149] Re: RUBY_IMPLEMENTATION — Charles Oliver Nutter <charles.nutter@...> 2008/04/03

Ezra Zygmuntowicz wrote:

[#16155] Re: RUBY_IMPLEMENTATION — "Yemi I. D. Bedu" <yemi@...> 2008/04/03

Hello,

[#16158] Re: RUBY_IMPLEMENTATION — Charles Oliver Nutter <charles.nutter@...> 2008/04/03

Yemi I. D. Bedu wrote:

[#16175] Re: RUBY_IMPLEMENTATION — Eleanor McHugh <eleanor@...> 2008/04/04

On 4 Apr 2008, at 00:23, Charles Oliver Nutter wrote:

[#16194] Re: RUBY_IMPLEMENTATION — Chris Cummer <chris@...> 2008/04/04

On 4-Apr-08, at 3:05 AM, Eleanor McHugh wrote:

[#16195] Re: RUBY_IMPLEMENTATION — "Luis Lavena" <luislavena@...> 2008/04/04

On Fri, Apr 4, 2008 at 2:15 PM, Chris Cummer <chris@postal-code.com> wrote:

[#16240] syntax request — "ry dahl" <ry@...>

Often times when one has many long arguments and orders them like this

42 messages 2008/04/06
[#16263] Re: syntax request — "Bill Kelly" <billk@...> 2008/04/07

[#16266] Re: syntax request — "David A. Black" <dblack@...> 2008/04/08

On Tue, 8 Apr 2008, Bill Kelly wrote:

[#16282] Re: syntax request — Paul Brannan <pbrannan@...> 2008/04/08

On Tue, Apr 08, 2008 at 02:23:26PM +0900, David A. Black wrote:

[#16290] Could someone confirm signal handling is broken on OSX? — Dave Thomas <dave@...>

I've raised this before, but no one replied. I'd like to double check

12 messages 2008/04/08

[#16359] design meeting — Yukihiro Matsumoto <matz@...>

Hi,

18 messages 2008/04/12

[#16397] Ruby 1.8.7-preview1 has been released — "Akinori MUSHA" <knu@...>

Folks,

16 messages 2008/04/15

[#16482] Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...>

Hi

32 messages 2008/04/22
[#16483] Re: Performance on method dispatch for methods defined via define_method — Paul Brannan <pbrannan@...> 2008/04/22

On Wed, Apr 23, 2008 at 12:39:29AM +0900, Robert Dober wrote:

[#16484] Re: Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...> 2008/04/22

On Tue, Apr 22, 2008 at 8:46 PM, Paul Brannan <pbrannan@atdesk.com> wrote:

[#16487] Re: Performance on method dispatch for methods defined via define_method — "David A. Black" <dblack@...> 2008/04/22

Hi --

[#16488] Re: Performance on method dispatch for methods defined via define_method — "Robert Dober" <robert.dober@...> 2008/04/22

On Tue, Apr 22, 2008 at 10:44 PM, David A. Black <dblack@rubypal.com> wrote:

[#16490] Re: Performance on method dispatch for methods defined via define_method — "David A. Black" <dblack@...> 2008/04/22

Hi --

[#16501] Re: Performance on method dispatch for methods defined via define_method — ts <decoux@...> 2008/04/23

Robert Dober wrote:

[#16507] Drop :: as a . synonym — "David A. Black" <dblack@...>

Hi --

50 messages 2008/04/23
[#16511] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/23

David A. Black wrote:

[#16512] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/23

Hi --

[#16525] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/23

David A. Black wrote:

[#16527] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/23

Hi --

[#16534] Re: [RCR] Drop :: as a . synonym — Thomas Enebo <Thomas.Enebo@...> 2008/04/23

David A. Black wrote:

[#16546] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/24

Hi --

[#16552] Re: [RCR] Drop :: as a . synonym — "Jeremy McAnally" <jeremymcanally@...> 2008/04/24

Or changing #send to private...or (insert progressive but code

[#16564] Re: [RCR] Drop :: as a . synonym — Charles Oliver Nutter <charles.nutter@...> 2008/04/24

Jeremy McAnally wrote:

[#16567] Re: [RCR] Drop :: as a . synonym — "David A. Black" <dblack@...> 2008/04/24

Hi --

[#16570] Re: [RCR] Drop :: as a . synonym — Yukihiro Matsumoto <matz@...> 2008/04/24

Hi,

[#16531] Re: [RCR] Drop :: as a . synonym — "Eric Mahurin" <eric.mahurin@...> 2008/04/23

On Wed, Apr 23, 2008 at 9:21 AM, David A. Black <dblack@rubypal.com> wrote:

[PATCH] SPARC architecture optimizations

From: Prashant Srinivasan <Prashant.Srinivasan@...>
Date: 2008-04-04 00:06:39 UTC
List: ruby-core #16159
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




Prashant Srinivasan wrote:
> 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
>


-- 
Prashant Srinivasan
F/OSS Enthusiast
Sun Microsystems, Inc.
http://blogs.sun.com/prashant
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A


In This Thread