Dion Almaer
6/9/2005 9:40:00 PM
Actually, at a macro level there is no reason that Ruby or Python or Java
can not be as fast as C.
An example here is IronPython. Some of the python benchmarks run FASTER
under IronPython compared to the C Python.
Virtual Machine's are pretty darn smart now, and with the abstraction can do
smart things, like changing out the native code on the fly to end up with
smarter versions (vs. a one pass compilation step).
As an industry we often move up a chain, especially for app dev work.
I have never run into a bottleneck in a web application that occurred due to
the programming language. As soon as you are dealing with networks, disks,
and the like, architecture is always the key.
Just my 2p.
Cheers,
Dion
> -----Original Message-----
> From: Ryan Leavengood [mailto:mrcode@netrox.net]
> Sent: Thursday, June 09, 2005 1:38 PM
> To: ruby-talk ML
> Subject: Re: python/ruby benchmark.
>
> Lothar Scholz said:
> >
> > If i can't use the language because it is to slow to solve
> the problem
> > then the development time doesn't matter. There are just too many
> > problem domains left where you can't ignore it.
>
> I would like to hear some more specifics on these problem
> domains. I'm not trying to start an argument, I'm just
> wondering if the problems you are thinking of are just not
> appropriate for any interpreted language.
>
> Ruby or Python or Java will never be as fast as C, and C in
> most cases is not as fast as good hand-coded assembly. Any
> problem domain that requires major number crunching will need
> to be coded in the most efficient language, sometimes even
> requiring special hardware (like 3D graphics.)
>
> Of course with modern computers and compilers, I doubt anyone
> would code an entire application in assembly, but rather
> entirely in C or with just the hot spots coded in assembly.
> The same philosophy applies when moving to the higher level
> of Ruby, with C for the hot spots. I certainly wouldn't try
> to write a web application with C these days.
>
> In fact I would say that in most cases, for many problem
> domains, the huge increase in productivity that you get with
> higher level languages totally outweighs performance issues.
>
> Ryan