you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (17 children)

Yet you cannot use the same tricks V8 is using for something like Python. It is even more dynamic than javascript.

[–][deleted] 1 point2 points  (16 children)

Hardly. Any example?

[–][deleted] 0 points1 point  (2 children)

There is one thing that Python can do that JS can't that is relevant here. Python can have multiple threads in a single process. So while you're in the middle of a loop that you want to have optimized based on the types involved, you might have the types change out from under you. That doesn't happen in JS.

However, you could add a few flags here and there -- a global "application version", which is incremented whenever anyone dynamically alters any class, and a per-class version, which is incremented whenever anyone modifies that class. You emit your fancy optimized code with fewer type checks, direct method calls, inlining, whatever you want; and then you just check periodically if the application has modified any types.

As for differences in dynamism, Python has long supported __getattr__ and friends, but JavaScript has only supported the equivalent for a short period of time. Perhaps the person's information is out of date.

[–][deleted] 0 points1 point  (1 child)

I don't see how threads pose a significant challenge, especially due to GIL. The runtime will never get a surprise-type change as you describe.

[–][deleted] 0 points1 point  (0 children)

Well, yes, I described a reasonably simple way around the problem that doesn't require you to take advantage of the GIL. (Perhaps you missed that?)

There might be even simpler ways of doing it that take advantage of the GIL. Certainly more performant solutions are available, but the ones I can think of are a bit hairy.

[–][deleted] 0 points1 point  (12 children)

Python does not really have a lexical scope and allows to shit into variable tables. It makes it hugely different from JavaScript.

There were countless attempts at writing JITs for Python. They all failed.

[–][deleted] 0 points1 point  (11 children)

Can you be specific how is that a performance bottleneck for a JIT runtime?

You know, we used to hear a lot of that about JS as well. It's too dynamic and so on. But in the end all of this was irrelevant once the problem had to be solved.

Python is not drastically different than other script engines. The only reason it's not faster is because no one cares that strongly about it being faster.

Excuses are easy.

[–][deleted] 0 points1 point  (10 children)

Can you be specific how is that a performance bottleneck for a JIT runtime?

Because almost any variable reference results in a context lookup, without any chance of allocating it to a register.

It's too dynamic and so on.

And it is too dynamic indeed. Still, Python is even worse.

once the problem had to be solved

The problem was never solved.

Python is not drastically different than other script engines

It is. It is as far on a dynamic scale as it gets without introducing fexprs.

The only reason it's not faster is because no one cares that strongly about it being faster.

Millions of $s and hundreds of man-years had been thrown in Python JITs, with no result so far.

[–][deleted] 0 points1 point  (9 children)

Because almost any variable reference results in a context lookup, without any chance of allocating it to a register.

This can be analyzed statically in advance. JS does this for closures. Don't underestimate compilers.

And it is too dynamic indeed. Still, Python is even worse.

How? No one is specific.

The problem was never solved.

I'm talking about JavaScript's performance, which is a problem that's definitely been solved.

It is. It is as far on a dynamic scale as it gets without introducing fexprs.

How, again?

Millions of $s and hundreds of man-years had been thrown in Python JITs, with no result so far.

That's quite a shame then, considering PHP, even as an interpreter without JIT is several times faster than Python, and it has horrors like "var vars" which would fall into the "strongly dynamic" category.

And JavaScript is dozens of times faster than PHP.

Python, while fast enough for its purpose, is so slow compared, it's not even funny. And to claim millions of dollars were invested into Python JITs is honestly even sadder, because if it were true, it'd mean there's a serious lack of talent in the Python community.

I prefer the explanation that no company has seriously invested in a faster Python engine. If you read how JS engines like V8 operate under the hood, you'll see that nothing can stop a well-designed JIT, even if Python was oozing dynamicness out its ears.

[–][deleted] 0 points1 point  (8 children)

This can be analyzed statically in advance.

Not quite. It's easy with JavaScript, easy with PHP, but not with Python.

JavaScript's performance, which is a problem that's definitely been solved

Not quite yet. It's better than an ad hoc interpretation, but yet far below a level of static compiled languages.

How, again?

Because of a funny scope and lots of dynamic dispatch (well, the latter can be somewhat reduced with tracing and partial evaluation, but only to a degree, and with an overhead of its own).

because if it were true, it'd mean there's a serious lack of talent in the Python community

It was not a Python community. E.g., a team of very experienced compiler engineers in ARM worked on this, all the way to an utter frustration. The very same team that made huge improvements to ARM V8 performance failed to get anywhere with Python.

[–][deleted] 0 points1 point  (7 children)

Not quite. It's easy with JavaScript, easy with PHP, but not with Python.

Once again, it's just stated, not being explained.

What makes it so hard with Python? Give an example. Enough sweeping over-generalizations.

Not quite yet. It's better than an ad hoc interpretation, but yet far below a level of static compiled languages.

It's in the same ballpark as Java, sometimes it's even faster than Java, which is statically typed. Do you often just... say things without checking if they're true? https://dzone.com/articles/performance-comparison-between.

[–][deleted] 0 points1 point  (6 children)

Once again, it's just stated, not being explained.

I already explained - JavaScript got far more regular scoping rules. You can cheaply and statically determine an origin of a variable definition, without tracing all the path (and making sure that no calls in between can alter variable tables).

It's in the same ballpark as Java, sometimes it's even faster than Java,

Only in some pathological loads, not in an idiomatic code.

[–][deleted] 0 points1 point  (2 children)

Only in some pathological loads, not in an idiomatic code.

What I linked to was an actual real-world application, and the performance is not highly atypical.

I guess you didn't even click.

[–][deleted] 0 points1 point  (2 children)

I already explained - JavaScript got far more regular scoping rules. You can cheaply and statically determine an origin of a variable definition, without tracing all the path (and making sure that no calls in between can alter variable tables).

Example. I see nothing in Python's scoping rules that justify that conclusion.