Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby is too slow for programming competitions

blog.clifreeder.com

Post reply on HN
Print view View original

161–170 of 254 posts

Re: Ruby is too slow for programming competitions

#161

Post by lbrandy »

jonhohle wrote: post #146
lbrandy wrote: post #127

Earlier quoted context omitted.

Everyone always agrees with this and, in my experience, has never really tried it. It works better in theory than in practice (or, at a minimum, it works only on a small subset of the types of problems that a naive view might otherwise lead you to believe). The problem is the data isn't organized in a way to be computation efficient, and all the C code in the world isn't going to make chasing pointers to pointers to…

I agree with it and have implemented it. After profiling a backfill script which was looking like it was going to take about two weeks to run, I found an area where certain bit-twiddling was being done which was extremely slow in Ruby. I rewrote this section in C, and was able to make this section 1000x faster then the ruby equivalent (this was MRI 1.8.5 several years ago). The total runtime for the script was brough…

I didn't mean to imply it wasn't ever possible. Just that the subset of things that it works great for is smaller than people wish, or believed. That "I'll write in Ruby and optimize in C when I need to" is a myth on the order of the "sufficiently smart compiler". There are things for which it just plain doesn't work. Things that are quite common.

Yes, you can make image transformations for your webapp fast by piping in a C-extension, because the C code can control the i/o and data organization as well as the algorithms. The integration surface is tiny. You can't, however, make the language's memory usage and garbage collection faster. At least not as easily. You won't be "dropping into C" to fix your garbage collection problems, at least not in the way people dream of when they think of "performance problems" at the outset.

Re: Ruby is too slow for programming competitions

#162

Post by estavaro »

fosap wrote: post #120
estavaro wrote: post #101

Earlier quoted context omitted.

Ruby is said to be useful for text processing and such. In Japan they had a need for the language to deal with text files specified in a Japanese codeset. Some of the flexibility to support different codesets cost Ruby a little. For Ruby 1.9 and 2.0, Matz took a while in the transition to "Unicode" support in order to keep some flexibility, even though many people preferred the old way of UTF8 and so on. Ruby is best…

I don't see the point with eval. Every lisp has a eval, and most AOT Lisps are faster than ruby. Not including eval seems to be a "discipline and bondage" fetish of language designers. Yes, you can write pretty awful code with eval. But it allows metaprogramming aswell. I'd like to judge if something is awful or awesome.

With eval language designers might have a delayed execution that could make compile-time optimizations less straightforward. Part of the toolset could have to be present during deployment time to be able to handle eval which happens at runtime. And yes, security concerns could also play a hand.

In Dart the code declaration is taken very seriously in many ways, and avoiding eval buys them more compile-time, loading-time and perhaps runtime optimization opportunities. I find that more than the language designers themselves, it's the end-users or developers that ask for more "bondage and discipline" from their tools. People who come from Java and C++ backgrounds, for example. They just can't have enough compile-time stuff aided by an IDE.

Re: Ruby is too slow for programming competitions

#163

Post by bbwharris »

He did everything right. Tried it in ruby, if it would have been fast enough this article wouldn't exist. Instead he applied good software engineering and found the right tool for the job.

This doesnt say "don't use ruby it's too slow". It's says prototype in your comfort zone and optimize. Isn't this what we all agree on?

Edit: auto correct fail.

Re: Ruby is too slow for programming competitions

#164

Post by threeseed »

frehpt wrote: post #153
threeseed wrote: post #139

Earlier quoted context omitted.

Go does't have 1/100000 the amount of libraries and support that Ruby or C does. Option A only seems simpler because you ignore the time/complexity in coding the task at hand.

> Go does't have 1/100000 the amount of libraries and support that Ruby or C does. That's what they used to say about Java...

Yes. Nearly 20 years ago.

But don't worry the JVM can save you. http://code.google.com/p/jgo/

Re: Ruby is too slow for programming competitions

#165

Post by drivebyacct2 »

xyzzyz wrote: post #37

Sure, I knew Ruby wasn’t going to be zomg fast, but I always assumed that if I chose the right solution and wrote in an efficient manner (memoizing, storing values/lookups that would be used later, limiting search spaces, etc), my ability to write code quickly and concisely mattered more than sheer processing speed. I was wrong. Sure, the author is wrong, but not because Ruby is slow (it is, though). He's wrong, beca…

