Re: [MacRuby-devel] [MacRuby] #22: NSPredicate doesn't work

2009-03-28 Thread MacRuby 
#22: NSPredicate doesn't work
-+--
 Reporter:  jordan.breed...@…|Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.1  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--

Comment(by a...@…):

 [http://www.sneakeralley.com Nike Air Force One]

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] new website!

2009-03-28 Thread Carlos Paramio 

Very nice. Congrats!

Carlos Paramio

El 28/03/2009, a las 4:12, Laurent Sansonetti escribió:


Hi guys,

I'm glad to introduce you our new website!

 http://macruby.org

It's written with webby and it's very easy to maintain it. It was  
implemented so that people can easily contribute changes.


Dependencies:

 $ sudo gem install coderay
 $ sudo gem install webby

To get the sources:

 $ svn co http://svn.macosforge.org/repository/ruby/MacRubyWebsite/trunk 
 macruby-website


To build it + start a local web browser + open a new browser window  
and refresh the server when a file changes:


 $ cd macruby-website
 $ webby autobuild

Feel free to check it out and if you want to provide a tutorial/ 
recipe please send your patch!


I would like to personally thank: John Athayde (design), Rich Kilmer  
(implementation) and William Siegrist (server hosting).


Enjoy,

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] branches/experimental

2009-03-28 Thread Laurent Sansonetti 

Hi guys,

As some of you already noticed we have been working on a branch for a  
few weeks and I thought it's now time to describe what has been done  
and were we are going exactly.


I wrote a blog entry here: 
http://www.macruby.org/blog/2009/03/28/experimental-branch.html

2 big features in this branch: a LLVM-based JIT compiler and a new IO  
subsystem. Obviously performance-related, we really need to be faster.


Current status of the branch:

- The compiler is now able to pass most of the Ruby AST. It compiles  
nodes directly from the parser in a lazy fashion.

- Only JIT compilation for the moment (AOT is planned for later).
- The VM is still under development, it's not as complete as the  
compiler yet.

- Early performance benchmarks are very promising.
- By the time of this writing, we pass the vast majority of the  
language RubySpecs (a week ago we weren't even able to even bootstrap  
mspec!), about 1190 expectations. Work is very active in this area, we  
are also making sure the specs do run with the original Ruby 1.9 and  
writing missing specs.
- The new IO subsystem is mostly functional, but there are still many  
methods that are not implemented yet and we are working on this. Once  
it will be complete we will integrate a default runloop in the VM and  
expose asynchronous IOs.


For the near future, the goals are:

- Improving the compiler. Currently compile time has not really been  
optimized yet.

- Be able to run IRB. We are almost there.
- Remove the libffi code used to call C/ObjC implementations and  
instead JIT compile stubs and insert them in the dispatcher cache. We  
should be way closer to ObjC then (and maybe faster once we enable  
secondary compilations of hotspots and inline the stubs).

- Rewrite the BridgeSupport side using LLVM types.
- Implement full concurrent threading! (this is a big one :-)).
- And many more (check the TODO file for more info).

Once we arrive at a point when the branch is as functional as trunk,  
it will be merged in trunk and we will then work on stabilizing it, to  
later on release it as 0.5. The schedule for this release is unknown,  
it will be released when it will be ready (preferably this year though).


If you want to help let me know!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Jordan Breeding 

Will OSA support be a 0.5 or a 0.6 task?

On Mar 28, 2009, at 14:37, Laurent Sansonetti   
wrote:



Hi guys,

As some of you already noticed we have been working on a branch for  
a few weeks and I thought it's now time to describe what has been  
done and were we are going exactly.


I wrote a blog entry here: 
http://www.macruby.org/blog/2009/03/28/experimental-branch.html

2 big features in this branch: a LLVM-based JIT compiler and a new  
IO subsystem. Obviously performance-related, we really need to be  
faster.


Current status of the branch:

- The compiler is now able to pass most of the Ruby AST. It compiles  
nodes directly from the parser in a lazy fashion.

- Only JIT compilation for the moment (AOT is planned for later).
- The VM is still under development, it's not as complete as the  
compiler yet.

