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

101–110 of 254 posts

Re: Ruby is too slow for programming competitions

#101

Post by estavaro »

voidlogic wrote: post #89

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

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 when it's used for the things it was meant for, but that hasn't kept people from trying to use it for more stuff. That's how Ruby found a good use in servicing web apps, first with CGI and then with dedicated instances in Rails and the like.

Now with Dart I understand that people demand languages be architected in different ways to extract more performance from them. Dart doesn't have "eval", for example. Whereas Ruby and Javascript do.

The question though is one of a divide, between the people who would never use Ruby or JavaScript and those who do use and love those languages that come with a lot of flexibility from the core. Python is like Ruby and JavaScript, even if the Python syntax could be borrowed for different languages that are more restricted in what they offer.

Re: Ruby is too slow for programming competitions

#102

Post by bajsejohannes »

berdario wrote: post #87
tr4656 wrote: post #78

Earlier quoted context omitted.

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

I'm using the ruby code from the blog post. I'm also just running the 15 first test cases out of the 10001 he uses.

Re: Ruby is too slow for programming competitions

#103

Post by afeezaziz »

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 have tested PyPy and think that it is good that I would be able to use Python to write faster loops.

Re: Ruby is too slow for programming competitions

#104

Post by sspiff »

yxhuvud wrote: post #99
sspiff wrote: post #85

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.

How did you read the input? All at once or one line at a time?

One line at a time. Is that significantly slower for stdin? I would assume that this wouldn't make a difference, since we're talking about simple memory operations, and 20k method invocations shouldn't be that hard on a modern system.

Re: Ruby is too slow for programming competitions

#105

Post by igouy »

voidlogic wrote: post #89

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

> All the usual benchmark disclaimers apply...

The actual disclaimers shown on the benchmarks game website apply ;-)

Re: Ruby is too slow for programming competitions

#106

Post by igouy »

rsiqueira wrote: post #79

Even using the same algorithm implementation, there is a huge speed processing difference between languages. For example the implementation of the Mandelbrot algorithm in RUBY takes 47 MINUTES to complete, while it takes LESS THAN 30 SECONDS when doing the same computation using much faster languages such as JAVA, SCALA, C or FORTRAN. According to this performance test, those languages are more than 100 times faster…

> between languages

Between specific programs, using specific programming language implementations.

Re: Ruby is too slow for programming competitions

#107

Post by georgemcbay »

nossralf wrote: post #90
trailfox wrote: post #65

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

I don't think the parent post (which I totally agree with) was saying that you must always decide by picking an inherently fast language, but rather if you decide to pick one whose execution time is not inherently fast to enter a competition where execution time is factored you will start with a major disadvantage.

That doesn't mean you'll lose (ala your Steven Seagal analogy), maybe you're so much better than everyone else that you can overcome the disadvantage, but you'll surely be starting in a bad position compared to someone holding a 'gun' even if he or she is somewhat less skilled at using the gun than you are at using the knife.

Re: Ruby is too slow for programming competitions

#108

Post by victorhn »

wting wrote: post #98

First of all, there are plenty of people who solved both large inputs with Python/Ruby (with and without pre-computing all the fair and square numbers).[0][1] As others have stated, the contests are designed such that language shouldn't matter and problem sets are deemed solvable with Python as a baseline. For this particular question, the official contest analysis goes into detail on how to reduce the solution space…

Correct Link for [0] is

http://www.go-hero.net/jam/13/solutions/0/3/Ruby

And the most difficult version (L2) was solved by 19 contestants.

Re: Ruby is too slow for programming competitions

#109

Post by Aaronneyer »

The Go solution is incorrect. It's not using int64, and most of the finishes are bigger than a 32bit int. If you run it on the following input: """ 2 8 10000200002 1 500 """ You will see that the loop that runs from start to finish is not running on the first case, because it sees the finish as 0. Haven't tested it using int64, but I would imagine it would be much slower(Still a decent bit faster than Ruby presumably), because any heavy computation for this problem was removed.

Re: Ruby is too slow for programming competitions

#110

Post by yyqux »

Luyt wrote: post #56
g3rald wrote: post #5

There is a huge difference between Ruby and Go, in terms of performance. I wonder if anyone has any experience with Python, considering that both are interpreted programming languages.

Actually, Python is compiled (just like Java, C#, Ruby) to bytecode which is executed in a virtual machine. It is the dynamic nature of certain languages that can make them slower than languages that are statically typed.

And then the bytecode is interpreted. It's faster than interpreting the AST or source directly, but it's still pretty slow.

Java compiles the bytecode on the fly. Back in older JVMs where Java interpreted the bytecode it was also slow as hell.

Post reply on HN