6 ms·

Lessons Learned in Large Computations with Ruby

22 points by champion 17y ago

newsdog 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
        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 17y ago
        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 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!
- chasingsparks 17y ago
  Oh, and don't forget RubyInline. This guy posted a nice article on his blog: http://coreyhoffstein.com/2009/06/16/sorting-with-ruby-rubyinline-and-thrust/ http://coreyhoffstein.com/2009/06/16/sorting-with-ruby-rubyi...
- Periodic 17y ago
  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.
weaksauce 17y ago
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.
- donw 17y ago
  Or Java from JRuby; it's really useful to be able to just use a native Java class without any extra work whatsoever.
- Tichy 17y ago
  "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 17y ago
    The screwdriver is not "hampered by" its poor nail-driving capabilities.
    - kscaldef 17y ago
      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.
    - jwhite 17y ago
      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).
Tichy 17y ago
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 17y ago
  "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 17y ago
    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&lang=ghc&lang2=icpp&box=1 http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... I guess learning Haskell just moved up several steps on my TODO heap.
    - Periodic 17y ago
      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/ 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.
megaduck 17y ago
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.

22 points by champion 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
        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 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!
chasingsparks 17y ago
Oh, and don't forget RubyInline. This guy posted a nice article on his blog: http://coreyhoffstein.com/2009/06/16/sorting-with-ruby-rubyinline-and-thrust/ http://coreyhoffstein.com/2009/06/16/sorting-with-ruby-rubyi...
Periodic 17y ago
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.

weaksauce 17y ago

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.

donw 17y ago
Or Java from JRuby; it's really useful to be able to just use a native Java class without any extra work whatsoever.
Tichy 17y ago
"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 17y ago
  The screwdriver is not "hampered by" its poor nail-driving capabilities.
  - kscaldef 17y ago
    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.
  - jwhite 17y ago
    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).

Tichy 17y ago

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 17y ago
"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 17y ago
  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&lang=ghc&lang2=icpp&box=1 http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... I guess learning Haskell just moved up several steps on my TODO heap.
  - Periodic 17y ago
    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/ 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.

megaduck 17y ago

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.