Ruby is too slow for programming competitions • Hacker News Board

Re: Ruby is too slow for programming competitions

#251

Post by Spakman » Tue, Apr 23, 2013, 11:50 AM UTC

rockasaur wrote: post #234

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…

Do you think we as a community should be pushing for a potential rewrite of MRI to get rid of the GIL? I feel as if the GIL is what is limiting true ruby performance. It also seems like Matz and ruby core team don't really give a shit about performance. It is very possible to achieve a high level of performance on an interpreted language!!

I don't think that it's true that the core developers don't care about performance at all.

There's an argument that removing the GIL would require a lot of effort for little gain (and in some cases decreased performance). It's just not a priority for them.

Of course, every use case is different (sometimes very different), but I haven't ever hit a problem that has caused me to curse the GIL.

Re: Ruby is too slow for programming competitions

#252

Post by up_and_up » Tue, Apr 23, 2013, 2:02 PM UTC

pkolaczk wrote: post #243

up_and_up wrote: post #205

Earlier quoted context omitted.

A really simple solution in that case is to run JRuby and then write computationally intensive code in a JVM compatible lang like Scala or Clojure. This route seems popular since you can easily give JRuby access to your Scala classes.

Right, but if already writing in Scala, why ever write some parts of code in Ruby? Scala gets you expressivity of Ruby with additional benefit of static typesafety.

Well a pretty typical scenario is you are writing a ruby app and run into an area that needs additional horsepower (say a gaming API or something). Being on JRuby would give you more options at that point.

Re: Ruby is too slow for programming competitions

#253

Post by pak » Tue, Apr 23, 2013, 7:57 PM UTC

Scaevolus wrote: post #158

pak wrote: post #122

Earlier quoted context omitted.

> 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. Agreed. Contrary to what lbrandy said, I've tried it, and it works very well. Writing Ruby extensions in C, or wrapping C libraries for Ruby, is really easy. Wrapping a PNG library for Ruby allowed us to draw about a trillion pixels' worth of images based o…

That's a neat project! When generating huge numbers of png images, it's worth it to tweak the compression settings. Run png optimizers like optipng/pngcrush on your output, and use the settings it finds. LodePNG is easy to use, but doesn't let you tweak as many options as libpng. The tiles I've inspected are 15-30% larger than necessary-- besides using sub-optimal compression heuristics, they include unnecessary meta…

Yeah, I did consider optipng/pngcrush. In the end it was a tradeoff between running time and space. I could afford the space but not the time. When I added in pngcrush, because it brute forces a whole bunch of compression routines on each tile, running times went up dramatically and I preferred having the job complete in days as opposed to weeks. It might be something to consider if we generate more tiles on a faster cluster.

Re: Ruby is too slow for programming competitions

#254

Post by yxhuvud » Wed, May 01, 2013, 1:29 PM UTC

sspiff wrote: post #104

yxhuvud wrote: post #99

Earlier quoted context omitted.

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.

stdin? No, that shouldn't matter then, but it would if you were reading from file.