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

81–90 of 254 posts

Re: Ruby is too slow for programming competitions

#81

Post by nossralf »

RyanZAG wrote: post #77

A lot of people are talking about the problem itself - which is interesting - but very often you run into real problems which cannot be simplified so easily (NP hard problems, many different other cases). In addition, when you need to do important calculations on a server for your product and you're using Ruby, you may very well end up requiring 10x as many servers. This is pretty massive when you consider an AWS ser…

Topaz [1] is a Ruby implemented using RPython (so it uses the same JIT mechanisms as PyPy).

[1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/

Re: Ruby is too slow for programming competitions

#82

Post by gnuvince »

I'm sorry, but is the Go program correct? I ran it on my machine, and for Case #1, it reports a solution of 1, while there are actually 19.

EDIT: I modified the Go program to use int64 instead of int (the upper bound of the first case is not a valid 32-bit integer), and the execution time is now much higher: 2 minutes 41 seconds on my laptop.

Re: Ruby is too slow for programming competitions

#83

Post by nossralf »

bvdbijl wrote: post #76
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.

Yeah sure. It's just that for performance reasons some languages really are better than others.

Agreed. If performance is the main (or an important) criteria for the competition then the choice of language is rather more significant.

Re: Ruby is too slow for programming competitions

#84

Post by Derbasti »

RyanZAG wrote: post #77

A lot of people are talking about the problem itself - which is interesting - but very often you run into real problems which cannot be simplified so easily (NP hard problems, many different other cases). In addition, when you need to do important calculations on a server for your product and you're using Ruby, you may very well end up requiring 10x as many servers. This is pretty massive when you consider an AWS ser…

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

Re: Ruby is too slow for programming competitions

#85

Post by sspiff »

I have noticed a similar thing recently. A programming challenge with a 10s max time restriction, and just reading the input and storing it in an array takes over 7 seconds.

I allocate the array ahead of time, as soon as I know the size.

The equivalent C/C++ version took under a second.

Re: Ruby is too slow for programming competitions

#86

Post by majke »

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…

I quickly checked my naive solution against cpython 2.7 and pypy-2.0-beta1 and it seems to be at least as fast as your code:

    ispalindrome = lambda a: a[::-1] == a

Re: Ruby is too slow for programming competitions

#87

Post by berdario »

tr4656 wrote: post #78
berdario wrote: post #75

Earlier quoted context omitted.

what does "ruby 1.9.3p194: 3.7 seconds" mean?

It means using Ruby 1.9.3 patch level 194 took 3.7 seconds.

ok, but on which code? he only posted the python implentation

which btw is a straight port of the original ruby script, that takes 53 minutes to run

so: 3.7seconds seems quite impossible

Re: Ruby is too slow for programming competitions

#88

Post by Karunamon »

davidw wrote: post #66

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 s…

You realize this is mostly a type of game right? "Do X task the best way you know how". If you think games are a waste of time, welp.

I'm clicking the down arrow, because not only are you being a dick, you're adding nothing to the discussion.

Re: Ruby is too slow for programming competitions

#89

Post by voidlogic »

Many people seem to be asserting just because the OP's algorithm was sub-optimal, that it means his Ruby code running slow vs Go is a non-issue. The problem is even well written Ruby vs Go has the same kind of performance divide:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... (All the usual benchmark disclaimers apply, your mileage may very, your app is always the best bench, etc etc.)

Re: Ruby is too slow for programming competitions

#90

Post by nossralf »

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?

If the goal of the competition is to slice apples, then a knife is pretty good compared to a gun. Or if the competition takes place under water. Or if you're Steven Seagal and the ship where you work is taken over by a splendidly over-acting Tommy Lee Jones and his gun-wielding minions.

Execution speed is nice, I don't disagree. But it's not always the be-all and end-all deciding factor for what tool to use to solve a problem in a specific context.

Competitions can be stressful, and choosing a tool that feels like an extension of yourself (be that Ruby, COBOL or whatever) is, to me, the better route. Compared to something that executes faster on your computer but not in your head.

Post reply on HN