Ruby is too slow for programming competitions • Hacker News Board

Re: Ruby is too slow for programming competitions

#181

Post by yen223 » Sun, Apr 21, 2013, 10:36 PM UTC

macobo wrote: post #11

In this context, no it's not. One thing that Code Jam does differently (and imho better) is that they give you an input set and you have 8 minutes (or so) to upload the solution. This is expected to give more than enough space for language speed variance. Instead of execution time, coding time is much more precious in such competitions, and Micro-optimizing has it's place, but it's usually not in a programming compet…

"Instead of execution time, coding time is much more precious in such competitions"

Unfortunately, in such competitions you'll be competing against people who write C++ algos faster than normal people writing Python.

Re: Ruby is too slow for programming competitions

#182

Post by KVFinn » Sun, Apr 21, 2013, 10:38 PM UTC

ClifReeder wrote: post #32

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.

Others have asserted that they aren't doing the same processing and the GO program is not correct.

https://news.ycombinator.com/item?id=5586152

Re: Ruby is too slow for programming competitions

#183

Post by bvdbijl » Sun, Apr 21, 2013, 10:45 PM UTC

JeanPierre wrote: post #134

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

I partially disagree, partially agree. In these competitions, it's about implementing a solution as fast as possible, while still get it working under the time limit (5/8 minutes). It's mostly about having the right idea and implement it. In very many cases, you would like to be able to manipulate and play with algorithms and have efficient mutable data structures. For this, Java/C++ (Essentially C with data structur…

Different ways for different people, I'm just talking about my own experience

Re: Ruby is too slow for programming competitions

#184

Post by bhauer » Sun, Apr 21, 2013, 10:48 PM UTC

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…

Not to thread-crash, but in case you missed it, we posted the results of Round 3 of our web frameworks and platforms benchmarking last week [1]. Seems relevant given your comment about hosting costs.

This round includes many more community contributions including more Scala, Erlang, Haskell, Python, Java, PHP, etc. And Go 1.1.

[1] http://www.techempower.com/benchmarks/#section=data-r3

Re: Ruby is too slow for programming competitions

#185

Post by cheald » Sun, Apr 21, 2013, 10:59 PM UTC

mitchi wrote: post #173

tonycoco wrote: post #167

This whole, "Ruby is slow," diatribe is just ridic. Everyone here that has done any C/C++ or Ruby development would probably agree that if you're looking for number smashing, Ruby is just not cutting it unless you're into rockin' C extensions and getting what you want... for now. Ruby, within a few years, will probably have some VM action, whether the JVM with JRuby or Rubinius wins out, who cares. In any case, in li…

Tim Sweeney predicted that we'd all have 20 core machines with 80 hardware threads by 2009. Not really what happened. The whole point is that while Ruby is nice, it's just too slow. Someone is better off investing time learning a faster compiled/JIT language.

Too slow for what? Certainly not all classes of problems. Heavy mathematical work (every number in Ruby is an object! That's going to be much, much slower than a C primitive!), sure, but there are lots of folks using it quite happily to solve a wide range of problems.

Re: Ruby is too slow for programming competitions

#186

Post by jeltz » Sun, Apr 21, 2013, 11:08 PM UTC

lbrandy wrote: post #161

jonhohle wrote: post #146

Earlier quoted context omitted.

I agree with it and have implemented it. After profiling a backfill script which was looking like it was going to take about two weeks to run, I found an area where certain bit-twiddling was being done which was extremely slow in Ruby. I rewrote this section in C, and was able to make this section 1000x faster then the ruby equivalent (this was MRI 1.8.5 several years ago). The total runtime for the script was brough…

I didn't mean to imply it wasn't ever possible. Just that the subset of things that it works great for is smaller than people wish, or believed. That "I'll write in Ruby and optimize in C when I need to" is a myth on the order of the "sufficiently smart compiler". There are things for which it just plain doesn't work. Things that are quite common. Yes, you can make image transformations for your webapp fast by piping…

In a way you actually do fix the garbage collection problems by dropping down to C. One of the main performance hit in tight loops in Ruby is usually object allocation and GC. If you drop down to C you can handle the memory manually and avoid most of the allocations.

Re: Ruby is too slow for programming competitions

#187

Post by hellb88ned » Sun, Apr 21, 2013, 11:09 PM UTC

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…

> when he really should have blamed the Dunning-Kruger effect.

Going a layer deeper, blame the competitions themselves. They very rarely have good data sets to actually weed out algorithmically poor solutions, so you can often get away with brute force or mostly brute force solutions -- if you use a low-level programming language.

For instance many times a O(N^2/100) will pass the test data just because it's written in C++ instead of something slower. That's a failure of the test data.

Re: Ruby is too slow for programming competitions

#188

Post by JulianMorrison » Sun, Apr 21, 2013, 11:12 PM UTC

threeseed wrote: post #166

kgabis wrote: post #152

Earlier quoted context omitted.

Why not 1/10e100? Or even less? Go's library support is quite nice already and it's growing really fast.

Because I am being realistic. Ruby, C, Java etc have had decades to build a comprehensive set of developer libraries. Go hasn't. It's a "cute" platform that I am sure will beat Ruby in a few benchmarks. But I don't see any reason why anyone would seriously consider it for a real world app.

Ruby has a sprawling ecosystem of libraries largely drawn into being by Rails (itself a sprawl) and by design decisions in Ruby's core and stdlib that complicate things and need further code to work around. Threads and fibers and events, oh my. Each workaround has its own ecosystem. You could even consider things like rack and unicorn workarounds for the weak implementations in stdlib.

I don't think Ruby's libraries honestly provide a whole lot better coverage than Go. The stdlib is very well considered. It's fast, it scales, it's thread safe in the appropriate places. It's not a toy implementation. What it doesn't provide, it provides hooks for. Third party libs cover all the major bases. And unlike Ruby, writing interfacing code in Go is a snip. I don't see libraries as a downside.

(With one exception. Why oh why did they not include a bigdecimal? Argh, a ratio type is not an adequate replacement. Try rounding a ratio some time. Blarg.)

Re: Ruby is too slow for programming competitions

#189

Post by ClifReeder » Sun, Apr 21, 2013, 11:17 PM UTC

gnuvince wrote: post #82

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.

Welp, I had no idea about the int64 business. Probing on this, but it does seem like it changes things quiet a bit.

UPDATE: After updating go from 1.0.2 to 1.1, this matches my results - it now takes about 2 minutes, 47 seconds to run through the input (and Code Jam confirms the output is correct). This seems like a significant detail to me, so I'll update the post.

Re: Ruby is too slow for programming competitions

#190

Post by btilly » Sun, Apr 21, 2013, 11:20 PM UTC

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 you're familiar with knives why not bring a knife to a gun fight?

As long as you start under 21 feet away, the knife is surprisingly effective. See http://www.policeone.com/edged-weapons/articles/102828-Edged... for more.

It is a question of knowing your tool, and knowing how to stay within its limitations.