Those show the statistics for a small application IMO.
Sure.
Once our application serves 200 million page views each day, and generates
4T datas on storage. Under that case, the languange is really sensitive, so
we go with C/C++.
shrug
Data storage is irrelevant, since that’s all carried by whatever
technology one is using for the data store – there are no Ruby
performance implications there.
200,000,000 page views a day, though… So what? Architect the application right, and the scaling will follow (though sometimes
getting that architecture right is a bitch). The devil is in the
details. I can say with confidence, though, that I could spin up an
Engine Y. Cloud instance tomorrow, duplicate this app I referenced
onto it, and using a 100% Ruby stack (i.e. without even using the EY
default nginx for front end web server), I am confident that I could
drive 200,000,000 page views through it in a day on a single instance.
However, it’s not a pissing contest. Someone can always come up with
instances where more speed is absolutely vital, requiring one to make
specific language choices to realize the needed speed. Nor am I
saying that we shouldn’t be thinking about performance when working on
the internals of MRI or any other Ruby implementation; we should! But
the assertion that I was responding to – that Ruby’s performance (MRI
Ruby’s anyway) is somehow inadequate for delivering very fast web
applications – is clearly false.
To come around to the original line of inquiry, though… People are
on the right track by looking at the Ruby 1.9 performance. One might
also look at Rubinius and JRuby. However, the method of timing is
suspect. Timings should be taken from inside the code, wrapped
around the specific items being timed, so that one eliminates
differences in startup costs in the final numbers. One should also,
if looking at jruby, collect timings from multiple iterations so that
the optimizer has a chance to do its thing.
On Tue, Jan 5, 2010 at 10:32 AM, Marnen Laibow-Koser [email protected]
wrote:
But my point was a bit different. Â Python and Ruby are basically similar
languages, and what annoys me is that there seems not to have been the
will in the Ruby community to steal some speed tricks from Python. Â (I’d
be working on this if I knew anything practical about language
implementation, but I don’t.)
Unfortunately, the Python community seems to turn to “write it in C” a
lot more often than the Ruby community has, so the #1 performance
trick for Python is to not write in Python. That’s obviously the wrong
direction for us to go…I don’t think anyone here would prefer to
write C over Ruby (or Java, or C++, or C#) when Ruby is the right tool
for the job…
And I’ll also mention the truth of performance we’ve discovered
repeatedly in JRuby: if you don’t have fast core classes, you don’t
have a fast Ruby implementation. 99% of the performance problems we’ve
investigated over the years could be traced back to core class
implementations, which in most implementations are already written in
a “fast” language like C or Java (Rubinius has a mix of C++ and Ruby
for most core classes, with emphasis on Ruby). So a large number of
poor-performing systems in Ruby can be directly attributed to misuse
or slow implementation of core methods. And that’s a much harder and
extensive challenge to meet.
On 01/05/2010 05:32 PM, Marnen Laibow-Koser wrote:
But my point was a bit different. Python and Ruby are basically similar
languages, and what annoys me is that there seems not to have been the
will in the Ruby community to steal some speed tricks from Python. (I’d
be working on this if I knew anything practical about language
implementation, but I don’t.)
Well, 1.9 has been improved dramatically in the area of performance
(among others). Whether this is because of “tricks stolen from Python”
I cannot judge. Your statement seems to imply that the Ruby community
is negligent of performance which is not true.
Why does everybody say that CPUs are fast nowadays and that “it dosn’t
mattar that language XYZ is slow”?
I have a Core2Dual, with each core clocking in at 2GHz. This is a
low-end CPU. Do you think I’m bothered about a millisecond, or even
100ms, for that matter?
The speed of an application isn’t just in the language used, but in how
fast an application appears. If it seems that an application is fast by,
for example, starting to display data soon enough (in a CRUD app,
starting to show the first few rows of the result set, while the
backend’s still collecting the whole shebang), is for all intents and
purposes fast enough.
It does matter: web applications. If your applications can’t serve all
the visitors, then you’re going to lose your customer or you’ll have to
learn some other language with better performance.
Especially in web applications, the speed of your language of choice is
less relevant than in any other possible scenario. You have about 2
seconds per unique visitor to build the whole page, before users think a
website is slow. That’s ages.
Now, if we talk about mobile devices, then CPU and memory constraints
start to reappear. But not on the desktop and the intertubes.
Why does everybody say that CPUs are fast nowadays and that “it dosn’t
mattar that language XYZ is slow”?
Dunno about everybody else. I did not
a) say that CPU’s are fast nowadays,
b) say that it does not matter that Ruby is slow,
c) claim we should not care about Ruby’s performance.
I specifically asked “does it matter?” For me it doesn’t (especially
since 1.9 is there) but that does not mean that it doesn’t for others.
Hence the question.
It does matter: web applications. If your applications can’t serve all
the visitors, then you’re going to lose your customer or you’ll have to
learn some other language with better performance.
Kirk has responded better than I could and I believe there is nothing
more I could add to this.
Those show the statistics for a small application IMO.
Once our application serves 200 million page views each day
200 million page views a day is an average of 2,300 page views a
second. This is reasonably close under the statistic that Kirk cited
(for some conversion between page views and requests).
On Tue, Jan 5, 2010 at 10:32 AM, Marnen Laibow-Koser [email protected]
wrote:
But my point was a bit different. Â Python and Ruby are basically similar
languages, and what annoys me is that there seems not to have been the
will in the Ruby community to steal some speed tricks from Python. Â (I’d
be working on this if I knew anything practical about language
implementation, but I don’t.)
Unfortunately, the Python community seems to turn to “write it in C” a
lot more often than the Ruby community has, so the #1 performance
trick for Python is to not write in Python. That’s obviously the wrong
direction for us to go…I don’t think anyone here would prefer to
write C over Ruby (or Java, or C++, or C#) when Ruby is the right tool
for the job…
Devil’s advocate: is Ruby the right tool the job for thoses cases?
Obviously, I’d rather write in Ruby than in C* or Java, but in a case
where the use of Ruby leads to performance problems, Ruby is probably
ipso facto not the right tool for the job.
And I’ll also mention the truth of performance we’ve discovered
repeatedly in JRuby: if you don’t have fast core classes, you don’t
have a fast Ruby implementation. 99% of the performance problems we’ve
investigated over the years could be traced back to core class
implementations, which in most implementations are already written in
a “fast” language like C or Java (Rubinius has a mix of C++ and Ruby
for most core classes, with emphasis on Ruby). So a large number of
poor-performing systems in Ruby can be directly attributed to misuse
or slow implementation of core methods. And that’s a much harder and
extensive challenge to meet.
I can well believe that, though I had understood that some of Python’s
speed boost came from bytecode compilation as well.
On 01/06/2010 06:27 PM, Marnen Laibow-Koser wrote:
Devil’s advocate: is Ruby the right tool the job for thoses cases?
Obviously, I’d rather write in Ruby than in C* or Java, but in a case
where the use of Ruby leads to performance problems, Ruby is probably
ipso facto not the right tool for the job.
Before you can make that judgement you need to find out the reason for
slowness. A flawed design might be faster in C but fixing the design in
Ruby might yield even better performance.
I can well believe that, though I had understood that some of Python’s
speed boost came from bytecode compilation as well.
I very doubt it.
I’m sorry, I really don’t understand how your reply relates to my
statement. I responded to Marnen questioning whether Ruby was the right
tool for a particular job. I wasn’t talking about the language’s design
but about the design of the application. And I specifically suggested
to fix the design but keep the language and not fix the design in a
different language. Of course, if the design isn’t flawed or the person
doing the fix can’t do it (in either language) then the whole procedure
is deemed to fail.
Before you can make that judgement you need to find out the reason for
slowness. A flawed design might be faster in C but fixing the design in
Ruby might yield even better performance.
I have sounded many guys talking about the flawed design when they
compare a languange to another. Yes a flowed design will make program
run much slower even it’s by C. But the problem is, if a person make bad
desigin in C language, will he do it right in other language like Ruby?
I very doubt it.
I have sounded many guys talking about the flawed design when they
compare a languange to another. Yes a flowed design will make
program run much slower even it’s by C. But the problem is, if a
person make bad desigin in C language, will he do it right in other
language like Ruby? I very doubt it.
Someone once said: “It’s a poor workman who blames his tools.” How
true it is.
Jose
…
Jose Hales-Garcia
UCLA Department of Statistics [email protected]