- Early performance benchmarks are very promising.
- By the time of this writing, we pass the vast majority of the  
language RubySpecs (a week ago we weren't even able to even  
bootstrap mspec!), about 1190 expectations. Work is very active in  
this area, we are also making sure the specs do run with the  
original Ruby 1.9 and writing missing specs.
- The new IO subsystem is mostly functional, but there are still  
many methods that are not implemented yet and we are working on  
this. Once it will be complete we will integrate a default runloop  
in the VM and expose asynchronous IOs.


For the near future, the goals are:

- Improving the compiler. Currently compile time has not really been  
optimized yet.

- Be able to run IRB. We are almost there.
- Remove the libffi code used to call C/ObjC implementations and  
instead JIT compile stubs and insert them in the dispatcher cache.  
We should be way closer to ObjC then (and maybe faster once we  
enable secondary compilations of hotspots and inline the stubs).

- Rewrite the BridgeSupport side using LLVM types.
- Implement full concurrent threading! (this is a big one :-)).
- And many more (check the TODO file for more info).

Once we arrive at a point when the branch is as functional as trunk,  
it will be merged in trunk and we will then work on stabilizing it,  
to later on release it as 0.5. The schedule for this release is  
unknown, it will be released when it will be ready (preferably this  
year though).


If you want to help let me know!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Laurent Sansonetti 

Most likely 0.6, unless someone volunteers to do it now :-)

Laurent

On Mar 28, 2009, at 12:48 PM, Jordan Breeding wrote:


Will OSA support be a 0.5 or a 0.6 task?

On Mar 28, 2009, at 14:37, Laurent Sansonetti  
 wrote:



Hi guys,

As some of you already noticed we have been working on a branch for  
a few weeks and I thought it's now time to describe what has been  
done and were we are going exactly.


I wrote a blog entry here: 
http://www.macruby.org/blog/2009/03/28/experimental-branch.html

2 big features in this branch: a LLVM-based JIT compiler and a new  
IO subsystem. Obviously performance-related, we really need to be  
faster.


Current status of the branch:

- The compiler is now able to pass most of the Ruby AST. It  
compiles nodes directly from the parser in a lazy fashion.

- Only JIT compilation for the moment (AOT is planned for later).
- The VM is still under development, it's not as complete as the  
compiler yet.

- Early performance benchmarks are very promising.
- By the time of this writing, we pass the vast majority of the  
language RubySpecs (a week ago we weren't even able to even  
bootstrap mspec!), about 1190 expectations. Work is very active in  
this area, we are also making sure the specs do run with the  
original Ruby 1.9 and writing missing specs.
- The new IO subsystem is mostly functional, but there are still  
many methods that are not implemented yet and we are working on  
this. Once it will be complete we will integrate a default runloop  
in the VM and expose asynchronous IOs.


For the near future, the goals are:

- Improving the compiler. Currently compile time has not really  
been optimized yet.

- Be able to run IRB. We are almost there.
- Remove the libffi code used to call C/ObjC implementations and  
instead JIT compile stubs and insert them in the dispatcher cache.  
We should be way closer to ObjC then (and maybe faster once we  
enable secondary compilations of hotspots and inline the stubs).

- Rewrite the BridgeSupport side using LLVM types.
- Implement full concurrent threading! (this is a big one :-)).
- And many more (check the TODO file for more info).

Once we arrive at a point when the branch is as functional as  
trunk, it will be merged in trunk and we will then work on  
stabilizing it, to later on release it as 0.5. The schedule for  
this release is unknown, it will be released when it will be ready  
(preferably this year though).


If you want to help let me know!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Jordan Breeding 
Well if you offer guidance and the target for 0.5 really is just "this  
year" then I might be able to give it a shot and help out.


Of course that also depends on whether I get a job immediately after  
graduation in August and how busy that keeps me.


On Mar 28, 2009, at 14:56, Laurent Sansonetti   
wrote:



Most likely 0.6, unless someone volunteers to do it now :-)

Laurent

On Mar 28, 2009, at 12:48 PM, Jordan Breeding wrote:


Will OSA support be a 0.5 or a 0.6 task?

