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

31–40 of 254 posts

Re: Ruby is too slow for programming competitions

#31

Post by aghoreyshi »

ClifReeder wrote: post #21
VeejayRampay wrote: post #2

Maybe the result would vary with JRuby or Rubinius (I'd be interested in benchmarks) because not only is Ruby itself not the fastest language, but its main implementation (MRI) is also not the best for speed.

This is a good point that I didn't consider. Running the 'just iterate over the range version' of this code with jruby: [master] clifff@fair_and_square: ruby -v jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_43-b01-447-11M4203 [darwin-x86_64] [master] clifff@fair_and_square: time ruby fair_and_square.rb C-large-1.in.bak real 6m39.105s user 6m37.762s sys 0m19.009s

What is sys time? The amount of time it's actually run on the processor?

Re: Ruby is too slow for programming competitions

#32

Post by ClifReeder »

electrograv wrote: post #8

Wow, 5 minutes in Ruby, and less than a second in Go? I know scripting languages are slow, but it's easy to forget just how much slower. (EDIT: Corrected misread number thanks to dljsjr). I don't want to detract from the article's main point with a cliche "algorithmic optimization beats fine tuning", but I think it's worth mentioning. Unless I'm mistaken, this particular problem can be solved about 10,000,000x more e…

To clarify, the Go program (which took under a second to run) was doing the same processing as the full Ruby program that took 50 minutes to run.

Re: Ruby is too slow for programming competitions

#34

Post by eatitraw »

aghoreyshi wrote: post #31
ClifReeder wrote: post #21

Earlier quoted context omitted.

This is a good point that I didn't consider. Running the 'just iterate over the range version' of this code with jruby: [master] clifff@fair_and_square: ruby -v jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_43-b01-447-11M4203 [darwin-x86_64] [master] clifff@fair_and_square: time ruby fair_and_square.rb C-large-1.in.bak real 6m39.105s user 6m37.762s sys 0m19.009s

What is sys time? The amount of time it's actually run on the processor?

No, it is the amount of time your program spent in system calls: http://stackoverflow.com/questions/556405/what-do-real-user-...

Re: Ruby is too slow for programming competitions

#35

Post by thinkpad20 »

This is a problem which is CPU-bound rather than IO-bound. Ruby, Python and the like won't typically show a great difference in speed when the majority of time is spent in IO operations (like web crawling, or text processing, running web apps, querying databases, etc), because the bottleneck on performance comes mostly from the slow reading of files and network sockets. In this case, though, the operations are mostly dependent on just doing computation, so a high-level interpreted language like Ruby really shows its limitations.

This is one of the (many) reasons why although languages like Ruby and Python are great for rapid development, on-the-fly updates and other reasons, it can pay dividends to be fluent in a high-performance language. It wouldn't even need to be C (although this wouldn't be hard to do in C) -- a language like D would give you excellent performance and nearly as easy development as Ruby.

Re: Ruby is too slow for programming competitions

#36

Post by bvdbijl »

nikic wrote: post #20

I also come to the conclusion that Ruby-like languages are just not the right tool for this kind of problem, but it should be pointed out that you would have been able to solve the 10^14 data set easily, even with Ruby. I was solving that problem with PHP and got it running reasonably fast (1s per range) for ranges up to around 10^60. PHP is probably faster than Ruby, but it's still in the same area. The first trick…

Yep, in a competition you want a language that had as little magic as possible. Languages like Ruby (not necessarily dynamic languages!) are just not really suitable for it

Re: Ruby is too slow for programming competitions

#37

Post by xyzzyz »

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, because he did not find the right solution for the problem. Instead, he wrote a brute-force solution with a simple optimization, and did not realize that this is the real cause of his code under-performing, blaming the Ruby's slowness for it, when he really should have blamed the Dunning-Kruger effect.

Re: Ruby is too slow for programming competitions

#39

Post by jmah »

aghoreyshi wrote: post #31
ClifReeder wrote: post #21

Earlier quoted context omitted.

This is a good point that I didn't consider. Running the 'just iterate over the range version' of this code with jruby: [master] clifff@fair_and_square: ruby -v jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_43-b01-447-11M4203 [darwin-x86_64] [master] clifff@fair_and_square: time ruby fair_and_square.rb C-large-1.in.bak real 6m39.105s user 6m37.762s sys 0m19.009s

What is sys time? The amount of time it's actually run on the processor?

The amount of time spent in system calls (i.e. the kernel).

Re: Ruby is too slow for programming competitions

#40

Post by nossralf »

bvdbijl wrote: post #36
nikic wrote: post #20

I also come to the conclusion that Ruby-like languages are just not the right tool for this kind of problem, but it should be pointed out that you would have been able to solve the 10^14 data set easily, even with Ruby. I was solving that problem with PHP and got it running reasonably fast (1s per range) for ranges up to around 10^60. PHP is probably faster than Ruby, but it's still in the same area. The first trick…

Yep, in a competition you want a language that had as little magic as possible. Languages like Ruby (not necessarily dynamic languages!) are just not really suitable for it

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.

Post reply on HN