Comments on: Random thoughts of the day

By: Corey

Corey — Tue, 16 Mar 2010 13:12:23 +0000

P.S. Good luck with the launch of your strategy!

By: Corey

Corey — Tue, 16 Mar 2010 13:12:05 +0000

Sorry I never replied tot this! Must’ve slipped by. Rubinius has worked out fairly well, though I have pretty much stopped using Ruby for anything other than i/o bound processes (web scraping, database maintenance, et cetera). For stuff like that, it doesn’t really matter what language I do it in because the bottleneck is in the i/o, not the speed of the language. I don’t see any reason why I couldn’t do my numerical analysis in Ruby instead of Matlab or R — I just think I have sort of segmented my tools to what I currently work most efficiently in.

I have been having some good fun playing around in Haskell, and there are a lot of available packages — lots more than I expected at least. And the community on freenode (#haskell) is extremely helpful to newcomers.

By: Jonathan Shore

Jonathan Shore — Sun, 07 Mar 2010 00:09:20 +0000

A late comment again. I’m curious how rubinius has worked out for you.

I started using jruby a couple of weeks ago as concluded that the functional structures in ruby are far better than any other OO lang have encountered. What one can do with blocks is awesome.

The jruby guys say it is 5x faster than ruby 1.8 and in recent tests faster than 1.9, but did not indicate #s.

There is also a project by Charles Nutter called Duby which adds type annotations (optionally) to ruby syntax. Numerical code at least, performs at the java level of performance I’ve been led to believe (which means it is comparable to C perf).

Duby is still too early stage probably to be usable I’m guessing.

By: Corey

Corey — Mon, 22 Feb 2010 14:17:27 +0000

I didn’t see any mention about allowing the time for byte-code compilation. JRuby would face the same issue — slow start-up simply because it has to compile the byte-code. The second time around, it should be much faster.

By: Shane

Shane — Mon, 22 Feb 2010 12:42:07 +0000

Have you looked at this benchmark?

http://antoniocangiano.com/2007/12/03/the-great-ruby-shootout/

It finds that Rubinius is slower than other Ruby VM’s.

By: Digital Dude

Digital Dude — Thu, 18 Feb 2010 22:10:48 +0000

Maybe something along the lines of FScript (www.fscript.org) would be more to your liking…

Cordially,

-Digital Dude-

“Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects.” -Alan Kay-

By: Corey

Corey — Sun, 14 Feb 2010 15:34:55 +0000

I took a look at Haskell a while ago when I started wanted to get back into functional languages after programming SML in school. I played with Erlang a bit, then leaned towards OCaml. I can’t remember why I didn’t spend anytime with Haskell. I will check it out again — thanks for the recommendation.

By: Andrew

Andrew — Thu, 11 Feb 2010 20:31:31 +0000

Have you looked at Haskell ? It’s fantastically expressive and much faster than Ruby once you know what you are doing. It’ll never be as fast as C but then nothing will.

By: Corey

Corey — Sat, 30 Jan 2010 22:51:06 +0000

No comparison between Rubinius and C++ — thought on my MacBook, generating the 40th fibonacci number (with a naive, non-optimized, non-memoized recursive algorithm) takes ~30s with Ruby 1.9, and ~9s with Rubinius — a considerable speed increase. I wouldn’t expect the speed to ever approach a statically compiled language because of all the run-time checks that need to occur. I am sure C++ would smoke Ruby — but for the ‘programmer cycles’ I can save writing code in Ruby, it is worth it to me. Plus, worst case scenario, I can just throw more processors at the problem using something like Ruby’s distributed object library (DRb). Real concurrency seems to be a far way off — the same issues plague Ruby that plague Python (see here). Lightweight threads (called Fibers) were introduced with 1.9, but they are non-preemptive, which defeats the purpose to me. I think JRuby, XRuby, and IronRuby are the only implementations that allow ruby to harness the power of multiple cores. Rubinius will soon have Multi-VM capabilities with IPC, so that should at least allow Rubyists to start dabbling more with concurrency.

For the most part, I have found Python vs. Ruby comparisons to be extremely biased by whoever is posting it. At this point in maturity, I think both languages are fairly comparable in speed. I simply chose Ruby because I liked its syntax more.

F# always seemed like an interesting possibility, but everything I have read has called it ‘too academic’ and too much of a ‘pet project’ than a real language to work with. I try not to be an early adopter of languages — I don’t like working in languages that don’t have a plethora of libraries to choose from. Let me know if you give it a spin.

By: tr8dr

tr8dr — Sat, 30 Jan 2010 21:38:51 +0000

Sounds cool. Have you done any performance comparisons of Ruby on Rubinius vs C++ or other VM environment?

I saw a comparison recently between Ruby and Python which showed the standard Ruby impl to be much faster than Python.

I am more curious as to whether Ruby with a good VM comes near to to statically typed languages in speed. I’ve had to disqualify Python in my environment due to its lack of concurrency and performance issues.

At this point I am leaning towards moving to F#. I’ve done some tests with mono, particularly with the new LLVM backend and was blown away with how far they’ve come on performance.