On Mar 28, 2009, at 14:37, Laurent Sansonetti  
 wrote:



Hi guys,

As some of you already noticed we have been working on a branch  
for a few weeks and I thought it's now time to describe what has  
been done and were we are going exactly.


I wrote a blog entry here: 
http://www.macruby.org/blog/2009/03/28/experimental-branch.html

2 big features in this branch: a LLVM-based JIT compiler and a new  
IO subsystem. Obviously performance-related, we really need to be  
faster.


Current status of the branch:

- The compiler is now able to pass most of the Ruby AST. It  
compiles nodes directly from the parser in a lazy fashion.

- Only JIT compilation for the moment (AOT is planned for later).
- The VM is still under development, it's not as complete as the  
compiler yet.

- Early performance benchmarks are very promising.
- By the time of this writing, we pass the vast majority of the  
language RubySpecs (a week ago we weren't even able to even  
bootstrap mspec!), about 1190 expectations. Work is very active in  
this area, we are also making sure the specs do run with the  
original Ruby 1.9 and writing missing specs.
- The new IO subsystem is mostly functional, but there are still  
many methods that are not implemented yet and we are working on  
this. Once it will be complete we will integrate a default runloop  
in the VM and expose asynchronous IOs.


For the near future, the goals are:

- Improving the compiler. Currently compile time has not really  
been optimized yet.

- Be able to run IRB. We are almost there.
- Remove the libffi code used to call C/ObjC implementations and  
instead JIT compile stubs and insert them in the dispatcher cache.  
We should be way closer to ObjC then (and maybe faster once we  
enable secondary compilations of hotspots and inline the stubs).

- Rewrite the BridgeSupport side using LLVM types.
- Implement full concurrent threading! (this is a big one :-)).
- And many more (check the TODO file for more info).

Once we arrive at a point when the branch is as functional as  
trunk, it will be merged in trunk and we will then work on  
stabilizing it, to later on release it as 0.5. The schedule for  
this release is unknown, it will be released when it will be ready  
(preferably this year though).


If you want to help let me know!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Richard Kilmer 

This is awesome new Laurent!

You have done amazing work to get this far and I know you will get it  
all the way.


Also Eloy and Vincent helped a lot with both the VM and specs and  
tests.  Thanks to all of you!


Do you have any plans for enlisting specific support you need to move  
things along faster?


Best,

Rich

On Mar 28, 2009, at 3:37 PM, Laurent Sansonetti wrote:


Hi guys,

As some of you already noticed we have been working on a branch for  
a few weeks and I thought it's now time to describe what has been  
done and were we are going exactly.


I wrote a blog entry here: 
http://www.macruby.org/blog/2009/03/28/experimental-branch.html

2 big features in this branch: a LLVM-based JIT compiler and a new  
IO subsystem. Obviously performance-related, we really need to be  
faster.


Current status of the branch:

- The compiler is now able to pass most of the Ruby AST. It compiles  
nodes directly from the parser in a lazy fashion.

- Only JIT compilation for the moment (AOT is planned for later).
- The VM is still under development, it's not as complete as the  
compiler yet.

- Early performance benchmarks are very promising.
- By the time of this writing, we pass the vast majority of the  
language RubySpecs (a week ago we weren't even able to even  
bootstrap mspec!), about 1190 expectations. Work is very active in  
this area, we are also making sure the specs do run with the  
original Ruby 1.9 and writing missing specs.
- The new IO subsystem is mostly functional, but there are still  
many methods that are not implemented yet and we are working on  
this. Once it will be complete we will integrate a default runloop  
in the VM and expose asynchronous IOs.


For the near future, the goals are:

- Improving the compiler. Currently compile time has not really been  
optimized yet.

- Be able to run IRB. We are almost there.
- Remove the libffi code used to call C/ObjC implementations and  
instead JIT compile stubs and insert them in the dispatcher cache.  
We should be way closer to ObjC then (and maybe faster once we  
enable secondary compilations of hotspots and inline the stubs).

- Rewrite the BridgeSupport side using LLVM types.
- Implement full concurrent threading! (this is a big one :-)).
- And many more (check the TODO file for more info).

