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

231–240 of 254 posts

Re: Ruby is too slow for programming competitions

#231

Post by ksec »

camus wrote: post #218
ksec wrote: post #206

I am risking myself getting insanely downvoted for writing this. But I hope it at least gets some of the attention. I really hope the Ruby Communities do actually admit Ruby is Slow. Because until you actually admit there is a problem, there will never be any notion of wanting to fix it. Most of the time, they will come up with Rails Examples or serving dynamic web pages, and the bottleneck being in Database. And the…

PHP and PYTHON are slow too. Like them Ruby can take advantage ) of C extensions. You cant write everything in ruby like PHP developpers use native drivers for database communication , compression , image manipulation ,etc ... that's normal. Scripted languages should be used for what they are for , a thin layer on the top of other more performant languages. Like Twitter , Ruby/Rails allowed them to bootstrap their id…

The problem was PHP and Python are slow too, and yet they are still faster then Ruby. And not to mention there are many other implementation of the two that gets them further along. So if Ruby was 1x, and PHP / Python are 1.5x, there are things that can get the last two to 3 - 4x. While Ruby is still just there, 1x. ( Numbers are for explanation only ). I really wish more resources were pour into Rubinius.

Re: Ruby is too slow for programming competitions

#232

Post by masklinn »

thomasz wrote: post #229
msy wrote: post #224

Earlier quoted context omitted.

I think the project you're looking for is Topaz, which has a close ecosystem relationship with PyPy: http://docs.topazruby.com/en/latest/blog/announcing-topaz/

It was announced two months ago. Would you trust it enough to use it in production in the next two to five years?

> It was announced two months ago.

But was started more than a year ago (the first commit was made in April 2012)

> Would you trust it enough to use it in production in the next two to five years?

Why not?

Re: Ruby is too slow for programming competitions

#233

Post by digger250 »

ClifReeder wrote: post #21
VeejayRampay wrote: post #2

Maybe the result would vary with JRuby or Rubinius (I'd be interested in benchmarks) because not only is Ruby itself not the fastest language, but its main implementation (MRI) is also not the best for speed.

This is a good point that I didn't consider. Running the 'just iterate over the range version' of this code with jruby: [master] clifff@fair_and_square: ruby -v jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_43-b01-447-11M4203 [darwin-x86_64] [master] clifff@fair_and_square: time ruby fair_and_square.rb C-large-1.in.bak real 6m39.105s user 6m37.762s sys 0m19.009s

When I run the benchmark in C-ruby (2.0.0) I get:

  real	2m35.450s
  user	2m35.257s
  sys	0m0.139s
On jruby with invokedynamic:

  time ruby -Xcompile.invokedynamic=true file2.rb C-large-1.in

  real	1m17.711s
  user	1m15.618s
  sys	0m0.830s
In jruby without invokedynamic time ruby file2.rb C-large-1.in

  real	1m37.856s
  user	1m39.260s
  sys	0m0.854s

Re: Ruby is too slow for programming competitions

#234

Post by rockasaur »

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

Re: Ruby is too slow for programming competitions

#235

Post by jdminhbg »

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

If you want a GIL-less Ruby, check out Rubinius: http://rubini.us/2013/03/19/pdx-summit-recap/

Re: Ruby is too slow for programming competitions

#236

Post by hsitz »

Lonny_Eachus wrote: post #171
Lonny_Eachus wrote: post #133

Earlier quoted context omitted.

Just a suggestion, but I would also give some thought to efficient coding style, not just algorithms. For example, you could have speeded up your I/O dramatically.

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.

I think that 30% improvement you're referring to must be for just the i/o itself. Given that the i/o for the problem amounts to less than 1/1000th of the processing time, a 30% improvement is basically irrelevant. It doesn't help much to speed up something that's not even close to being a bottleneck. I think many of the best algorithm contest coders just use whatever i/o method uses the least code, keeps their answers simple and clean.

Re: Ruby is too slow for programming competitions

#237

Post by Lonny_Eachus »

Lonny_Eachus wrote: post #171
Lonny_Eachus wrote: post #133

Earlier quoted context omitted.

Just a suggestion, but I would also give some thought to efficient coding style, not just algorithms. For example, you could have speeded up your I/O dramatically.

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.

Re: Ruby is too slow for programming competitions

#238

Post by chadcf »

bhauer wrote: post #184
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

Topaz is also a really early experiment that supports a pretty small subset of ruby. I really hope it gets developed into a real, useful ruby vm but at the moment it is not even worth considering.

Re: Ruby is too slow for programming competitions

#239

Post by papsosouid »

Derbasti wrote: post #84
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.

>Why

Because it is a huge pain in the ass, and very rarely does any good. As soon as you are writing C, you are dealing with all the headaches that go with it for both development and deployment. You've lost a big part of the benefit of using scripting language X. And this part:

>In many cases, only a tiny fraction of your code needs to be fast

Isn't true. People repeat it a lot, but I've seen no evidence to support it. Most people are using scripting languages for web apps which really are just generally slow all over. They would need to write 80% of it in C to get good performance. Seems like using a language that is as productive as scripting languages, but is also fast, makes a lot more sense.

Re: Ruby is too slow for programming competitions

#240

Post by papsosouid »

awj wrote: post #140
frehpt wrote: post #128

Earlier quoted context omitted.

Option A: -Write your application in Go Option B: -Write application in Ruby -Profile Ruby application to identify code to be rewritten in C -Learn C if you don't already know it -Rewrite various parts of your application in C -Run Valgrind to search for memleaks -Ensure that your target systems all have required libs installed Option A seems much simpler...

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.

Post reply on HN