5 ms·

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to

by zinxq 13y ago

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the tractor doesn't perform up to snuff, we'll add a spoiler (and given the 10x disparity between Java and Ruby in some of those graphs, if we throw out a 20mph top speed for a farm tractor, the ferrari analogy is actually rather spot on). There are many good reasons to choose dynamic/interpreted languages - but always know you're giving up performance in exchange.

camus 13y ago
People chose language X over language Y not for performance reasons. Cost , ease of use and deployment , librairies , available programmers ,etc ... Things are more complicated than just a benchmarks. Furthermore NodeJS and raw PHP are doing quite well in the benchmarks.
- zinxq 13y ago
  I did say exactly that - there's plenty of good reasons for choosing them - but understanding its a tradeoff is a good idea. In other words, although interesting (and exceedingly well done) these benchmarks should have "surprised" no one. Not even the disparity between languages.
dragonwriter 13y ago
> Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. True. > That's like choosing between a farm tractor or a ferrari - and figuring if the tractor doesn't perform up to snuff, we'll add a spoiler Its really not like that at all, because programming languages aren't like vehicles. Particularly, with Ruby, on typical method of optimization is finding which bits of code are bottlenecks, and then optimizing those bottlenecks, often by replacing them with C (or, if the Ruby runtime being used in JRuby, Java). Which I guess is like having your tractor turn into a Ferrari for the parts of work that involve going long distances on a road without towing something, but I think that kind of points out how bad even using the tractor/Ferrari analogy is.
- candybar 13y ago
  I keep hearing about this, but do people really rewrite performance-critical parts of their web apps in C? Even if it happens to be part of some third-party library? And maintain a fork? What if that performance-critical part is dependent on other parts in a non-trivial way? It seems that an unanticipated replacement of some core functionality with a C library may involve a major rewrite and most Ruby teams may not have the expertise to do a good job maintaining a C code base any way.
  - binarysoul 13y ago
    In many cases it is as easy as relying on a gem instead of doing it yourself. Where the gem contains a c extension. Say resizing images with chunkypng vs mini_magick
  - sbov 13y ago
    I've never heard of it for webapps. They usually just buy more instances/servers. It would be interesting to see the profile of some these benchmarks for the various frameworks to see where the bottleneck is.
  - dragonwriter 13y ago
    > I keep hearing about this, but do people really rewrite performance-critical parts of their web apps in C? Certainly they do it for Ruby apps in general. I don't think its all that common for it to be a high-value proposition for web apps. > Even if it happens to be part of some third-party library? And maintain a fork? If its an open-source third-party library that tends to get used in a way that is performance-critical, upstream will probably accept moving bottlenecks to (portable) C and maintaining the API, so its unlikely that you'll need to take up responsibility for a fork. > What if that performance-critical part is dependent on other parts in a non-trivial way? If the call pattern is such that they are not part of the performance critical part themsellves, then the performance critical part calls them through the regular conventions for calling Ruby from C. If the call patter is such that they are part of the performance critical piece, well, I think the answer is obvious. > It seems that an unanticipated replacement of some core functionality with a C library may involve a major rewrite It might, but in the meantime you've got working code. > and most Ruby teams may not have the expertise to do a good job maintaining a C code base any way. If the team determines it needs expertise in a particular area that it doesn't currently have, then it should either develop that expertise or bring in people that have it. That's true whether its particular domain expertise (e.g., building messaging systems) or particular technology expertise (e.g., C). That's part of the normal development of a team.
jakejake 13y ago
I think the tractor/ferrari analogy does't really hold up because a tractor to me implies that it would be slower, but more powerful. The ferrari sacrifices power for speed. I'd say these platforms are more like comparing a ferrari with a go-kart. Or comparing a ferrari with another ferrari that has 10,000 lbs of bricks in the trunk. (Actually, that probably doesn't hold up either because ferraris probably don't have trunks!) But to further add to the analogy, the tractor, the ferrari and the go-kart may all perform about the same if you're only traveling 1 inch. Love me some analogies!
cmircea 13y ago
To add my 2 cents, static languages have started adding dynamic features. One example is C#.
justincormack 13y ago
Openresty is doing pretty well with Lua and despite the fact it uses LuaJIT it is actually interpreted and the JIT compiler is not used (that will change eventually). Ruby is just slow, as is PHP.
- meric 13y ago
  Can't wait to see Openresty benchmark with LuaJIT.
- continuations 13y ago
  > despite the fact it uses LuaJIT it is actually interpreted and the JIT compiler is not used Why not - is that a limitation of OpenResty or of LuaJIT? How would you turn on JIT compiler in OpenResty?
  - justincormack 13y ago
    The traditional Lua API is interpreted only so every call interrupts a trace. You have to use the ffi API to call C code instead. Plus some string operations are interpreted only but that is being fixed. It is all being worked on but there is a fair amount to do...