Amazingly, both his implementation and Ruby can be independently slow.

Re: Ruby is too slow for programming competitions

#166

Post by threeseed »

kgabis wrote: post #152
threeseed wrote: post #139

Earlier quoted context omitted.

Go does't have 1/100000 the amount of libraries and support that Ruby or C does. Option A only seems simpler because you ignore the time/complexity in coding the task at hand.

Why not 1/10e100? Or even less? Go's library support is quite nice already and it's growing really fast.

Because I am being realistic. Ruby, C, Java etc have had decades to build a comprehensive set of developer libraries. Go hasn't.

It's a "cute" platform that I am sure will beat Ruby in a few benchmarks. But I don't see any reason why anyone would seriously consider it for a real world app.

Re: Ruby is too slow for programming competitions

#167

Post by tonycoco »

This whole, "Ruby is slow," diatribe is just ridic.

Everyone here that has done any C/C++ or Ruby development would probably agree that if you're looking for number smashing, Ruby is just not cutting it unless you're into rockin' C extensions and getting what you want... for now.

Ruby, within a few years, will probably have some VM action, whether the JVM with JRuby or Rubinius wins out, who cares.

In any case, in like 5 or 6 years when we all have 50/100 core machines, Ruby's gonna be just fine for almost everything. Maybe by then we will be done arguing and just agree that Ruby is the nicest language to look at and develop in, even if it has subpar performance. Because if you're arguing something different, you've probably never gone from Ruby to C or Java or even Python... just so you all know, it blows.

Re: Ruby is too slow for programming competitions

#168

Post by learc83 »

lbrandy wrote: post #127
Derbasti wrote: post #84

Earlier quoted context omitted.

> having half your product in Ruby and half in C is awful to have to deal with. Why? In many cases, only a tiny fraction of your code needs to be fast. In my experience, it is very reasonable to code that part in some fast language while delegating the bigger (and often more complex) part in a higher level language such as Ruby.

Everyone always agrees with this and, in my experience, has never really tried it. It works better in theory than in practice (or, at a minimum, it works only on a small subset of the types of problems that a naive view might otherwise lead you to believe). The problem is the data isn't organized in a way to be computation efficient, and all the C code in the world isn't going to make chasing pointers to pointers to…

A huge swath of the game industry is based on just this kind of architecture.

The engine is built in C++ and the logic is coded in some higher level scripting language. Seems to work fine for them.

Re: Ruby is too slow for programming competitions

#169

Post by reeses »

vidarh wrote: post #157
lbrandy wrote: post #127

Earlier quoted context omitted.

Everyone always agrees with this and, in my experience, has never really tried it. It works better in theory than in practice (or, at a minimum, it works only on a small subset of the types of problems that a naive view might otherwise lead you to believe). The problem is the data isn't organized in a way to be computation efficient, and all the C code in the world isn't going to make chasing pointers to pointers to…

I have tried it. My MSc dissertation required a lot of computation (weeks of runtime after I'd rewritten critical portions in C++), and I'd do it that way again. For many types of problems, putting the data into an efficient format before passing it to your C/C++ code is trivial in terms of both difficulty and time spent. I prototyped everything in Ruby, profiled, and then rewrote a handful of the critical parts in C…

We don't call 'scripting languages' 'glue code' for nothing.

If more people thought of FFI/RPC/etc. as just another pipe-and-filter framework, they'd be less reluctant to write properly-defined, performance critical, pieces in a more performant environment.

Then again, your use of a profiler and FFI/pipe/whatever is a secret weapon that seems to be one of the things that separate 1x from 10x engineers. :-)

Re: Ruby is too slow for programming competitions

#170

Post by spoiler »

trailfox wrote: post #65
nossralf wrote: post #40

Earlier quoted context omitted.

Wouldn't you want to use a language that is familiar in a competition? If Ruby is your forte, surely you should use it? I fail to see how "magic" properties of a language matter if you've got reasonable algorithmic chops and focus on solving the problems rather than trying to be clever.

> Wouldn't you want to use a language that is familiar in a competition? If Ruby is your forte, surely you should use it? If you're familiar with knives why not bring a knife to a gun fight? If knives are your forte, surely you should use it?

Considering I don't know how to shoot a gun, and I know how to throw stuff, I could at least throw the knife and hope the sharp end finds the target.
Post reply on HN