Related
So, I have a few questions that I have to ask, I did browse the internet, but there weren't too many reliable answers. Mostly blog posts that would cancel each-other out because they both praised different things and had benchmarks to "prove their viewpoint" (I have never seen so many contradicting benchmarks in my life).
Anyway, my questions are:
Is Rubinius really faster? I was pretty impressed by this apparently honest pro-Rubinius presentation. Another thing that confuses me a little is that a lot of Rubinius is written in Ruby itself, yet somehow it is faster than C-Ruby? It must be a pretty damn good implementation of the language, then!
Does EventMachine work with Ruinius? As far as I know, EventMachine partially relies on Fibers (correct me if I'm wrong) which weren't implemented until 1.9. I know Rubinius will eventually support 1.9, too; I don't mind waiting a little.
Do C extensions work in Rubinius? I have written a C extension which "serializes" binary messages received from a TCP stream into Ruby Objects and vice-versa (I suppose the details are not important, but if it helps answer this question I will update the post). This can be a lot of messages! I managed to write the same code in Ruby (although, it made little sense after a month), but it proved to be a real bottle-neck in the application. So, I had to use C as a "solution" to my problem.
EDIT: I just remembered, I use C for another task, it is a hit-test method for Arrays. Basically it just checks if a "point" is inside an a polygon, it was impossibly slow in CRuby.
If the previous answer was a "No," is there then an alternative for C extensions in Rubinus? I gather the VM is written in C++, so that then.
A few "bonus" questions:
Will C-Ruby (2.0+, YARV) ever get rid of GIL? Or at least modify it so CRuby supports true parallelism?
What is exactly mruby? I see matz is working on it, and as far as the description goes it seems pretty awesome. How different is it from CRuby (performance-wise)?
I apologize for this text-storm I unleashed upon you! ♥
Is Rubinius really faster?
In most benchmarks, yes.
But benchmarks are... dumb. Apps are what we really care about. So the best thing to do is benchmark your app & see how well it performs. The 2 areas where Rubinius will real shine over MRI are parallelism & memory usage. Rubinius has no GIL, so you can utilize all available threads. It also has a much more sophisticated GC, so in general it could perform better with respect to GC.
I did those benchmarks back in Oct '11 for my talk on MagLev at RubyConf
Does EventMachine work with Rubinius?
Yes, and if there are parts that don't work, then the issue should be reported. With that said, currently the EM tests don't pass on any Ruby implementation.
Do C extensions work in Rubinius?
Yes. I maintain the compatibility issue for C-exts, so if there is one you have that is tested on Travis, Rubinius would like to see it pass against rbx. Rubinius has historically had good support for the C-api and C-exts, though it would be nice if someday Rubinius could run Ruby so fast one would not need C-exts or the C-api.
Will C-Ruby (2.0+, YARV) ever get rid of GIL? Or at least modify it so CRuby supports true parallelism?
No, most likely not. Jesse Storimer has a succinct writeup of Matz's opinion (or lack thereof) on threads from RubyConf 2012. Koichi Sasada tried to remove the GIL once and MRI perf just tanked. Evan Phoenix also tried once, before he created Rubinius, but didn't have good results.
What is exactly mruby?
An embeddable Ruby interpreter, akin to Lua. Matt Aimonetti has a few articles that might shed some light for you.
I am not too much into Ruby but I might be able to answer the first question.
Is Rubinius really faster?
I've seen different Benchmarks telling different things. However, the fact that Rubinius is partially written in Ruby does not have to mean that it is slower. I thought the same about PyPy which is Python in Python. After some research and the right classes in college I knew why.
As far as I know both are written in a subset of their language which should be much simpler. An (e.g. C) interpreter can be be optimized much easier for such a subset than the whole language.
Writing the Ruby/Python interpreter in its own language allows much more flexibility and quicker prototyping of new interpretation algorithms. The whole point of the existence of Ruby and Python are among others that algorithms can be implemented much quicker than in e.g. C or even assembler. A faster algorithm outweighs the little overhead of an interpreter a lot of the time.
Btw. writing an interpreter for a language in the same language is also a common academic practice to show how mighty the language is. In one class we've written Lisp in Lisp in Lisp.
I have all kind of scripting with Ruby:
rails (symfony)
ruby (php, bash)
rb-appscript (applescript)
Is it possible to replace low level languages with Ruby too?
I write in Ruby and it converts it to java, c++ or c.
Cause People say that when it comes to more performance critical tasks in Ruby, you could extend it with C. But the word extend means that you write C files that you just call in your Ruby code. I wonder, could I instead use Ruby and convert it to C source code which will be compiled to machine code. Then I could "extend" it with C but in Ruby code.
That is what this post is about. Write everything in Ruby but get the performance of C (or Java).
The second advantage is that you don't have to learn other languages.
Just like HipHop for PHP.
Are there implementations for this?
Such a compiler would be an enormous piece of work. Even if it works, it still has to
include the ruby runtime
include the standard library (which wasn't built for performance but for usability)
allow for metaprogramming
do dynamic dispatch
etc.
All of these inflict tremendous runtime penalties, because a C compiler can neither understand nor optimize such abstractions. Ruby and other dynamic languages are not only slower because they are interpreted (or compiled to bytecode which is then interpreted), but also because they are dynamic.
Example
In C++, a method call can be inlined in most cases, because the compiler knows the exact type of this. If a subtype is passed, the method still can't change unless it is virtual, in which case a still very efficient lookup table is used.
In Ruby, classes and methods can change in any way at any time, thus a (relatively expensive) lookup is required every time.
Languages like Ruby, Python or Perl have many features that simply are expensive, and most if not all relevant programs rely heavily on these features (of course, they are extremely useful!), so they cannot be removed or inlined.
Simply put: Dynamic languages are very hard to optimize, simply doing what an interpreter would do and compiling that to machine code doesn't cut it. It's possible to get incredible speed out of dynamic languages, as V8 proves, but you have to throw huge piles of money and offices full of clever programmers at it.
There is https://github.com/seattlerb/ruby_to_c Ruby To C compiler. It actually only takes in a subset of Ruby though. I believe the main missing part is the Meta Programming features
In a recent interview (November 16th, 2012) Yukihiro "Matz" Matsumoto (creator of Ruby) talked about compiling Ruby to C
(...) In University of Tokyo a research student is working on an academic research project that compiles Ruby code to C code before compiling the binary code. The process involves techniques such as type inference, and in optimal scenarios the speed could reach up to 90% of typical hand-written C code. So far there is only a paper published, no open source code yet, but I’m hoping next year everything will be revealed... (from interview)
Just one student is not much, but it might be an interesting project. Probably a long way to go to full support of Ruby.
"Low level" is highly subjective. Many people draw the line differently, so for the sake of this argument, I'm just going to assume you mean compiling Ruby down to an intermediate form which can then be turned into machine code for your particular platform. I.e., compiling ruby to C or LLVM IR, or something of that nature.
The short answer is yes this is possible.
The longer answer goes something like this:
Several languages (Objective-C most notably) exist as a thin layer over other languages. ObjC syntax is really just a loose wrapper around the objc_*() libobjc runtime calls, for all practical purposes.
Knowing this, then what does the compiler do? Well, it basically works as any C compiler would, but also takes the objc-specific stuff, and generates the appropriate C function calls to interact with the objc runtime.
A ruby compiler could be implemented in similar terms.
It should also be noted however, that just by converting one language to a lower level form does not mean that language is instantly going to perform better, though it does not mean it will perform worse either. You really have to ask yourself why you're wanting to do it, and if that is a good reason.
There is also JRuby, if you still consider Java a low level language. Actually, the language itself has little to do here: it is possible to compile to JVM bytecode, which is independent of the language.
Performance doesn't come solely from "low level" compiled languages. Cross-compiling your Ruby program to convoluted, automatically generated C code isn't going to help either. This will likely just confuse things, include long compile times, etc. And there are much better ways.
But you first say "low level languages" and then mention Java. Java is not a low-level language. It's just one step below Ruby in terms of high- or low-level languages. But if you look at how Java works, the JVM, bytecode and just-in-time compilation, you can see how high level languages can be fast(er). Ruby is currently doing something similar. MRI 1.8 was an interpreted language, and had some performance problems. 1.9 is much faster, it's using a bytecode interpreter. I'm not sure if it'll ever happen on MRI, but Ruby is just one step away from JIT on MRI.
I'm not sure about the technologies behind jRuby and IronRuby, but they may already be doing this. However, both have their own advantages and disadvantages. I tend to stick with MRI, it's fast enough and it works just fine.
It is probably feasible to design a compiler that converts Ruby source code to C++. Ruby programs can be compiled to Python using the unholy compiler, so they could be compiled from Python to C++ using the Nuitka compiler.
The unholy compiler was developed more than a decade ago, but it might still work with current versions of Python.
Ruby2Cextension is another compiler that translates a subset of Ruby to C++, though it hasn't been updated since 2008.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I like Ruby on Rails and I use it for all my web development projects. A few years ago there was a lot of talk about Rails being a memory hog and about how it didn't scale very well but these suggestions were put to bed by Gregg Pollack here.
Lately though, I've been hearing people saying that Ruby itself is slow.
Why is Ruby considered slow?
I do not find Ruby to be slow but then again, I'm just using it to make simple CRUD apps and company blogs. What sort of projects would I need to be doing before I find Ruby becoming slow? Or is this slowness just something that affects all programming languages?
What are your options as a Ruby programmer if you want to deal with this "slowness"?
Which version of Ruby would best suit an application like Stack Overflow where speed is critical and traffic is intense?
The questions are subjective, and I realise that architectural setup (EC2 vs standalone servers etc) makes a big difference but I'd like to hear what people think about Ruby being slow.
Finally, I can't find much news on Ruby 2.0 - I take it we're a good few years away from that then?
Why is Ruby considered slow?
Because if you run typical benchmarks between Ruby and other languages, Ruby loses.
I do not find Ruby to be slow but then
again, I'm just using it to make
simple CRUD apps and company blogs.
What sort of projects would I need to
be doing before I find Ruby becoming
slow? Or is this slowness just
something that affects all programming
languages?
Ruby probably wouldn't serve you well in writing a real-time digital signal processing application, or any kind of real-time control system. Ruby (with today's VMs) would probably choke on a resource-constrained computer such as smartphones.
Remember that a lot of the processing on your web applications is actually done by software developed in C. e.g. Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, many parsing libraries, RMagick, TCP/IP, etc are C programs used by Ruby. Ruby provides the glue and the business logic.
What are your options as a Ruby
programmer if you want to deal with
this "slowness"?
Switch to a faster language. But that carries a cost. It is a cost that may be worth it. But for most web applications, language choice is not a relevant factor because there is just not enough traffic justify using a faster language that costs much more to develop for.
Which version of Ruby would best suit
an application like Stack Overflow
where speed is critical and traffic is
intense?
Other folks have answered this - JRuby, IronRuby, REE will make the Ruby part of your application run faster on platforms that can afford the VMs. And since it is often not Ruby that causes slowness, but your computer system architecture and application architecture, you can do stuff like database replication, multiple application servers, loadbalancing with reverse proxies, HTTP caching, memcache, Ajax, client-side caching, etc. None of this stuff is Ruby.
Finally, I can't find much news on
Ruby 2.0 - I take it we're a good few
years away from that then?
Most folks are waiting for Ruby 1.9.1. I myself am waiting for Rails 3.1 on Ruby 1.9.1 on JRuby.
Finally, please remember that a lot of developers choose Ruby because it makes programming a more joyful experience compared to other languages, and because Ruby with Rails enables skilled web developers to develop applications very quickly.
First of all, slower with respect to what? C? Python? Let's get some numbers at the Computer Language Benchmarks Game:
Ruby 1.9 vs. Python3 within the same order of magnitude
Ruby 1.9 vs. PHP within the same order of magnitude
Ruby 1.9 vs. Java 6 server up to two orders of magnitude slower!
Ruby 1.9 vs. C (gcc) up to two orders of magnitude slower!
...
Why is Ruby considered slow?
Depends on whom you ask. You could be told that:
Ruby is an interpreted language and interpreted languages will tend to be slower than compiled ones
Ruby uses garbage collection (though C#, which also uses garbage collection, comes out two orders of magnitude ahead of Ruby, Python, PHP etc. in the more algorithmic, less memory-allocation-intensive benchmarks above)
Ruby method calls are slow (although, because of duck typing, they are arguably faster than in strongly typed interpreted languages)
Ruby (with the exception of JRuby) does not support true multithreading
etc.
But, then again, slow with respect to what? Ruby 1.9 is about as fast as Python and PHP (within a 3x performance factor) when compared to C (which can be up to 300x faster), so the above (with the exception of threading considerations, should your application heavily depend on this aspect) are largely academic.
What are your options as a Ruby programmer if you want to deal with this "slowness"?
Write for scalability and throw more hardware at it (e.g. memory)
Which version of Ruby would best suit an application like Stack Overflow where speed is critical and traffic is intense?
Well, REE (combined with Passenger) would be a very good candidate.
Here's what the creator of Rails, David Heinemeier Hansson has to say:
Rails [Ruby] is for the vast majority
of web applications Fast Enough. We
got sites doing millions of dynamic
page views per day. If you end up
being with the Yahoo or Amazon front
page, it's unlikely that an
off-the-shelve framework in ANY
language will do you much good. You'll
probably have to roll your own. But
sure, I'd like free CPU cycles too. I
just happen to care much more about
free developer cycles and am willing
to trade the former for the latter.
i.e. throwing more hardware or machines at the problem is cheaper than hiring more developers and using a faster, but harder to maintain language. After all, few people write web applications in C.
Ruby 1.9 is a vast improvement over 1.8. The biggest problems with Ruby 1.8 are its interpreted nature (no bytecode, no compilation) and that method calls, one of the most common operations in Ruby, are particularly slow.
It doesn't help that pretty much everything is a method lookup in Ruby - adding two numbers, indexing an array. Where other languages expose hacks (Python's __add__ method, Perl's overload.pm) Ruby does pure OO in all cases, and this can hurt performance if the compiler/interpreter is not clever enough.
If I were writing a popular web application in Ruby, my focus would be on caching. Caching a page reduces the processing time for that page to zero, whatever language you are using. For web applications, database overhead and other I/O begins to matter a lot more than the speed of the language, so I would focus on optimising that.
Writing code is slow. Reading code is slow. Finding and fixing bugs is slow. Adding features and enhancements is slow. Anything that improves on the previous is a win. Very rarely is execution performance an issue.
The answer is simple: people say ruby is slow because it is slow based on measured comparisons to other languages. Bear in mind, though, "slow" is relative. Often, ruby and other "slow" languages are plenty fast enough.
Joel on Software - Ruby Performance Revisited
quite well explains it. Might be outdated though...
I would recommend to just stick with it as you're used to Ruby on Rails,
if you ever meet a performance issue you might reconsider to use a different language and framework.
In that case I would really suggest C# with ASP.NET MVC 2, works very well for CRUD apps.
I would say Ruby is slow because not much effort has been spent in making the interpreter faster. Same applies to Python. Smalltalk is just as dynamic as Ruby or Python but performs better by a magnitude, see http://benchmarksgame.alioth.debian.org. Since Smalltalk was more or less replaced by Java and C# (that is at least 10 years ago) no more performance optimization work had been done for it and Smalltalk is still ways faster than Ruby and Python. The people at Xerox Parc and at OTI/IBM had the money to pay the people that work on making Smalltalk faster. What I don't understand is why Google doesn't spend the money for making Python faster as they are a big Python shop. Instead they spend money on development of languages like Go...
Ruby is slower than C++ at a number of easily measurable tasks (e.g., doing code that is heavily dependent on floating point). This is not very surprising, but enough justification for some people to say that “Ruby is Slow” without qualification. They don't count the fact that it is far easier and safer to write Ruby code than C++.
The best fix is to use targeted modules written in another language (e.g., C, C++, Fortran) in your Ruby code. Those can do the heavy lifting and your scripts can focus on higher level coordination issues.
First of all, do you care about what others say about the language you like? When it does the job it has to do, you're fine.
OO isn't the fastest way to execute code, but it does help in creating the code. Smart code is always faster than dumb code and useless loops. I'm an DBA and see a lot of these useless loops, drop them, use better code and queries and application is faster, much faster. Do you care about the last microsecond? You might have languages optimized for speed, others just do the job they have to do and can be maintained by many different programmers.
It's all just a choice.
Obviously, talking about speed Ruby loses. Even though benchmark tests suggest that Ruby is not so much slower than PHP. But in return, you are getting easy-to-maintain DRY code, the best out of all frameworks in various languages.
For a small project, you wont feel any slowness (I mean until like <50K users) given that no complex calculations are used in the code, just the mainstream stuff.
For a bigger project, paying for resources pays off and is cheaper than developer wages. In addition, writing code on RoR turns out to be much faster than any other.
In 2014 this magnitude of speed difference you're talking about is for most websites insignificant.
The way to deal with Ruby's performance in Web application is the same as with any other programming language:
ARCHITECTURE
This is easier to do in Rails than in most other Web Frameworks.
At the application level, by caching whatever is supposed to be cached and by managing the access to the DB in an intelligent way (since the bottleneck is usually on the "DB" access for most WEB apps).
Rails makes it very easy and natural to solve these problems. There are several abstractions for caching data, pages and fragments, and there are also very nice abstractions to deal with the SQL part in an optimised and reusable fashion (Active Record and AREL).
This is the reason why so many applications written in faster and not-so-expressive languages (like php) end up being slower than the Ruby counterparts. It's not so easy and elegant to tackle caching and querying with these languages than it is with Ruby.
At the infrastructure level it is reasonable to think of load balancing and all that stuff that I do not happen to know a lot about. I'd outsource that problem by hiring some platform as service provider, like Heroku or Engine Yard. Anyway. Deploying rails with load balancing is probably not very hard to do.
People say that Ruby is slow because they compare Ruby programs to programs written in other languages. Maybe the programs you write don't need to be faster. Maybe for the programs you write Ruby isn't the bottleneck that's slowing things down.
Ruby 2.1 compared to Javascript V8
Ruby 2.1 compared to ordinary Lua
Ruby 2.1 compared to Python 3
Performance is almost always about good design and optimized database interactions. Ruby does what most web sites need quite fast, especially more recent versions; and the speed of development and ease of maintenance provides a large payoff in costs and in keeping customers happy. I find JAVA to have slow execution performance for some tasks, and given the difficulty of developing in JAVA, many developers create slow applications regardless of the theoretical speed capability as demonstrated in benchmarks (benchmarks are generally contrived to show a specific and narrow capability). When I need intensive processing that isn't well suited to my database's capabilities, I choose C or Objective-C or some other truly high performance compiled language for those tasks depending on the platform. If I need to create a databased web application, I use RoR or sometimes C# ASP.NET depending on other requirements; because all platforms have strengths and weaknesses. Execution speed of the things your application does is important, but after all, if execution performance of one narrow aspect of a language is all that counts; then I might still be using Assembler language for everything.
Ruby performs well for developer productivity. Ruby by nature forces test driven development because of the lack of types. Ruby performs well when used as a high level wrapper for C libraries. Ruby also performs well during long running processes when it is JIT-compiled to machine code via JVM or Rbx VM. Ruby does not perform well when it is required to crunch numbers in a short time with pure ruby code.
Here is the only way I know to ask it at the moment. As Understand it Scala uses the Java Virtual Machine. I thought Jruby did also. Twitter switched its middleware to Scala. Could they have done the same thing and used Jruby?
Could they have started with Jruby to start with and not had their scaling problems that caused them to move from Ruby to Scala in the first place? Do I not understand what Jruby is? I'm assuming that because Jruby can use Java it would have scaled where Ruby would not.
Does it all boil down to the static versus dynamic types, in this case?
Scala is "scalable" in the sense that the language can be improved upon by libraries in a way that makes the extensions look like they are part of the language. That's why actors looks like part of the language, or why BigInt looks like part of the language.
This also applies to most other JVM languages. It does not apply to Java, because it has special treatment for it's basic types (Int, Boolean, etc), for operators, cumbersome syntax that makes clear what is built in the language and what is library, etc.
Now, Scala is more performatic than dynamic languages on the JVM because the JVM has no support for them. Dynamic languages on JVM have to resort t reflection, which is very slow.
No, not really. It's not that the JVM is somehow magic and makes things scale by its magic powers; it's that Scala, as a language, is architected to help people write scalable systems. That it's on top of the JVM is almost incidental.
I don't really think that the language is the biggest problem here. Twitter grew insanely fast, which always leads to a code mess. And if you do a rewrite, it is a good idea to go for a different language - that bars you from building your own mistakes again and/or to "reuse some parts". Also, Ruby is not really meant for that kind of heavy data handling that the twitter backend does.
The frontend remains Ruby, so they still use it.
You have to separate out different meanings of scaling:
Scaling in terms of growing the number of requests per second that can be handled with a proportionate increase in hardware
Scaling in terms of growing a code base without it becoming a tangled mess
Scala helps on the first point because it compiles to Java bytecode that's really similar to Java, and therefore usually has the same performance as Java. I say "usually," because Scala there are some cases where idiomatic Scala causes large amount of boxing to take place where idiomatic Java would not (this is slated to change in Scala 2.8).
Performance is of course different than scaling. Equivalent code written in JRuby would scale just as well, but the slope of the line would be steeper - you'd need more hardware to handle the same number of requests, but the shape of the line would be the same. But from a more practical perspective the performance helps because you rarely can scale in a perfectly linear fashion with respect to adding core or especially servers and having better performance slows the rate at which you have to add capacity.
Scala helps with the second point because it has an expressive, compile-time enforced type system and it provides a lot of other means for managing the complexity of your code, such as mixins. You can write spaghetti code in any language, but the Scala compiler will tell you when some of the noodles are broken while with JRuby you'll have to rely solely on tests. I've personally found that for me Python breaks down at about 1000 closely related LOCs, and which point I have to refactor to either substantially reduce of the LOCs or make the structure more modular. Of course this refactoring would be a good idea regardless of what your language, but occasionally the complexity is inherent. Dealing with a large number of tightly couple LOCs isn't easy in any language, but it is much easier in Scala than it is in Python, and I think the analogy extends to Ruby/JRuby as well.
Scala is a statically typed language. JRuby is dynamically typed. That is why Scala is faster than JRuby, even though both run on the JVM. JRuby has to do a lot of work at runtime (method resolution, etc.) that Scala does at compile-time. For what it's worth, though, JRuby is a very fast Ruby implementation.
Scalability is not an inherit language capability. You are talking about speed.
A better question to ask would be "Why is Scala faster than other JVM languages (or is it)?". As others have pointed out, it's a static vs. dynamic language thing.
There's an interesting discussion from the Twitter developers themselves in the comments of this post.
They've evaluated the different options and decided to implement the back-end in Scala because: it ran faster than the Ruby/JRuby alternatives and they felt they could benefit from static typing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Ruby is slow at certain things. But what parts of it are the most problematic?
How much does the garbage collector affect performance? I know I've had times when running the garbage collector alone took several seconds, especially when working with OpenGL libraries.
I've used matrix math libraries with Ruby that were particularly slow. Is there an issue with how ruby implements basic math?
Are there any dynamic features in Ruby that simply cannot be implemented efficiently? If so, how do other languages like Lua and Python solve these problems?
Has there been recent work that has significantly improved performance?
Ruby is slow. But what parts of it are the most problematic?
It does "late lookup" for methods, to allow for flexibility. This slows it down quite a bit. It also has to remember variable names per context to allow for eval, so its frames and method calls are slower. Also it lacks a good JIT compiler currently, though MRI 1.9 has a bytecode compiler (which is better), and jruby compiles it down to java bytecode, which then (can) compile via the HotSpot JVM's JIT compiler, but it ends up being about the same speed as 1.9.
How much does the garbage collector effect performance? I know I've had times when running the garbage collector alone took several seconds, especially when working with OpenGL libraries.
from some of the graphs at http://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/ I'd say it takes about 10% which is quite a bit--you can decrease that hit by increasing the malloc_limit in gc.c and recompiling.
I've used matrix math libraries with Ruby that were particularly slow. Is there an issue with how ruby implements basic math?
Ruby 1.8 "didn't" implement basic math it implemented Numeric classes and you'd call things like Fixnum#+ Fixnum#/ once per call--which was slow. Ruby 1.9 cheats a bit by inlining some of the basic math ops.
Are there any dynamic features in Ruby that simply cannot be implemented efficiently? If so, how do other languages like Lua and Python solve these problems?
Things like eval are hard to implement efficiently, though much work can be done, I'm sure. The kicker for Ruby is that it has to accomodate for somebody in another thread changing the definition of a class spontaneously, so it has to be very conservative.
Has there been recent work that has significantly improved performance?
1.9 is like a 2x speedup. It's also more space efficient. JRuby is constantly trying to improve speed-wise [and probably spends less time in the GC than KRI]. Besides that I'm not aware of much except little hobby things I've been working on. Note also that 1.9's strings are at times slower because of encoding friendliness.
Ruby is very good for delivering solutions quickly. Less so for delivering quick solutions. It depends what kind of problem you're trying to solve. I'm reminded of the discussions on the old CompuServe MSBASIC forum in the early 90s: when asked which was faster for Windows development, VB or C, the usual answer was "VB, by about 6 months".
In its MRI 1.8 form, Ruby is - relatively - slow to perform some types of computationally-intensive tasks. Pretty much any interpreted language suffers in that way in comparison to most mainstream compiled languages.
The reasons are several: some fairly easily addressable (the primitive garbage collection in 1.8, for example), some less so.
1.9 addresses some of the issues, although it's probably going to be some time before it becomes generally available. Some of the other implementation that target pre-existing runtimes, JRuby, IronRuby, MagLev for example, have the potential to be significantly quicker.
Regarding mathematical performance, I wouldn't be surprised to see fairly slow throughput: it's part of the price you pay for arbitrary precision. Again, pick your problem. I've solved 70+ of the Project Euler problems in Ruby with almost no solution taking more than a mintue to run. How fast do you need it to run and how soon do you need it?
The most problematic part is "everyone".
Bonus points if that "everyone" didn't really use the language, ever.
Seriously, 1.9 is much faster and now is on par with python, and jruby is faster than jython.
Garbage collectors are everywhere; for example, Java has one, and it's faster than C++ on dynamic memory handling. Ruby isn't suited well for number crunching; but few languages are, so if you have computational-intensive parts in your program in any language, you better rewrite them in C (Java is fast with math due to its primitive types, but it paid dearly for them, they're clearly #1 in ugliest parts of the language).
As for dynamic features: they aren't fast, but code without them in static languages can be even slower; for example, java would use a XML config instead of Ruby using a DSL; and it would likely be SLOWER since XML parsing is costly.
Hmm - I worked on a project a few years ago where I scraped the barrel with Ruby performance, and I'm not sure much has changed since. Right now it's caveat emptor - you have to know not to do certain things, and frankly games / realtime applications would be one of them (since you mention OpenGL).
The culprit for killing interactive performance is the garbage collector - others here mention that Java and other environments have garbage collection too, but Ruby's has to stop the world to run. That is to say, it has to stop running your program, scan through every register and memory pointer from scratch, mark the memory that's still in use, and free the rest. The process can't be interrupted while this happens, and as you might have noticed, it can take hundreds of milliseconds.
Its frequency and length of execution is proportional to the number of objects you create and destroy, but unless you disable it altogether, you have no control. My experience was there were several unsatisfactory strategies to smooth out my Ruby animation loop:
GC.disable / GC.enable around critical animation loops and maybe an opportunistic GC.start to force it to go when it can't do any harm. (because my target platform at the time was a 64MB Windows NT machine, this caused the system to run out of memory occasionally. But fundamentally it's a bad idea - unless you can pre-calculate how much memory you might need before doing this, you're risking memory exhaustion)
Reduce the number of objects you create so the GC has less work to do (reduces the frequency / length of its execution)
Rewrite your animation loop in C (a cop-out, but the one I went with!)
These days I would probably also see if JRuby would work as an alternative runtime, as I believe it relies on Java's more sophisticated garbage collector.
The other major performance issue I've found is basic I/O when trying to write a TFTP server in Ruby a while back (yeah I pick all the best languages for my performance-critical projects this was was just an experiment). The absolute simplest tightest loop to simply respond to one UDP packet with another, contaning the next piece of a file, must have been about 20x slower than the stock C version. I suspect there might have been some improvements to make there based around using low-level IO (sysread etc.) but the slowness might just be in the fact there is no low-level byte data type - every little read is copied out into a String. This is just speculation though, I didn't take this project much further but it warned me off relying on snappy I/O.
The main speed recent increase that has gone on, though I'm not fully up-to-date here, is that the virtual machine implementation was redone for 1.9, resulting in faster code execution. However I don't think the GC has changed, and I'm pretty sure there's nothing new on the I/O front. But I'm not fully up-to-date on bleeding-edge Ruby so someone else might want to chip in here.
I assume that you're asking, "what particular techniques in Ruby tend to be slow."
One is object instantiation. If you are doing large amounts of it, you want to look at (reasonable) ways of reducing that, such as using the flyweight pattern, even if memory usage is not a problem. In one library where I reworked it not to be creating a lot of very similar objects over and over again, I doubled the overall speed of the library.
Steve Dekorte: "Writing a Mandelbrot set calculator in a high level language is like trying to run the Indy 500 in a bus."
http://www.dekorte.com/blog/blog.cgi?do=item&id=4047
I recommend to learn various tools in order to use the right tool for the job. Doing matrix transformations could be done efficiently using high-level API which wraps around tight loops with arithmetic-intensive computations. See RubyInline gem for an example of embedding C or C++ code into Ruby script.
There is also Io language which is much slower than Ruby, but it efficiently renders movies in Pixar and outperforms raw C on vector arithmetics by using SIMD acceleration.
http://iolanguage.com
https://renderman.pixar.com/products/tools/it.html
http://iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Primitives-Vector
Ruby 1.9.1 is about twice as fast as PHP, and a little bit faster than Perl, according to some benchmarks.
(Update: My source is this (screenshot). I don't know what his source is, though.)
Ruby is not slow. The old 1.8 is, but the current Ruby isn't.
Ruby is slow because it was designed to optimize the programmers experience, not the program's execution time. Slowness is just a symptom of that design decision. If you would prefer performance to pleasure, you should probably use a different language. Ruby's not for everything.
IMO, dynamic languages are all slow in general. They do something in runtime that static languages do in compiling time.
Syntax Check, Interpreting and Like type checking, converting. this is inevitable, therefore ruby is slower than c/c++/java, correct me if I am wrong.