Awesome job Laurent, as usual! - Matt
On Mon, Jun 29, 2009 at 1:19 PM, Laurent Sansonetti <lsansone...@apple.com>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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