Once we arrive at a point when the branch is as functional as trunk,  
it will be merged in trunk and we will then work on stabilizing it,  
to later on release it as 0.5. The schedule for this release is  
unknown, it will be released when it will be ready (preferably this  
year though).


If you want to help let me know!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #238: rdoc memleaks & segfaults when installing gems

2009-03-28 Thread MacRuby 
#238: rdoc memleaks & segfaults when installing gems
+---
 Reporter:  t...@…   |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:   
Component:  MacRuby |Keywords:  gem install rdoc 
+---
 Was trying to install some dependencies for a gem i am working on (so i
 can test it on macruby).  I get a lot of mentions that macruby has a non-
 zero refcount (all the info is in the trace).

 http://gist.github.com/87225

 installing w/ --no-rdoc & --no-ri works just fine :)

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] macruby experimental benchmark

2009-03-28 Thread रजनीश 

Hello,

banchmark is already impressive when compared to 0.4.

I ran the benchmark with:
1. clang -03 -arch i386 macruby 0.4
2. clang -O3 -arch i386 macruby 0.5
3. gcc-4.2 -O3 -arch i386 macruby 0.5

(clang is the C/ObjC compiler native to LLVM)

PS. clang currently doesn’t pass rake spec:ci (

== clang -03 -arch i386 macruby 0.4  

~/Developer/MacRuby-> ./miniruby -I./lib ../macruby-experimental/ 
bench.rb
user system  total 
real
10 fib(30)  2.61   0.01   2.62  
(  2.623886)
10 fib(35) 28.72   0.06  28.78  
( 28.809891)
tak 2.53   0.00   2.53  
(  2.524596)
tarai   2.06   0.01   2.07  
(  2.066017)
ackermann   2.41   0.00   2.41  
(  2.410433)
1000 times loop 0.33   0.00   0.33  
(  0.322564)
3000 times loop 3.24   0.00   3.24  
(  3.243957)
1000 while loop 0.89   0.00   0.89  
(  0.891436)
6000 while loop 5.50   0.02   5.52  
(  5.521020)
3000 msg w/ 0 arg   3.94   0.01   3.95  
(  3.947202)
3000 msg w/ 1 arg   4.01   0.01   4.02  
(  4.026623)
1000 super w/ 0 arg 7.42   0.02   7.44  
(  7.437519)
1000 super w/ 1 arg 9.54   0.02   9.56  
(  9.592043)
1000 #send  5.28   0.02   5.30  
(  5.309358)
1000 ivar read  2.04   0.00   2.04  
(  2.053376)
3000 ivar read  6.10   0.02   6.12  
(  6.119993)
1000 ivar write 2.15   0.01   2.16  
(  2.152597)
3000 ivar write 6.44   0.01   6.45  
(  6.449781)
3000 const  1.80   0.01   1.81  
(  1.803391)
3000 yield  3.52   0.01   3.53  
(  3.519516)
3000 msg w/ block+yield 6.40   0.01   6.41  
(  6.418424)
3000 Proc#call  8.64   0.03   8.67  
(  8.692045)
3000 while break2.51   0.00   2.51  
(  2.530938)
1000 block break   13.81   0.55  14.36  
(  8.429742)
3000 while next 2.29   0.00   2.29  
(  2.295239)
1000 block next 2.69   0.01   2.70  
(  2.702703)
6000 begin w/o exception4.98   0.01   4.99  
(  5.014342)
6000 ensure w/o exception   3.64   0.01   3.65  
(  3.647675)
5 raise 2.58   0.17   2.75  
(  2.077362)


=== clang -O3 -arch i386 macruby 0.5  
=

./miniruby -I./lib bench.rb
user system  total 
real
10 fib(30)  0.35   0.00   0.35  
(  0.353159)
10 fib(35)  3.89   0.00   3.89  
(  3.905832)
tak 0.22   0.01   0.23  
(  0.224368)
tarai   0.17   0.00   0.17  
(  0.162998)
ackermann   0.21   0.00   0.21  
(  0.211560)
1000 times loop 0.14   0.00   0.14  
(  0.138711)
3000 times loop 1.38   0.00   1.38  
(  1.386931)
1000 while loop 0.08   0.00   0.08  
(  0.082421)
6000 while loop 0.50   0.00   0.50  
(  0.493618)
3000 msg w/ 0 arg   1.05   0.00   1.05  
(  1.052416)
3000 msg w/ 1 arg   1.65   0.01   1.66  
(  1.646295)
1000 super w/ 0 arg 1.00   0.00   1.00  
(  1.003267)
1000 super w/ 1 arg 1.35   0.00   1.35  
(  1.357992)
1000 #send  0.45   0.00   0.45  
(  0.447047)
1000 ivar read  0.15   0.00   0.15  
(  0.151039)
3000 ivar read  0.45   0.00   0.45  
(  0.452225)
1000 ivar write 0.18   0.00   0.18  
(  0.178246)
3000 ivar write 0.53   0.00   0.53  
(  0.534289)
3000 const  0.50   0.00   0.50  
(  0.510684)
3000 yield  1.19   0.01   1.20  
(  1.194234)
3000 msg w/ block+yield 3.42   0.00   3.42  
(  3.425893)
3000 Proc#call  2.34   0.01   2.35  
(  2.346405)
3000 while break0.19   0.00   0.19  
(  0.191913)
1000 block break1.66   0.00   1.66  
(  1.670270)
3000 while next 0.24   0.00   0.24  
(  0.246752)
1000 block next 1.63   0.00   1.63

Re: [MacRuby-devel] macruby experimental benchmark

2009-03-28 Thread Laurent Sansonetti 

Hello,

I'm curious, how did you manage to build MacRuby with clang? I thought  
it did not support C++ yet. Did you use llvm-g++ maybe?


Laurent

On Mar 28, 2009, at 4:45 PM, रजनीश wrote:


Hello,

banchmark is already impressive when compared to 0.4.

I ran the benchmark with:
1. clang -03 -arch i386 macruby 0.4
2. clang -O3 -arch i386 macruby 0.5
3. gcc-4.2 -O3 -arch i386 macruby 0.5

(clang is the C/ObjC compiler native to LLVM)

PS. clang currently doesn’t pass rake spec:ci (

== clang -03 -arch i386 macruby 0.4  

~/Developer/MacRuby-> ./miniruby -I./lib ../macruby-experimental/ 
bench.rb
   user system  total 
real
10 fib(30)  2.61   0.01   2.62  
(  2.623886)
10 fib(35) 28.72   0.06  28.78  
( 28.809891)
tak 2.53   0.00   2.53  
(  2.524596)
tarai   2.06   0.01   2.07  
(  2.066017)
ackermann   2.41   0.00   2.41  
(  2.410433)
1000 times loop 0.33   0.00   0.33  
(  0.322564)
3000 times loop 3.24   0.00   3.24  
(  3.243957)
1000 while loop 0.89   0.00   0.89  
(  0.891436)
6000 while loop 5.50   0.02   5.52  
(  5.521020)
3000 msg w/ 0 arg   3.94   0.01   3.95  
(  3.947202)
3000 msg w/ 1 arg   4.01   0.01   4.02  
(  4.026623)
1000 super w/ 0 arg 7.42   0.02   7.44  
(  7.437519)
1000 super w/ 1 arg 9.54   0.02   9.56  
(  9.592043)
1000 #send  5.28   0.02   5.30  
(  5.309358)
1000 ivar read  2.04   0.00   2.04  
(  2.053376)
3000 ivar read  6.10   0.02   6.12  
(  6.119993)
1000 ivar write 2.15   0.01   2.16  
(  2.152597)
3000 ivar write 6.44   0.01   6.45  
(  6.449781)
3000 const  1.80   0.01   1.81  
(  1.803391)
3000 yield  3.52   0.01   3.53  
(  3.519516)
3000 msg w/ block+yield 6.40   0.01   6.41  
(  6.418424)
3000 Proc#call  8.64   0.03   8.67  
(  8.692045)
3000 while break2.51   0.00   2.51  
(  2.530938)
1000 block break   13.81   0.55  14.36  
(  8.429742)
3000 while next 2.29   0.00   2.29  
(  2.295239)
1000 block next 2.69   0.01   2.70  
(  2.702703)
6000 begin w/o exception4.98   0.01   4.99  
(  5.014342)
6000 ensure w/o exception   3.64   0.01   3.65  
(  3.647675)
5 raise 2.58   0.17   2.75  
(  2.077362)


=== clang -O3 -arch i386 macruby 0.5  
=

./miniruby -I./lib bench.rb
   user system  total 
real
10 fib(30)  0.35   0.00   0.35  
(  0.353159)
10 fib(35)  3.89   0.00   3.89  
(  3.905832)
tak 0.22   0.01   0.23  
(  0.224368)
tarai   0.17   0.00   0.17  
(  0.162998)
ackermann   0.21   0.00   0.21  
(  0.211560)
1000 times loop 0.14   0.00   0.14  
(  0.138711)
3000 times loop 1.38   0.00   1.38  
(  1.386931)
1000 while loop 0.08   0.00   0.08  
(  0.082421)
6000 while loop 0.50   0.00   0.50  
(  0.493618)
3000 msg w/ 0 arg   1.05   0.00   1.05  
(  1.052416)
3000 msg w/ 1 arg   1.65   0.01   1.66  
(  1.646295)
1000 super w/ 0 arg 1.00   0.00   1.00  
(  1.003267)
1000 super w/ 1 arg 1.35   0.00   1.35  
(  1.357992)
1000 #send  0.45   0.00   0.45  
(  0.447047)
1000 ivar read  0.15   0.00   0.15  
(  0.151039)
3000 ivar read  0.45   0.00   0.45  
(  0.452225)
1000 ivar write 0.18   0.00   0.18  
(  0.178246)
3000 ivar write 0.53   0.00   0.53  
(  0.534289)
3000 const  0.50   0.00   0.50  
(  0.510684)
3000 yield  1.19   0.01   1.20  
(  1.194234)
3000 msg w/ block+yield 3.42   0.00   3.42  
(  3.425893)
3000 Proc#call  2.34   0.01   2.35  
(  2.346405)
3000 while break0.19   0.00   0.19  
(  0.191913)
1000 block break

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Charles Oliver Nutter 

Laurent Sansonetti wrote:

Hi guys,

As some of you already noticed we have been working on a branch for a 
few weeks and I thought it's now time to describe what has been done and 
were we are going exactly.


Very cool stuff...some low-level benchmarks seem to have really 
excellent performance.


I know you probably don't need bugs filed against 'experimental' yet, 
but I had a couple questions:


1. Is there a way to tell what's compiling and what isn't? Some 
benchmarks I run are fast, and some others are incredibly slow. I'd like 
to know what's representative of actual performance.
2. Is there a way to turn off peephole optimizations? Lots of benchmarks 
out there, including some we have in JRuby, have a lot of dead code 
(like repeated assignments to a local variable). That's going to 
confound a lot of benchmarking, since most of the benchmark isn't 
actually being run. JRuby has a flag to turn off peephole optz (though I 
often forget to turn it on).
3. You probably know about these, but I noticed there are numerous 
problems with eval:


* Running an eval benchmark caused the system to blow up, claiming it 
ran out of space for machine code

* bindings appear to be missing altogether
* The binding associated with a block does not appear to work, as in p = 
proc { }; eval 'something', p.binding. This troublesome feature is one 
reason many local variable optimizations are much more difficult.


I'm looking forward to seeing future results and getting some guidance 
on where we can expect to see the best performance right now. I'd also 
love to talk about some techniques you're using to see if they'd be 
applicable for JRuby.


- Charlie
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Laurent Sansonetti 

Hi Charles,

On Mar 28, 2009, at 9:46 PM, Charles Oliver Nutter wrote:


Laurent Sansonetti wrote:

Hi guys,
As some of you already noticed we have been working on a branch for  
a few weeks and I thought it's now time to describe what has been  
done and were we are going exactly.


Very cool stuff...some low-level benchmarks seem to have really  
excellent performance.


Thank you :)

I know you probably don't need bugs filed against 'experimental'  
yet, but I had a couple questions:


1. Is there a way to tell what's compiling and what isn't? Some  
benchmarks I run are fast, and some others are incredibly slow. I'd  
like to know what's representative of actual performance.


Currently everything is compiled. It is possible to dump the LLVM IR  
by turning on the ROXOR_DUMP_IR variable in roxor.cpp. Generally when  
something is incredibly slow it's because of a runtime bug and not the  
compiler, though.


2. Is there a way to turn off peephole optimizations? Lots of  
benchmarks out there, including some we have in JRuby, have a lot of  
dead code (like repeated assignments to a local variable). That's  
going to confound a lot of benchmarking, since most of the benchmark  
isn't actually being run. JRuby has a flag to turn off peephole optz  
(though I often forget to turn it on).


It's possible by modifying the source code and comment the call to  
createInstructionCombiningPass() and createCFGSimplificationPass(),  
but I do not recommend to remove these because I think it would break  
the way we compile Dwarf exception handlers in blocks.


# In my personal benchmark suite I try to make sure these  
optimizations do not provide false positive numbers when comparing  
against YARV.


3. You probably know about these, but I noticed there are numerous  
problems with eval:


* Running an eval benchmark caused the system to blow up, claiming  
it ran out of space for machine code


Yes, currently calling eval with a literal string will call the JIT,  
so doing this in a loop will most likely eat all your memory :-)


