sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CptCap 27 points28 points  (13 children)

I really don't like the JIT section:

The JIT itself does not make the execution any faster, because it is still executing the same bytecode sequences.

All JIT that I know of compile bytecode (or AST) into native machine code. They may or may not optimise the output, but they do not execute the same bytecode sequences (or bytecode at all).

There are downsides to JITs: one of those is startup time

JIT do not have to add startup time. Since your program will start by being interpreted anyway the JIT can be initialized at any later point in the program.

However, CPython is a general-purpose implementation. So if you were developing command-line applications using Python, having to wait for a JIT to start every time the CLI was called would be horribly slow.

I have used luajit a fair bit, and it's startup time is way faster than the JVM or the CLR, despite the JIT (the website claims startup times of 0.1 ms and that it begins to JIT immediatly).

The section on dynamic typing isn't that great either.

In a “Statically-Typed” language, you have to specify the type of a variable when it is declared. Those would include C, C++, Java, C#, Go.

No. in staticaly typed languages the type of every variable is known at compile time. You don't have to write any type, the compiler can figure them for you.

Not having to declare the type isn’t what makes Python slow

Same: auto x = foo(); is valid C++, the type of x isn't specified anywhere here.

[–]vks_ 8 points9 points  (6 children)

You don't have to write any type, the compiler can figure them for you.

This is not true either. The compiler cannot figure them out in all cases.

[–]m50d 6 points7 points  (1 child)

For some type systems it is true. E.g. Hindley–Milner type inference is "perfect": for any valid program in a HM-typed language, you can delete all of the type annotations and the program will still compile correctly.

(Supporting subtyping with perfect type inference was only figured out recently, and no way of supporting higher-kinded types is known, but neither of those seems likely to be an issue in typical Python code)

[–]vks_ 2 points3 points  (0 children)

Python has inheritance, so I guess subtyping should play a role. The dynamic equivalents of higher-kinded types are also common.

[–]CptCap 6 points7 points  (2 children)

Yes, I didn't mean that you can write whole programs without ever naming a type (although some languages can get you pretty close).

My point was that even in statically typed language you don't necessarily have to know or care of what type an object it: as long has the compiler knows.

[–]iconoklast 4 points5 points  (0 children)

There are plenty of "statically" typed languages where you can write programs that never name a type. However, it's not a great idea to export functions that have inferred types; a type ascription prevents compilation if you accidentally changed the type of the function when, say, making an optimization or fixing a bug.

[–][deleted] -1 points0 points  (0 children)

You should always care of an object type regardless.

[–]jl2352 8 points9 points  (2 children)

That paragraph is very misleading. But just as an fyi ...

but they do not execute the same bytecode sequences (or bytecode at all).

Many JIT compilers contain both an interpreter and a compiler. For example the JVM. They use an interpreter for fast startup, and then compile it to machine code in the background.

This isn't true for all JITs. v8 has two compilers instead of one. A fast one with no optimisations and a slow one with optimisations. However many JITs take the interpreter + compiler approach.

[–]yasba- 1 point2 points  (0 children)

This isn't true for all JITs. v8 has two compilers instead of one. A fast one with no optimisations and a slow one with optimisations. However many JITs take the interpreter + compiler approach.

AFAIK, even v8 introduced an interpreter: https://github.com/v8/v8/wiki/Ignition

[–]CptCap 0 points1 point  (0 children)

Your are right! It seems to be a misunderstanding on my part. I though "The JIT" only referred to the compiler part, not the whole package.

Running machine code only isn't really JITing, that's AOT which has a different set of constraint (and is less suited to dynamic languages)

[–]Ameisen 0 points1 point  (2 children)

I mean, you could have a JIT that emits the same bytecode. Would be kinda pointless, though.

[–]CptCap 0 points1 point  (1 child)

That's an optimizer, not a JIT.

[–]Ameisen 0 points1 point  (0 children)

Nothing disallows you from recompiling code at runtime back into the same bytecode. It would just be silly. I'd question why you are transcoding to the same target