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

241–250 of 254 posts

Re: Ruby is too slow for programming competitions

#241

Post by papsosouid »

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.

Because in reality, people don't make decisions based on how many duplicate, unmaintained, broken libraries exist for language X. They make them based on "does language X have the libraries I actually need". Oh, json, DB_of_choice, and web framework exist? Gee, I guess 90%+ of people are covered right there. Virtually every language, even as seldom used as say, ocaml, have the libraries that 90% of people actually use. Libraries aren't an issue for the majority of tasks people are doing.

Re: Ruby is too slow for programming competitions

#242

Post by awj »

papsosouid wrote: post #240
awj wrote: post #140

Earlier quoted context omitted.

Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Also you're trading away a few language features to get Go, so between the two you're tossing a lot of programmer time out the door to avoid writing in C. Maybe that's still a worthwhile trade, but it's not really a simple one.

>Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Now replace go with ruby and ruby with perl. Go has libraries for 99% of what people are doing with ruby. If you are in that 1%, then you need to evaluate whether or not it is worth writing the library you need or if you should use another language.

A quick check led to me not finding a package manager for Go similar to RubyGems. Does it have one? Manually installing dependencies is a colossal waste of time.

Re: Ruby is too slow for programming competitions

#243

Post by pkolaczk »

up_and_up wrote: post #205
Derbasti wrote: post #84

Earlier quoted context omitted.

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

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.

Re: Ruby is too slow for programming competitions

#244

Post by stevepike »

codygman wrote: post #212
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…

Done a bit hastily, let me know if I got something wrong. But here's a racket (formerly plt scheme) solution: #lang racket (define (palindrome? lst) (equal? lst (foldl cons empty lst))) (define ITERATIONS 10000000) (for ([i (in-range ITERATIONS)]) (palindrome? '(i))) time racket palindrome.rkt real 0m0.893s user 0m0.864s sys 0m0.024s Here are some other solutions done in racket for those that are interested: http://w…

I don't think you can just pass '(i) to palindrome? here - doesn't the number need to be converted to a list of digits first? I got #t for everything using your code.

I took some code off SO and it bumped up the runtime substantially:

  #lang racket
  (require srfi/1 srfi/26)
  (define (digits->list num (base 10))
    (unfold-right zero? (cut remainder  base) (cut quotient  base) num))

  (define (palindrome? lst)
    (equal? lst (foldl cons empty lst)))

  (define ITERATIONS 10000000)
  (for ([i (in-range ITERATIONS)])
    (palindrome? (digits->list i)))

  racket palindrome.rkt  11.66s user 0.55s system 99% cpu 12.293 total
I'm a racket beginner so I'd be interested in better answers to this.

Re: Ruby is too slow for programming competitions

#245

Post by kyllo »

So you wrote a brute-force algorithm in a slow, interpreted implementation of a dynamic language, and you were surprised that your solution took a long time to run?

Using a faster language implementation could have allowed you to use the same brute-force algorithm and come in under the time limit, but your real problem is your algorithm, not your language implementation.

You can write fast code in a fast language and get very fast running time.

You can also write slow code in a fast language, or fast code in a slow language, and still have acceptably fast running time.

But you wrote slow code in a slow language, the worst of both worlds.

Re: Ruby is too slow for programming competitions

#246

Post by papsosouid »

awj wrote: post #242
papsosouid wrote: post #240

Earlier quoted context omitted.

>Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Now replace go with ruby and ruby with perl. Go has libraries for 99% of what people are doing with ruby. If you are in that 1%, then you need to evaluate whether or not it is worth writing the library you need or if you should use another language.

A quick check led to me not finding a package manager for Go similar to RubyGems. Does it have one? Manually installing dependencies is a colossal waste of time.

It is just go. Do a "go build foo" or "go install foo" and it will handle any dependencies for foo on its own. Do a "go get bar" and it will download and install bar and anything it depends on.

Re: Ruby is too slow for programming competitions

#247

Post by awj »

papsosouid wrote: post #246
awj wrote: post #242

Earlier quoted context omitted.

A quick check led to me not finding a package manager for Go similar to RubyGems. Does it have one? Manually installing dependencies is a colossal waste of time.

It is just go. Do a "go build foo" or "go install foo" and it will handle any dependencies for foo on its own. Do a "go get bar" and it will download and install bar and anything it depends on.