I plan to address that later by fallbacking to the LLVM interpreter in  
some cases, but I doubt this will affect real-world applications.  
Also, there are ways to improve the JIT (nothing has been done yet).



* bindings appear to be missing altogether
* The binding associated with a block does not appear to work, as in  
p = proc { }; eval 'something', p.binding. This troublesome feature  
is one reason many local variable optimizations are much more  
difficult.


Yes as you noticed Binding has not been implemented yet :-( This is on  
the very top of my TODO list (needed for IRB) and I already know how  
to implement it without disabling our current "local variables into  
CPU registers" optimization.


I'm looking forward to seeing future results and getting some  
guidance on where we can expect to see the best performance right  
now. I'd also love to talk about some techniques you're using to see  
if they'd be applicable for JRuby.


Absolutely :-)

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] branches/experimental

2009-03-28 Thread Charles Oliver Nutter 

Laurent Sansonetti wrote:
It's possible by modifying the source code and comment the call to 
createInstructionCombiningPass() and createCFGSimplificationPass(), but 
I do not recommend to remove these because I think it would break the 
way we compile Dwarf exception handlers in blocks.


# In my personal benchmark suite I try to make sure these optimizations 
do not provide false positive numbers when comparing against YARV.


Ok, it would be nice if there were a simpler way to turn those off; I 
don't want to break 'experimental' completely, but it would be nice to 
get real benchmark results in these cases.


