Lessons Learned in Large Computations with Ruby | Hacker News Reader

Lessons Learned in Large Computations with Ruby

nirvdrum.com

22 pointschampion33 comments

Listen friend, this isn't what Ruby is good at.

Acquire a C program, a C-Assembler program if possible and drive it from Ruby with an API.

Don't do mad cranking with Ruby.

Ditto. I spend 95% of my time writing Monte-Carlo based financial simulations. Obviously, they are computationally intense. That being said, after many years, I finally figured out that prototyping in in a scripting language (formerly Python now Ruby) and then factoring out parts into other languages for speed (usually just a C++ or C/CUDA binary via a `cmd` call) makes me 100 times more productive than just doing it in C.

Funny, I do a lot of stuff with Monte-Carlo* as well and I have reached the opposite conclusion. It's soooo much easier (and more pleasurable) to prototype in Python versus chasing down null pointer violations all afternoon. At least for my simulations I have always found that 90+% of the execution time is spent in one or two routines which can then be factored out into C (or FORTRAN, which is faster.) Also, it's much easier to inspect and graph your data in Python; when I develop in C I tend to skip these things because they're such a PITA. I can't help but wonder what I'm missing.

Although, at a 100x productivity increase, I might have to give it another look; I'd be out of grad school by Halloween.

*For the uninitiated, Monte Carlo is a fancy way of saying "for loops."

I think you misinterpreted what I said. I prototyped formerly in Python, and now with Ruby. I also do not chase down null pointer violations most of the time (except when debugging any CUDA exported functions that need speed).

Ahh, righto, sure did! Well then we agree. How do you like CUDA? We just took delivery on a 4xTesla C1060 box which I can't wait to check out. Sadly it's sitting in a closet right now because of departmental squabbling over who must foot the air-con bill when it gets plugged in :-)