Where are these packages published? Can I install things from this page[1] in that way?

At least from 1000 feet away, it seems like Ruby has this problem solved better than Go does. Maybe it's just that the nature of the solution is more apparent.

[1] https://code.google.com/p/go-wiki/wiki/Projects

Re: Ruby is too slow for programming competitions

#248

Post by papsosouid »

awj wrote: post #247
papsosouid wrote: post #246

Earlier quoted context omitted.

It is just go. Do a "go build foo" or "go install foo" and it will handle any dependencies for foo on its own. Do a "go get bar" and it will download and install bar and anything it depends on.

Where are these packages published? Can I install things from this page[1] in that way? At least from 1000 feet away, it seems like Ruby has this problem solved better than Go does. Maybe it's just that the nature of the solution is more apparent. [1] https://code.google.com/p/go-wiki/wiki/Projects

>Where are these packages published?

Anywhere you want to publish them.

>Can I install things from this page[1] in that way?

Sure. Just do a "go install github.com/foo/bar". Bitbucket, github, google code, and launchpad are all in the defaults, but you can configure your import path to add whatever locations you like, and then "go list" will show packages available there, and the other go commands will be able to build/install/etc those. The same syntax is used for import statements, so your code can depend on any code any where:

     import "mycoolwebsite.com/~bob/myproject.git/foo"
>Maybe it's just that the nature of the solution is more apparent.

I think they make it pretty clear: http://golang.org/cmd/go/ gives you pretty much everything about packages and so does "go help". Go pretty much does everything out of the box with the included toolset, from installing dependencies to formatting code to refactoring.

Re: Ruby is too slow for programming competitions

#249

Post by hsitz »

Lonny_Eachus wrote: post #237
Lonny_Eachus wrote: post #171

Earlier quoted context omitted.

Correction: I benchmarked the I/O improvement I was thinking about. It actually only resulted in an improvement of about 30%. Worthwhile, probably, but not as "dramatic" as I thought it would be. Mea culpa.

hsitz: It was only an EXAMPLE. It might be irrelevant to this particular issue, but look at the context of my comment: it isn't irrelevant to the subject of learning to code more efficiently.

No problem. When I read your post I was confused whether you were suggesting that he could have gotten a 30% speed up in overall time by making i/o more efficient. Now I understand you weren't.

But I would still suggest that, within the context of programming competitions, a certain kind of "programming efficiency" is close to irrelevant. A sloppily coded solution that nevertheless implements the proper algorithm can be many orders of magnitude faster than an efficiently coded implementation of a slow algorithm. Programming contests are more about having the insight to implement an algorithm having low big O, not so much about efficient coding practices. This isn't to say that efficient coding practices aren't important generally, just that there are much more important things to focus on in programming competitions.

Re: Ruby is too slow for programming competitions

#250

Post by emn13 »

timr wrote: post #225
vidarh wrote: post #221

Earlier quoted context omitted.

I didn't find it hard at all, nor a pain in the ass. I wrote my code. Profiled it. Found the few, small bits that needed to be fast and treated the Ruby code as an executable spec for the C, and rewrote it very quickly. There is SWIG support for Ruby, as well as the Ruby FFI implementation and RubyInline, offering various degrees of simplicity, but none of them are hard. The Ruby extension interface is more work, but…

"I wrote my code. Profiled it. Found the few, small bits that needed to be fast and treated the Ruby code as an executable spec for the C, and rewrote it very quickly." The fact that the speed-critical parts of your problem could be reduced to a "few, small bits" indicates that we're talking about entirely different things. I was in a problem domain where writing the time-critical pieces in a different language meant…

Also, it's a weird wonderland in which you know exactly which parts need to be fast, reimplement those, and then never need to touch those bits again. In my experience, that's not the case - you're going to want to tune and alter your algorithm, and if it's API needs to go through several languages, it's going to be a pain. Every time you decide you need a slightly different input format or data store or set of hyperparameters, you'll likely be changing many more files than you would in a one-language solution, and in a way that's hard to unit-test and hard to statically type.

It's certainly doable, and definitely the right way to go if you want number crunching in a high-level language, but it's not a free lunch. It's certainly not a quick one-time conversion and then you can forget about it.

Post reply on HN