Hacker News new | ask | show | jobs
by igouy 3199 days ago
And obviously the performance of programs using those language implementations on the same computer under the same workload may be measured and compared.

Why should "different families" of language implementation not be compared?
1 comments
etiene 3198 days ago
Firstly, the paper separates languages into compiled languages and interpreted languages to begin with. So I was expecting it would follow this pattern correctly.

Secondly, why would you compare the performance of C and Ruby, for example? Ruby is bound to be slower for design reasons. Doing it to say "Look, C is fast!" doesn't mean anything. There are different reasons one would compare C and Rust, or C and Ruby. The way the results are displayed and what it tries to convey is very important.

If you're not making a baseline, or being very clear, etc. then it's just misleading to have a benchmark portraying Javascript as faster than Ruby, Python and Lua. Either you put those into their correct classifications clearly, or you compare it with LuaJIT, PyPy, Julia etc.

link
igouy 3198 days ago
> … the paper separates languages into…

The paper, both shows tables that include all the results (ordered by Energy consumed) and shows separate charts for what the authors classify as "either a compiled, interpreted, or virtual-machine language".

What is "an interpreted language" ?

"Although we refer to Lua as an interpreted language, Lua always precompiles source code to an intermediate form before running it. … The presence of a compilation phase may sound out of place in an interpreted language like Lua. However, the distinguishing feature of interpreted languages is not that they are not compiled, but that any eventual compiler is part of the language runtime and that, therefore, it is possible (and easy) to execute code generated on the fly."

p57 "Programming in Lua" (2003)

> … why would you compare the performance of C and Ruby, for example? Ruby is bound to be slower…

Except when the C program is measured to be 50x slower than the Ruby program --

http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...

link
etiene 3197 days ago
Lua is not compiled to machine code. It compiles to an intermediate bytecode, which is then interpreted. So you could say it is a VM. Also bear in mind, LuaJIT is not Lua. It's a different implementation.

I guess you misinterpreted my comment. I didn't imply there are no reasons to compare C and Ruby. I said the reason is important and the way you portray that, and the way you portray your results, changes things.

link
igouy 3197 days ago
> Lua is not compiled to machine code…

Do you think Roberto Ierusalimschy is confused about that ?

Again, here's what the creator of Lua says -- "… the distinguishing feature of interpreted languages is not that they are not compiled, but that any eventual compiler is part of the language runtime…"

EDIT:

Is that not what you mean by "interpreted language" ?

link
etiene 3197 days ago
> Do you think Roberto Ierusalimschy is confused about that ?

No, of course not. I think you are. You are clearly misinterpreting his words. I will repeat, (PUC)Lua is not compiled to machine code, but to an intermediate bytecode form. Those are completely different things, and what I said does not come in conflict at all with the quote you took from PiL, so I don't know what you are confronting me about.

link
igouy 3196 days ago
> Lua is not compiled to machine code, but to an intermediate bytecode form.

Correct.

Now look at what Roberto Ierusalimschy means by "interpreted language": "… the distinguishing feature of interpreted languages is not that they are not compiled, but that any eventual compiler is part of the language runtime and that, therefore, it is possible (and easy) to execute code generated on the fly."

Is that what you mean by "interpreted language" ?

link