4 ms·

Not sure why this is downvoted so badly, the comment is largely correct. This benchmark is even less useful than alioth's shootout, I'm not sure why there is s

by lucian1900 14y ago

Not sure why this is downvoted so badly, the comment is largely correct. This benchmark is even less useful than alioth's shootout, I'm not sure why there is so much effort put into it :)

papsosouid 14y ago
The comment is largely the authors opinion, it can be neither correct nor incorrect. It is very possible that what he feels is important and unimportant does not generalize to everyone else.
- voidlogic 14y ago
  Not to mention that he assumes all the faster langs take more effort. What if you could have a lang that is a best performance and be highly productive- he assume this is not possible. The Go code size is pretty small, in fact it might be smaller than the Rails code... I'm still trying to find all the Ruby files, Go is in one file...
  - kbenson 14y ago
    I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. Not sure yet if there are smaller ones (note that there are no other files required for those apps, period) In the same vein, Lua's OpenResty[4] looks good, as do Tornado[5], Flask[6] and Bottle[7] (although you need to tease the raw/ORM methods apart to get an idea for the last two). And of course, Sinatra[8]. There probably a lot more, especially for PHP, but I didn't feel like going through that list. [1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/mojolicious/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/dancer/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [3]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/kelp/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [4]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/openresty/app.lua https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/tornado/server.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [6]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/flask/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [7]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/bottle/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [8]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/sinatra/hello_world.rb https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
    - voidlogic 14y ago
      >>I don't consider the Go size pretty small. You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). Also, Go is statically typed = win
      - laumars 14y ago
        > Also, Go is statically typed = win Actually I find Perl's type system to make the most sense for web work: 1) Any zero length string or 0 valued int is classed as false, which is handy when checking the returns from query strings et al. 2) You can use eq for string comparison or == for numeric checking, which means which is handy has you can read values from a query string and then compare it against an int without having to do type conversion. Don't get me wrong, I don't have anything against statically typed languages - in fact I normally prefer them. But the way Perl does type checking I find reduces the number of type problems when dealing with web development. That all said, I much prefer working with structured types in Go than in Perl.
      - kbenson 14y ago
        > You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). hello.go uses more lines defining variables and types than the entirely of many of the alternatives I posted. Obviously they will be a little longer if they implement the fortune handler, but I doubt that will really make much of a difference. > Also, Go is statically typed = win I'm not sure what that has to do with implementation size (which is the only thing I was addressing), but feel free to make a case.
    - laumars 14y ago
      > I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. You've basically just listed Perl 3 times though. Particularly when the guts of the code in all 3 of those examples was Perl's standard database interface (the same DBI you'd use for CGI Perl or even standalone .pl scripts). I do love Perl for the flexibility of it's syntax and how concise the code can be. But for me the performance of Go won out. And while mod_perl* does make great gains in performance, it also makes the code a lot less portable (unlike Go). So I found myself porting my performance critical webapps over to Go * I've not tried Mojolicious, Dancer nor Kelp so I couldn't comment on how they compare for performance.
trailfox 14y ago
For many systems performance matters. Claiming that there is no difference between Ruby and C is just sticking your head in the sand.
- lucian1900 14y ago
  I only claimed that this is a not a useful (representative) benchmark, not that there is no difference between Ruby or C.
- freework 14y ago
  You can build an application in Ruby, deploy it onto 15 machines, and it will outperform the same application written in C and deployed to only one machine. Performance is more of a function of the underlying hardware than the language used to build it.
  - trailfox 14y ago
    If a language is 30x less efficient than another language then you would likely need 30x more servers. Many folk are simply not prepared to spend 30x more than they need to on hardware. It's the difference between 20 servers and 600 servers. Case in point: "How We Went from 30 Servers to 2": http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
    - kbenson 14y ago
      That's only true when you are using the full resources of one or more servers. If you are only using 1/100th of the server's resources, then being 30x less efficient still doesn't require any more servers. That doesn't negate the point though, language performance matters at certain scales.
  - oberhamsi 14y ago
    If you split a single app instance onto 15 machines, you will lose some efficiency due to network communication unless those 15 instances can work isolated without any shared data (sessions). That may not be much but worst case: you have to write that inter-machine sync code.

Not sure why this is downvoted so badly, the comment is largely correct. This benchmark is even less useful than alioth's shootout, I'm not sure why there is so much effort put into it :)

