Re:Let's Remove the Global Interpreter Lock
by sillysaurus3 on Monday August 14, 2017 @10:58AM
(#15009045)
For example, Python makes it fairly easy to trap a call to a missing method, both via __getattr__ and __missing__. In JS the only way you can do that is via Proxy objects, and even those have limits.
You can't always inline the arithmetic ops effectively. You can recompile the method each time it's called with different types, but that's why the warmup time is an issue. This wouldn't be a problem if Python didn't make it so trivial to overload arithmetic. JS doesn't.
Re:Let's Remove the Global Interpreter Lock
by JulianWasTaken on Monday August 14, 2017 @11:14AM
(#15009194)
Ah! Yes, agreed, Python does certainly make it too easy to do things that cannot reasonably be sped up.
Re:Let's Remove the Global Interpreter Lock
by sillysaurus3 on Monday August 14, 2017 @11:19AM
(#15009255)
Twist: Lua makes it trivial to overload arithmetic using metatables, but LuaJIT seems to have solved that. If there is any warmup time, it's hard to tell. Mike Pall is a JIT god, and I wish we had more insight into everything that went into producing one of the best JIT's of all time.
I'd love a comment/post that highlights the differences between JS and Lua as the reason why LuaJIT was able be so effective. There must be differences that make Lua possible to speed up so much. There are easy ones to think of, but the details matter a lot.
EDIT: I found some discussion at https://news.ycombinator.com/item?id=1188246 but it left me wanting more.
Related:
https://stackoverflow.com/questions/4911762/why-is-luajit-so...
Re:Let's Remove the Global Interpreter Lock
by sillysaurus3 on Monday August 14, 2017 @02:02PM
(#15010898)
(And yeah the CPython API is still a pain point if you've got a library that uses it, although some stuff will still work using PyPy's emulation layer. It'd be great if people stopped using it though.)