Comparing Ruby Performance

Posted by Scott Hughes Mon, 28 Nov 2005 19:50:00 GMT

My old friend P.O. Boykin recently took a look at Ruby (and other scripting languages) and came up with a very interesting post: Performance of Programming Languages

After spending time with so called “scripting languages” (a term that I feel is not a terribly well defined or useful), I have found that I enjoy programming in languages like Ruby, Python, and Boo more than languages like C, C++, Java, or C# (though C# is getting better and better as they improve the language). My question is: how much performance do I loose by adopting one these laguages. To answer this question I took a look at the Language Shootout site.

I hadn’t heard of the Language Shootout site; that’s a very interesting link. They compare the implementations of your favorite programming languages (and are very careful not to say they compare the actual language, just the implementation) and produce a whole lot of “at-a-glance” graphs.

I’m a very recent fan(atic) of Ruby. I still don’t “think” in Ruby, just because I don’t have enough trench time with it. But I subscribe to the Google group RSS feed for comp.lang.ruby, and it’s very common to find code snippets (usually in response to a question) that just make me smile. Since more than half of the work I do at my job is using a PC to communicate with a significantly slower device (parallel FPGA, usb or serial Micro, or a 1-Wire device), I try to sneak scripting solutions in wherever I can. If the PC takes 100x more cpu time to compute a message that is going to be put on a slow bus (several orders of magnitude slower than the cpu) noone is going to notice the loss of a few extra nanoseconds. That said, I usually need to hand code off to other people (those so-called “paying customers”) and using a more popular programming language (C or Java) makes that hand-off much easier.

But for some of my tasks, Ruby’s elegance outweighs any of the performance penalties. Ruby is still fairly young, so I’m hoping that in the near future it will reach a good level of general acceptance and gain some significant performance improvements (thanks to all the eyes it now has on it). Also, I think it’d be interesting to run the same benchmarks the Language Shootout guys did, but using either YARV [1] or RB2C [2]. Seems that if those projects don’t do better than vanilla Python, they should re-think their solution. It’d be nice to see if they are able to tighten the large margins between the Java or .NET runtime.

[1] YARV: Yet Another Ruby VM - http://www.atdot.net/yarv/

[2] RB2C : a Ruby to C converter http://www-lab09.kuee.kyoto-u.ac.jp/~hiwada/ruby/rb2c/

Posted in  | Tags , ,  | 4 comments

Source for 1-Wire Java-USB Project

Posted by Scott Hughes Sun, 06 Nov 2005 06:06:00 GMT

I’ve finally gotten around to creating a source tarball for the work I did to get the Public Domain Kit support files for libUSB running under the 1-Wire API for Java. 80% of the work here was figuring out what to do, so you’ll find there isn’t a lot of code to glue them together. It would be pretty easy, for example, to swap out the PDK files for libUSB with the DS1410E link-level files for Linux. Then you could have parallel port support using the 1-Wire API for Java under Linux as well as the USB port.

The Makefile is geared towards Mac OSX. Everything else, including the C source in the ‘native’ folder, is platform independent and should compile everywhere libUSB does. Using Sun’s reference on how to build JNI libraries for the various platforms, you should be able to modify the Makefile to support your platform. If you have any suggestions for improving the build process, especially if you can help make it a cross-platform Makefile, then please let me know.

PDKAdapterUSB.tar.gz (444kb)

Posted in ,  | Tags , , , ,  | 1 comment

RubyConf

Posted by Scott Hughes Sat, 15 Oct 2005 00:13:00 GMT

RubyConf 2005 is underway and I’m hoping that the slides from the presentations will be available soon. I found that Kevin Clark is live-blogging RubyConf and is doing a pretty good job of it (Thanks, Kevin!).

His notes from the progress report on YARV: Yet Another Ruby VM are an especially interesting read. Maybe YARV will finally help answer the question, “Does RubyOnRails Scale?”

Thanks to Ezra Zygmuntowicz, you can start listening in on some presentations as well.

Update: Matz’s slides from his keynote speech on the future of Ruby are now available online. He talks about a lot of cool ideas that are going to keep Ruby 2.0 very fun. There’s even a video(198mb).

Posted in ,  | Tags , ,  | no comments

Rogue Software Development

Posted by Scott Hughes Thu, 22 Sep 2005 16:33:00 GMT

I happened upon this amazing story (via Wired). The incredible Graphing Calculator application, which is included with Macintosh computers, was actually a clandestine, rogue project at Apple. A contractor, whose project was cancelled, continued to sneak into the building and work on the application.

I asked my friend Greg Robbins to help me. His contract in another division at Apple had just ended, so he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive. We worked twelve hours a day, seven days a week.

Thanks to all his hard work, Graphing Calculator was bundled in with the OS and was initially shipped on more than 20 million machines. That’s a pretty good sized audience.

When we had a test Mac at my first co-op job, I wasted a few hours playing around with Graphing Calculator. It was almost enough to make me ‘switch’ back then… Though, college students who are paying their own way through college have a hard time affording a Mac (until the Mac Mini anyways). Wondering why he didn’t ship a version of it with Windows?

We wanted to release a Windows version as part of Windows 98, but sadly, Microsoft has effective building security.

Posted in  | Tags , ,  | no comments

JSR-277 Might Fix Java

Posted by Scott Hughes Fri, 26 Aug 2005 13:25:00 GMT

Thanks to Ted Neward, I just read about this interesting new Java Specification Request: JSR 277

The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:
  1. A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
  2. A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
  3. A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
  4. Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
  5. A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.

Modules with metadata about their dependencies sounds like just what the doctor ordered. It’s crazy that Java has such a large and pro-active userbase, yet it is so slow in catching up to the fledgling .NET. Item #1 and #2 should’ve been implemented a long time ago, and Sun knows it. I agree with Ted as well when he says:

About the only thing I *wish* we could do that’s out-of-scope to the JSR is to fix the javac compiler to cease emitting .class files directly, but instead consider .class files to be the moral equivalent of C/C++-compiled .obj files, and automagically do that final step and turn it into a .jar file right out of the box. (Out of curiosity, is there anybody out there who doesn’t immediately jar up your .class files?)

I know I immediately jar mine up, except in the cases where I’m prototyping with a single .class. If Javac auto-jarred, that wouldn’t bother me in that case.

Posted in ,  | Tags ,  | no comments