by zinxq 13y ago

camus 13y ago

People chose language X over language Y not for performance reasons. Cost , ease of use and deployment , librairies , available programmers ,etc ... Things are more complicated than just a benchmarks. Furthermore NodeJS and raw PHP are doing quite well in the benchmarks.

zinxq 13y ago
I did say exactly that - there's plenty of good reasons for choosing them - but understanding its a tradeoff is a good idea. In other words, although interesting (and exceedingly well done) these benchmarks should have "surprised" no one. Not even the disparity between languages.

dragonwriter 13y ago

> Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. True. > That's like choosing between a farm tractor or a ferrari - and figuring if the tractor doesn't perform up to snuff, we'll add a spoiler Its really not like that at all, because programming languages aren't like vehicles. Particularly, with Ruby, on typical method of optimization is finding which bits of code are bottlenecks, and then optimizing those bottlenecks, often by replacing them with C (or, if the Ruby runtime being used in JRuby, Java). Which I guess is like having your tractor turn into a Ferrari for the parts of work that involve going long distances on a road without towing something, but I think that kind of points out how bad even using the tractor/Ferrari analogy is.

candybar 13y ago
I keep hearing about this, but do people really rewrite performance-critical parts of their web apps in C? Even if it happens to be part of some third-party library? And maintain a fork? What if that performance-critical part is dependent on other parts in a non-trivial way? It seems that an unanticipated replacement of some core functionality with a C library may involve a major rewrite and most Ruby teams may not have the expertise to do a good job maintaining a C code base any way.
- binarysoul 13y ago
  In many cases it is as easy as relying on a gem instead of doing it yourself. Where the gem contains a c extension. Say resizing images with chunkypng vs mini_magick
- sbov 13y ago
  I've never heard of it for webapps. They usually just buy more instances/servers. It would be interesting to see the profile of some these benchmarks for the various frameworks to see where the bottleneck is.
- dragonwriter 13y ago
  > I keep hearing about this, but do people really rewrite performance-critical parts of their web apps in C? Certainly they do it for Ruby apps in general. I don't think its all that common for it to be a high-value proposition for web apps. > Even if it happens to be part of some third-party library? And maintain a fork? If its an open-source third-party library that tends to get used in a way that is performance-critical, upstream will probably accept moving bottlenecks to (portable) C and maintaining the API, so its unlikely that you'll need to take up responsibility for a fork. > What if that performance-critical part is dependent on other parts in a non-trivial way? If the call pattern is such that they are not part of the performance critical part themsellves, then the performance critical part calls them through the regular conventions for calling Ruby from C. If the call patter is such that they are part of the performance critical piece, well, I think the answer is obvious. > It seems that an unanticipated replacement of some core functionality with a C library may involve a major rewrite It might, but in the meantime you've got working code. > and most Ruby teams may not have the expertise to do a good job maintaining a C code base any way. If the team determines it needs expertise in a particular area that it doesn't currently have, then it should either develop that expertise or bring in people that have it. That's true whether its particular domain expertise (e.g., building messaging systems) or particular technology expertise (e.g., C). That's part of the normal development of a team.

jakejake 13y ago

I think the tractor/ferrari analogy does't really hold up because a tractor to me implies that it would be slower, but more powerful. The ferrari sacrifices power for speed. I'd say these platforms are more like comparing a ferrari with a go-kart. Or comparing a ferrari with another ferrari that has 10,000 lbs of bricks in the trunk. (Actually, that probably doesn't hold up either because ferraris probably don't have trunks!) But to further add to the analogy, the tractor, the ferrari and the go-kart may all perform about the same if you're only traveling 1 inch. Love me some analogies!

cmircea 13y ago

To add my 2 cents, static languages have started adding dynamic features. One example is C#.

justincormack 13y ago

Openresty is doing pretty well with Lua and despite the fact it uses LuaJIT it is actually interpreted and the JIT compiler is not used (that will change eventually). Ruby is just slow, as is PHP.

meric 13y ago
Can't wait to see Openresty benchmark with LuaJIT.
continuations 13y ago
> despite the fact it uses LuaJIT it is actually interpreted and the JIT compiler is not used Why not - is that a limitation of OpenResty or of LuaJIT? How would you turn on JIT compiler in OpenResty?
- justincormack 13y ago
  The traditional Lua API is interpreted only so every call interrupts a trace. You have to use the ffi API to call C code instead. Plus some string operations are interpreted only but that is being fixed. It is all being worked on but there is a fair amount to do...