

Lessons Learned in Large Computations with Ruby - champion
http://nirvdrum.com/2009/09/17/lessons-learned-in-large-computations-with-ruby.html

======
newsdog
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.

~~~
chasingsparks
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.

~~~
hyperbovine
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."

~~~
chasingsparks
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).

~~~
hyperbovine
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 :-)

~~~
chasingsparks
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!

------
megaduck
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.

------
weaksauce
_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.

~~~
Tichy
"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?

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

~~~
kscaldef
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.

------
Tichy
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)?

~~~
Periodic
"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.

~~~
Tichy
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...](http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=icpp&box=1)

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

~~~
Periodic
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.

~~~
Tichy
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.