I have a single C1060 on my desktop system -- it is the single greatest investment I have ever made. Granted, debugging CUDA is not great, but the for many things Thrust alone (http://gpgpu.org/2009/05/31/thrust) can make demolish any bottlenecks so you can get closer to your idea rather than spending all your time on metal. However, I have to play with OpenCL...especially now that OSX has built in support!

Oh, and don't forget RubyInline. This guy posted a nice article on his blog: http://coreyhoffstein.com/2009/06/16/sorting-with-ruby-rubyi...

When you get down to it, all the code really just ends up being machine code. Many popular languages now allow you to build interfaces to use the generic C libraries.

This lets you do the complicated, high-level stuff in a language suited for it, and do the nitty-gritty stuff in C or your favorite compiled language.

It's very important to pick the right tool for the job, and these days that doesn't even have to be one tool at a time.

This is exactly why our company is using a combination of JRuby and Java. There's some big "infrastructure" bits (like search) that really are better done in Java, and it's wonderful to be able to leverage that while still using nice terse Ruby for the majority of our code.

There are those that prefer to use MRI or YARV with C, and more power to 'em. However, I'm getting too old and lazy to spend all my time chasing down memory bugs.

My takeaway from the project is that Ruby is a great language hampered by a terrible execution environment.

He has a problem with execution speed and blames the tool instead of using the correct tool for the job. I could probably hammer a nail in with the back of a screwdriver but it would be better to learn how to use the hammer. Sigh. Call C from ruby/python/any interpreted language if you NEED speed.

Or Java from JRuby; it's really useful to be able to just use a native Java class without any extra work whatsoever.

"blames the tool instead of using the correct tool for the job"

Uh, why the negativity? Basically he is saying that Ruby is not well suited to certain tasks. How does that differ from what you say?

The screwdriver is not "hampered by" its poor nail-driving capabilities.

Okay, but I can write code just as quickly in Perl or Python and it'll be several times faster than Ruby. I can write that's Haskell that's just as elegant and concise (although it takes me slightly longer) and that runs orders of magnitude faster.

Increasingly, I'm unclear on what this unique advantage is that Ruby supposedly has that makes up for the atrocious implementation.

Among other things, he saw segfaults in the GC and found the debugger randomly detaching from the target process. I'd say that's a terrible execution environment, and orthogonal to speed.

Sometimes you don't see how bad a tool is until you push it's limits, and I'd say that's just what he did. To use your analogy, I can buy a $2 screwdriver that works fine in many cases, but the shaft might snap or bend if I apply too much torque to it (and no nails in sight).

Any advice for programming languages that are both fast and pleasant to use? How does LISP fare? Or maybe Haskell (because of the static typing)?

"Pleasant to use" is not benchmarkable, it is subjective. You can benchmark the speeds and figure out which one runs something faster, but it's very hard to quantify what languages are the most pleasant to develop in.

Some people like OO, some people like FP. Some people like things explicit, some people want things inferred.

All these popular languages are built around various trade offs. As I understand it, the functional languages allow you to use FP for your high-level stuff, but tend to be a bit slower than C (like one order of magnitude). Ruby has a lot of flexibility and allows for rapid development, but can be very slow for some things. C is fast, but it's C.

Get what I mean? Try a few. Find a language that works the way you think.

OK, different attempt then: are there ANY other choices than C/C++ and Java for high performance computing? (No Fortran please, I suppose).

I think there is a fundamental reason why languages with dynamic types will usually be slower than languages with static types, but some statically typed languages should be able to compete in terms of speed?

I suppose that puts Scala and Haskell on the map. I am not a 100% sure about LISP - I think there are variants where static types are optional?

Nitpicking aside, let's assume "pleasant to use" means "deemed cool by the HN crowd". Just give me some suggestions, then I can still decide if I agree or not.

Edit: in the flawed language shootout, Haskell seems to kick ass: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

I guess learning Haskell just moved up several steps on my TODO heap.

Play around with the Computer Language Benchmarks Game. It's good at showing what some of the trade-offs are. Of course, it's really not very scientific, but it gives you an idea. http://shootout.alioth.debian.org/

You'll usually see C, C++, Java, Haskell, OCaml, Fortran, Scala, and Lisp in the 1-10x range (of the fastest solution). They all should be reasonably competative on most things, and so you might make your decision based on personal preference and available libraries.

This is in contrast to things like Ruby, Perl, and Python which are often take 100x the time.

Thanks - I really need to pick up one of these languages. I know Java well, but don't want to use it anymore. So far I have only tried "slow" alternatives, though. Given my interests (machine learning), sometimes speed is called for.

C# and Ada are typically fast as well (as expected).

Interestingly, Erlang and Lua seem to consistently come out a bit ahead of almost everything else that's not compiled to native code, running on a JITing VM, and/or Lisp.

> http://shootout.alioth.debian.org/gp4/

Please choose the up-to-date measurements instead of these.

Which ones do you mean?

At the top of

   http://shootout.alioth.debian.org/gp4/

you'll see an "UP-TO-DATE MEASUREMENTS" url

Do you think those labeled "22 Sep 2009" are more up to date than those labeled "mid 2008" or "late 2007"?

If you hadn't said anything, I wouldn't have noticed that these are links. Blame it on the layout of the site.

Did you notice the "PLEASE CHOOSE THE UP-TO-DATE MEASUREMENTS INSTEAD OF THESE!" ?

I have used two varieties of Lisp: Common Lisp and Clojure. Both have dynamic typing with optional "type hints", which allow you to get the performance of a statically typed language. Type hints are typically used only in small doses, for parts of your code that are very performance critical.

>(No Fortran please, I suppose).

I've got a friend who works on simulating air currents around areroplanes real-time. They have to do everything in Fortran but he says that Fortran-99 is actually pretty pleasant. Pretty pleasant compared to older fortrans perhaps :)

Haskell does well in benchmarks but this hides the fact that its performance is very unpredictable. Try it and you'll see what I mean. Also, Common Lisp does well in benchmarks but only after a lot of declarations are added which make the code nearly unreadable.

Personally I get the best results from the MLton SML compiler. OCaml is also pretty fast and more practical. YMMV.

I do not consider Perl especially pleasant to use but it's faster than every other scripting language and it has a killer library. So if you're looking to avoid C but can't stomach the slowness of Ruby or Python consider it.

> it's faster than every other scripting language

http://shootout.alioth.debian.org/u32/lua.php

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Lisp will smoke out everything but C. And there it can get fairly close.

http://xach.livejournal.com/199225.html

http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

http://www.lrde.epita.fr/~didier/research/verna.06.labri-sli...

Perhaps one day someone will "properly tune the corresponding LISP code by introducing the proper type declarations..." for the benchmarks game programs -

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Reply on news.ycombinator.com