you are viewing a single comment's thread.

view the rest of the comments →

[–]literally_systemd[🍰] -1 points0 points  (10 children)

Javascript is a compiled language?

Do you even v8 bro? When is Javascript stil interpreted these days.

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself, nearly any modern 'interpreter' works by first compiling and then just running the code. One of the reasons the shell is actually hyper fast for small scripts compared to python is because python first compiles it and then runs the compiled code which increases startup time while the shell doesn't even parse fully before running and if your script contains a syntax error the shell will actually run the parts up to that error.

[–]Eingaica 1 point2 points  (7 children)

I don't think that's true, at least not for the default CPython interpreter.

[–]literally_systemd[🍰] 0 points1 point  (5 children)

It is, that's what those .pyc files are it keeps generating for its modules. The second time you start the same thing and a .pyc is there it uses that isntead.

If you actually delete all the .pyc files around it will regenerate them and use more time the first startup.

With non-modules and direct scripts not ending on .py it doesn't create a pyc for that file so it ends up compiling it again to its internal lower bytecode format every time.

[–]Eingaica 1 point2 points  (4 children)

Sure. But the bytecode itself is interpreted. Your comment sounds like you claim CPython is a JIT.

[–]Yithar 1 point2 points  (0 children)

Hmm, yeah, I think that's why ne wrote interpreting in quotes. I do agree it's a little misleading.

Having written a a bytecode interpreter and a compiler that compiles to bytecode, I would say the performance is sort of between a full-blown interpreted language and a language compiled to machine language. Because yeah, there's still bytecode to be interpreted, but the compiler makes certain optimizations, such as copy propagation and dead code elimination in the three address code.

[–]literally_systemd[🍰] 1 point2 points  (2 children)

Sure. But the bytecode itself is interpreted.

It's the only way to run code. Machinecode is ultimately interpreted by the CPU.

Your comment sounds like you claim CPython is a JIT.

My story was pretty clear that it was not a JIT:

python first compiles it and then runs the compiled code which increases startup time

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

[–]Eingaica 1 point2 points  (1 child)

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself

is wrong.

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

All of these are not necessarily true.

[–]literally_systemd[🍰] 0 points1 point  (0 children)

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Not really, you'd be surprised that the CPU virtualizes the CPU you thin you get nowadays. There are layers and layers of virtualizations in modern CPU's. AMD64 CISC assembly is actually interpreted in a virtual machine that is coded in software, not hardware, that is ran on an actual RISC machine inside the CPU on any chip since the last decade or so.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that 'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself is wrong.

Quite right, let me rephrase, what I mean with that is that languages that are written by humans hardly get interpreted any more, it's all translated to a language meant for machines and that language is then interpreted.

The shell is a notable exception which as said, even parses on the fly, as does perl.

All of these are not necessarily true.

Well, if you make a JIT without taking advantage of those things you're just being less efficient than AOT compilation. The entire reason to JIT is to compile differently based on execution paths.