papsosouid 14y ago

The comment is largely the authors opinion, it can be neither correct nor incorrect. It is very possible that what he feels is important and unimportant does not generalize to everyone else.

voidlogic 14y ago
Not to mention that he assumes all the faster langs take more effort. What if you could have a lang that is a best performance and be highly productive- he assume this is not possible. The Go code size is pretty small, in fact it might be smaller than the Rails code... I'm still trying to find all the Ruby files, Go is in one file...
- kbenson 14y ago
  I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. Not sure yet if there are smaller ones (note that there are no other files required for those apps, period) In the same vein, Lua's OpenResty[4] looks good, as do Tornado[5], Flask[6] and Bottle[7] (although you need to tease the raw/ORM methods apart to get an idea for the last two). And of course, Sinatra[8]. There probably a lot more, especially for PHP, but I didn't feel like going through that list. [1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/mojolicious/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/dancer/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [3]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/kelp/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [4]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/openresty/app.lua https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/tornado/server.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [6]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/flask/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [7]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/bottle/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [8]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/sinatra/hello_world.rb https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
  - voidlogic 14y ago
    >>I don't consider the Go size pretty small. You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). Also, Go is statically typed = win
    - laumars 14y ago
      > Also, Go is statically typed = win Actually I find Perl's type system to make the most sense for web work: 1) Any zero length string or 0 valued int is classed as false, which is handy when checking the returns from query strings et al. 2) You can use eq for string comparison or == for numeric checking, which means which is handy has you can read values from a query string and then compare it against an int without having to do type conversion. Don't get me wrong, I don't have anything against statically typed languages - in fact I normally prefer them. But the way Perl does type checking I find reduces the number of type problems when dealing with web development. That all said, I much prefer working with structured types in Go than in Perl.
    - kbenson 14y ago
      > You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). hello.go uses more lines defining variables and types than the entirely of many of the alternatives I posted. Obviously they will be a little longer if they implement the fortune handler, but I doubt that will really make much of a difference. > Also, Go is statically typed = win I'm not sure what that has to do with implementation size (which is the only thing I was addressing), but feel free to make a case.
  - laumars 14y ago
    > I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. You've basically just listed Perl 3 times though. Particularly when the guts of the code in all 3 of those examples was Perl's standard database interface (the same DBI you'd use for CGI Perl or even standalone .pl scripts). I do love Perl for the flexibility of it's syntax and how concise the code can be. But for me the performance of Go won out. And while mod_perl* does make great gains in performance, it also makes the code a lot less portable (unlike Go). So I found myself porting my performance critical webapps over to Go * I've not tried Mojolicious, Dancer nor Kelp so I couldn't comment on how they compare for performance.

trailfox 14y ago

For many systems performance matters. Claiming that there is no difference between Ruby and C is just sticking your head in the sand.

lucian1900 14y ago
I only claimed that this is a not a useful (representative) benchmark, not that there is no difference between Ruby or C.
freework 14y ago
You can build an application in Ruby, deploy it onto 15 machines, and it will outperform the same application written in C and deployed to only one machine. Performance is more of a function of the underlying hardware than the language used to build it.
- trailfox 14y ago
  If a language is 30x less efficient than another language then you would likely need 30x more servers. Many folk are simply not prepared to spend 30x more than they need to on hardware. It's the difference between 20 servers and 600 servers. Case in point: "How We Went from 30 Servers to 2": http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
  - kbenson 14y ago
    That's only true when you are using the full resources of one or more servers. If you are only using 1/100th of the server's resources, then being 30x less efficient still doesn't require any more servers. That doesn't negate the point though, language performance matters at certain scales.
- oberhamsi 14y ago
  If you split a single app instance onto 15 machines, you will lose some efficiency due to network communication unless those 15 instances can work isolated without any shared data (sessions). That may not be much but worst case: you have to write that inter-machine sync code.