From: Charles O Nutter <headius@...>
Date: 2006-07-26T23:26:45+09:00
Subject: Re: For performance, write it in C

------=_Part_8417_30349664.1153924002671
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/26/06, Peter Hickman <peter@semantico.com> wrote:
>
> Charles O Nutter wrote:
> > I'll lob a couple of grenades and then duck for cover.
> >
> > - Write it in C is as valid as write it in Java (as someone else
> > mentioned).
> > Java is at least as fast as C for most algorithms.
>
> As someone who is paid to program in Java I very seriously doubt this.
> However I will write a Java version of the code and time it. It should
> be interesting to say the least.


Doubt all you like.

> All this said, there's truth to the idea that we shouldn't *have* to
> > write
> > platform-level code to get reasonable performance, and every effort
> > should
> > be made to improve the speed of Ruby code as near as possible to that
> > of the
> > underlying platform code.
> We are talking about two different things here. I was talking about
> performance as being the number 1 absolute top priority, you are talking
> about 'reasonable performance'. As far as I am concerned for those
> scripts that I don't convert to C Perl, Ruby and Python are fast enough.
> Other people think that they are not, they seem to expect the sort of
> performance C gives when they write things in a scripting language. I
> think that they are barking.


They may be hoping for the impossible, but that doesn't mean they shouldn't
hope and that doesn't mean they shouldn't be frustrated when the stock
answer is "write it in C". The fact that Ruby and other dynamic languages
are not as fast as compiled C is not the language's fault or the user's
fault...it's an implementation flaw. It certainly may be a flaw that can't
be fixed, a problem impossible to solve, but there's nothing about a
language's design that should necessitate it being slower than any other
language. Perhaps we haven't found the right way to implement these
languages, or perhaps some of us have and others just aren't there yet.
Either way, it's not the language that's eventually the problem...it's
simply the distance from what the underlying platform wants to run that's an
issue. C is, as they put it, closer to "bare metal", but only because C is
little more than a set of macros on top of assembly code. If the underlying
processor ran YARV bytecodes, I doubt Ruby performance would be a concern.

-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

------=_Part_8417_30349664.1153924002671--