3 ms·

> In the benchmarks where Python wins it's multithreaded For reverse-complement and binary-trees, the Python program uses less cpu time — it doesn't matter tha

by igouy 8y ago

> In the benchmarks where Python wins it's multithreaded For reverse-complement and binary-trees, the Python program uses less cpu time — it doesn't matter that it's multithreaded.

wahern 8y ago
For binary-trees it's because of the issue I mentioned. For reverse-complement I believe its partly because the low-level transformation is happening through a Python C module: see reverse_translation = bytes.maketrans(...). Lua is notoriously batteries NOT included. I suspect only a fraction of Python programmers have written a Python C module, at least for production use, because they rarely need to. By contrast, almost all PUC Lua programmers I have met have written Lua C modules, as you can't even do simple things like directory manipulation or sockets without third-party modules (few of which are "standard") or by writing a custom module. Lua is somewhat handicapped in these benchmark games as the language is fundamentally designed to be extended with C code. It doesn't come with any real modules of its own beyond a simple (non-regex) string matcher and bindings to the ISO C library. The whole point of Lua is that it's super trivial to write C modules; and as compared to writing Python or Perl C modules it's incomparably more straight forward, even for inexperienced C programmers. (The use of binding generators is usually discouraged as 9 times out of 10 manually written bindings are both easier to write and maintain.) But it obviously wouldn't be any more fair to permit custom-written Lua C modules in the benchmarks. If you look at all those benchmarks in just a little depth, I think it should be fairly clear that the core Lua VM is significantly faster--roughly 2x. OTOH, that's often irrelevant, especially if Python's core module ecosystem directly or indirectly helps you solve an issue. It's a fundamental limitation of the benchmark game, particularly regarding Lua. Lua isn't just a scripting language; it's thoroughly designed to be embedded in or extended by C. See the paper "Passing a Language through the Eye of a Needle: How the embeddability of Lua impacted its design", https://queue.acm.org/detail.cfm?id=1983083 https://queue.acm.org/detail.cfm?id=1983083
- igouy 8y ago
  > For binary-trees it's because of the issue I mentioned. No it is not — I removed that program before I replied. (Refresh you web browser cache).
- igouy 8y ago
  > It's a fundamental limitation of the benchmark game, particularly regarding Lua. It's a fundamental limitiation of language vs language comparison. See "Apples and Oranges" — view-source:https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

by igouy 8y ago

> In the benchmarks where Python wins it's multithreaded For reverse-complement and binary-trees, the Python program uses less cpu time — it doesn't matter that it's multithreaded.

wahern 8y ago

For binary-trees it's because of the issue I mentioned. For reverse-complement I believe its partly because the low-level transformation is happening through a Python C module: see reverse_translation = bytes.maketrans(...). Lua is notoriously batteries NOT included. I suspect only a fraction of Python programmers have written a Python C module, at least for production use, because they rarely need to. By contrast, almost all PUC Lua programmers I have met have written Lua C modules, as you can't even do simple things like directory manipulation or sockets without third-party modules (few of which are "standard") or by writing a custom module. Lua is somewhat handicapped in these benchmark games as the language is fundamentally designed to be extended with C code. It doesn't come with any real modules of its own beyond a simple (non-regex) string matcher and bindings to the ISO C library. The whole point of Lua is that it's super trivial to write C modules; and as compared to writing Python or Perl C modules it's incomparably more straight forward, even for inexperienced C programmers. (The use of binding generators is usually discouraged as 9 times out of 10 manually written bindings are both easier to write and maintain.) But it obviously wouldn't be any more fair to permit custom-written Lua C modules in the benchmarks. If you look at all those benchmarks in just a little depth, I think it should be fairly clear that the core Lua VM is significantly faster--roughly 2x. OTOH, that's often irrelevant, especially if Python's core module ecosystem directly or indirectly helps you solve an issue. It's a fundamental limitation of the benchmark game, particularly regarding Lua. Lua isn't just a scripting language; it's thoroughly designed to be embedded in or extended by C. See the paper "Passing a Language through the Eye of a Needle: How the embeddability of Lua impacted its design", https://queue.acm.org/detail.cfm?id=1983083 https://queue.acm.org/detail.cfm?id=1983083

igouy 8y ago
> For binary-trees it's because of the issue I mentioned. No it is not — I removed that program before I replied. (Refresh you web browser cache).
igouy 8y ago
> It's a fundamental limitation of the benchmark game, particularly regarding Lua. It's a fundamental limitiation of language vs language comparison. See "Apples and Oranges" — view-source:https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...