[MacRuby-devel] experimental branch: status update

[Jordan Breeding]

The clang support seems to be pretty solid. It does use llvm-g++ to  
compile the C++ files as noted, so that helps while clang itself  
doesn't do C++.

I am attaching another patch that helps out when clang can't be found  
in /usr/bin, and also looks for gcc/g++ in /Developer (or where you  
have Dev Tools installed) if they can't be found in /usr/bin for some  
reason.

Long term something interesting might be building more in the style of  
Xcode (build each arch, use lipo to assemble them into one file) so  
that -O4 could be used to see if it gets any additional speed out of  
the MacRuby code. I don't have the time to tackle that one right now  
however.

Jordan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: macruby-patch-for-rake.diff
Type: application/octet-stream
Size: 2157 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20090629/5dfdc44b/attachment.obj>
-------------- next part --------------


On Jun 29, 2009, at 15:19, Laurent Sansonetti wrote:

> Last week's status on the experimental branch work!
>
> - It's now possible to build MacRuby with clang (assuming you  
> installed it) by issuing the following command:
> $ rake use_clang=true miniruby
> This will compile all C and Objective-C files with clang and C++  
> files with llvm-g++. Apparently the build's product works as  
> expected. However, since clang is a moving target and since it does  
> not support C++ yet, this option is not enabled by default even if  
> you have clang in your system.
> - Threads!
>
> A first multi-threaded design for MacRuby was implemented. The idea  
> behind this design is to map a Thread object to a native POSIX  
> thread and make sure its related block will most always run in a  
> concurrent fashion.
>
> In order to achieve this, we created a new class called Core, which  
> is a singleton object containing all the data structures that should  
> be shared across all threads. The Core object contains a lock that  
> is used every time a shared data structure is accessed. Shared data  
> structures are for example: LLVM caches, various stubs caches,  
> BridgeSupport caches, etc.
>
> Everything else was moved to a VM class, which is completely lock- 
> free. A VM object is created at demand and only once for every  
> thread that wants to access the runtime. The VM object contains data  
> structures for the very specific thread execution, like for instance  
> current blocks, bindings, exceptions, etc. The VM sometimes calls  
> the Core (when defining a method for example) which acquires the  
> Core lock, but most of the time it just runs concurrently. All  
> MacRuby threads are scheduled by the OS kernel and registered into  
> the Objective-C garbage collector (which runs on its own threads)  
> before doing anything.
>
> This implementation is not quite finished yet and will be polished  
> in the near future, but it's already very promising. It passes all  
> the RubySpec core/thread expectations and according to a few  
> benchmarks we can finally use multiple CPU cores. I was able to run  
> some micro-benchmark code (like fib(40), method dispatch loops,  
> etc.) on 8 different Threads on a Mac Pro and MacRuby was using 800%  
> of the system (all 8 cores) vs only one in the case of Ruby 1.9.
>
> Obviously since threads are concurrent it means the developer must  
> take this into account and use mutexes to secure access to a shared  
> object (local variable, instance variable, etc.), which is not  
> necessarily needed in Ruby 1.8 or 1.9 because threads don't run  
> concurrently.
>
> Also, Thread#kill is supported but is really discouraged because  
> it's not deterministic.
>
> I wrote for fun a simple web server on top of Foundation's run loop  
> that dispatches new HTTP requests to a pool of threads, to test a  
> little bit our implementation and see if it's stable. I stressed it  
> with ab(1) (Apache benchmarking tool) and it's quite good, there are  
> still 2-3 random bugs but I think I identified all of them. If  
> you're interested, the simple web server was committed in sample- 
> macruby/Scripts/web_server.rb.
>
> That's all folks! Threads was really the last piece of functionality  
> missing in experimental vs trunk. Now it's time to converge and try  
> to fix all the remaining bugs.
>
> Laurent
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3820 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20090629/5dfdc44b/attachment.bin>