Yes, currently calling eval with a literal string will call the JIT, so 
doing this in a loop will most likely eat all your memory :-)


I plan to address that later by fallbacking to the LLVM interpreter in 
some cases, but I doubt this will affect real-world applications. Also, 
there are ways to improve the JIT (nothing has been done yet).


In Rails, as recently as 2.2 (I haven't checked 2.3) there's a small bit 
of eval'ed code used to look up constants. Before we fixed our parser 
performance, we found it was a bottleneck. So that's at least one 
real-world case.


Yes as you noticed Binding has not been implemented yet :-( This is on 
the very top of my TODO list (needed for IRB) and I already know how to 
implement it without disabling our current "local variables into CPU 
registers" optimization.


How will you do that? Given that a block can be used as a binding, you 
can't statically inspect contained blocks to determine which variables 
are used and which aren't. For example, this code:


  def foo
a = 1
bar { }
puts a
  end

  def bar(&b)
eval "a = 2", b.binding
  end

  foo

This should print out "2" but prints out "1" in 'experimental' right 
now. This one feature is the primary reason JRuby can only put local 
variables in registers when there's no blocks present. When there's a 
block present, any variable can be accessed via its binding at any time. 
I've argued for this feature to be removed, but I have been unsuccessful.


Current JRuby is also putting local variables in registers (via HotSpot 
doing so for Java locals) when there's no blocks present.


- Charlie
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel