How many lines of C it takes to execute a + b in Python • Hacker News Board

Re: How many lines of C it takes to execute a + b in Python

#221

Post by ngcc_hk » Thu, Dec 14, 2023, 10:45 PM UTC

lifthrasiir wrote: post #198

jerf wrote: post #185

Earlier quoted context omitted.

"If you have used Python long enough you may know that Python originally had two types of classes" Yes, because that's also the era where this claim was flying around. I'd say that each individual person may have their own read on what the claim meant, but certainly the way it was deployed at anyone who vaguely complained that Python was kind of slow shows that plenty of people in practice read it as I've described..…

Yeah, I agree everyone may have different anecdotes, for my case though I heard more of the "Python as glue code" arguments and never heard that Python proper can be as fast as C. I've used Python since 2.3, so maybe that argument was more prevalent before?

Same here. Never heard of python can be fast. It is not what it is originally for.

Re: How many lines of C it takes to execute a + b in Python

#222

Post by ngcc_hk » Thu, Dec 14, 2023, 10:50 PM UTC

pjmlp wrote: post #180

AlotOfReading wrote: post #142

Earlier quoted context omitted.

It's the whole design. Every object creates allocation/gc overhead, bytecode dispatch is a major bottleneck, attribute lookup is expensive, objects are expensive, namespaces are expensive, etc. You can change things internally (e.g. optimizing opcode parsing), fixed object layouts, restricting mutability, converting everything to predictable array accesses, but you'll likely just end up with something like Lua or Wre…

Smalltalk, Common Lisp and SELF are just as dynamic if not more, with a JIT.

That is a question in my mind throughout reading this discussion.

How about objective c vs swift from a dynamic at least type vs static one. Can swift be glue.

Re: How many lines of C it takes to execute a + b in Python

#223

Post by ngcc_hk » Thu, Dec 14, 2023, 11:07 PM UTC

KMag wrote: post #143

whizzter wrote: post #45

Earlier quoted context omitted.

The semantic issues of making a performant Python language implementation are more or less exactly the same as for JS and Lua, optimizing Ruby seems to possibly have even more "magic" that needs patching but we've seen the Shopify team get cracking on that (it includes MaximeCB that did HiggsJS). PyPy is in many aspects to be rated as a research project that tried a novel approach to reduce the workload compared to t…

> LuaJIT managed with less with a focused language and a really capable lead. It's pretty well established that "Mike Pall" is the pen name for an AI sent from the future for unknown reasons. It disappeared from our light cone due to a rift in causality, presumably because it succeeded in whatever changes it wanted to make in the future.

Finally got the proof that time travel did exist. But I wonder many like bitcoin might be. Then the pin drop could the whole python is a future ai coming in and prevent us from optimise and squeeze them out. They need the glue language. Ai depend upon it. Hence it is all for ai.

Re: How many lines of C it takes to execute a + b in Python

#224

Post by whizzter » Sat, Dec 16, 2023, 10:51 AM UTC

lifthrasiir wrote: post #218

whizzter wrote: post #215

Earlier quoted context omitted.

Iirc the slowness of CPython in all the above mentioned are artifacts of the implementation rather than the language itself. The huge issue is that a big selling point for Python was the easy C-api integration providing lots of useful functionality via libraries now works as a chain that limits how many changes can be made (see any GIL-removal discussion). The most sane way forward would be to mandate a conversion to…

I should clarify that LuaJIT is not universally used either, because LuaJIT doesn't support anything after Lua 5.1 among other reasons. People often claim that Lua is a relatively speedy language due to the existence of LuaJIT but it's not entirely correct.

It DIDN'T because Mike Pall(LuaJIT author) was on a hiatus from develoment. He's resumed work since and many 5.2+ features has been incorporated now even if the biggest language-turd (1: _ENV) is explicitly incompatible.

The problem is that _ENV explicitly exposes the lexical environment as regular objects prohibiting optimizations, even JavaScript has _removed_ a similar feature (2: the with statement) when running in "strict" mode to simplify optimizations.

LuaJIT _could_ implement the _ENV blocks but it'd seep into large parts of the codebase as ugly special cases that'd slow down all code in related contexts (thus possibly breaking much performance for code in seemingly unrelated places to where _ENV exists).

To compare from an implementation optimization perspective, exposing _ENV is actually __worse__ than what CPython has with the GIL for example.

Luckily "with"-statements in JS was seldomly used so implementers ignored it's existence as long as it's not used(but still have to consider it in implementations, thus adding more workload), but it's an wart that will kill many optimizations if used.

For most practical purposes most people are fine without "with" or _ENV and the languages are fast enough.

https://luajit.org/extensions.html

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...