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

61–70 of 254 posts

Re: Ruby is too slow for programming competitions

#61

Post by eric970 »

bambax wrote: post #29

I'm not a rubyist but it appears the OP was doing something like this: for each range (start to sqr(end)) for each number in the range check if the number is fair and square If you do this you're checking the same numbers many times (total count of numbers checked is over 3 hundred million calls...) The right approach is to first compute all fair and square numbers between 0-10^14, store the result, and then simply c…

Sounds right to me as well. But hey, isn't it much easier to blame the language and its VM? Or interpreted languages in general?

Re: Ruby is too slow for programming competitions

#63

Post by clarle »

MaxSize wrote: post #54

EventMachine helps with performance critical Ruby code

You're right that EventMachine helps when you're dealing with IO-limitations (like those commonly found in web applications), but for CPU-limited functions like the ones that you see in programming competitions, it's not going to provide much of a benefit.

Re: Ruby is too slow for programming competitions

#64

Post by raverbashing »

bajsejohannes wrote: post #53

For comparison, I translated it pretty directly to Python: import sys from math import sqrt def string_palindrome(num): s = str(num) return s == s[::-1] sys.stdin.readline() # throw away first line (number of cases) for count, line in enumerate(sys.stdin): found = 0 start, finish = [int(num) for num in line.split(" ")] sqrt_start = int(sqrt(start )) sqrt_finish = int(sqrt(finish)) for x in xrange(sqrt_start, sqrt_fin…

Check with PyPy if you can

Re: Ruby is too slow for programming competitions

#65

Post by trailfox »

nossralf wrote: post #40
bvdbijl wrote: post #36

Earlier quoted context omitted.

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.

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

Re: Ruby is too slow for programming competitions

#66

Post by davidw »

Great, so stop dicking around with some zero-sum game ( http://en.wikipedia.org/wiki/Zero%E2%80%93sum_game - a competition may only have one winner ) and go build a business, where no one cares what language you use as long as the solution works for your customers - and there can be more than one winner in many cases.

Or even if you don't have a side project or startup or something, go build something cool and open source it and do that, rather than working on some artificial problem.

You can click the little down arrow all you want, but it won't keep me from thinking you're mostly wasting your time with these competitions, and it won't put any money in your pocket.

Re: Ruby is too slow for programming competitions

#68

Post by TillE »

raverbashing wrote: post #64
bajsejohannes wrote: post #53

For comparison, I translated it pretty directly to Python: import sys from math import sqrt def string_palindrome(num): s = str(num) return s == s[::-1] sys.stdin.readline() # throw away first line (number of cases) for count, line in enumerate(sys.stdin): found = 0 start, finish = [int(num) for num in line.split(" ")] sqrt_start = int(sqrt(start )) sqrt_finish = int(sqrt(finish)) for x in xrange(sqrt_start, sqrt_fin…

Check with PyPy if you can

I just tested, and it should be about 6x faster than Python 2.7. About 1.0 second for the first fifteen cases.

Re: Ruby is too slow for programming competitions

#69

Post by bajsejohannes »

raverbashing wrote: post #64
bajsejohannes wrote: post #53

For comparison, I translated it pretty directly to Python: import sys from math import sqrt def string_palindrome(num): s = str(num) return s == s[::-1] sys.stdin.readline() # throw away first line (number of cases) for count, line in enumerate(sys.stdin): found = 0 start, finish = [int(num) for num in line.split(" ")] sqrt_start = int(sqrt(start )) sqrt_finish = int(sqrt(finish)) for x in xrange(sqrt_start, sqrt_fin…

Check with PyPy if you can

Good idea! Updated results.

Re: Ruby is too slow for programming competitions

#70

Post by ekr »

ConceitedCode wrote: post #43
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…

Even if he did brute force it, he did the same thing with Go and it was much faster. So by comparison Ruby is slow and his conclusion is sound. Yes he could have optimized it, but that just means he could of optimized the Go solution too.

In fact I don't think his conclusion is sound. If you're into algorithmic competitions you most likely don't need to change the language. If you devise a solution with a good enough complexity, the competition (if well designed) should allow enough time for the execution of that (near-)optiumum solution, while not awarding points for solutions which are asymptotically worse. The time taken by algorithms with different complexities vary with the size of the input, as a nonconstant function, while implementing the same algorithm in different languages will give you a difference of a constant factor.

What I'm trying to say, (stating the obvious): When the input is large enough, it doesn't matter what language you're programming in. And programming competitions should (and generally do) only focus on that.

But I'll admit that I'm a huge fan of optimizing my algorithms with bit-level operators, extreme care of memory allocation and other tools C offers.

Post reply on HN