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

Post by pjmlp » Wed, Dec 13, 2023, 7:39 AM UTC

igouy wrote: post #191

pjmlp wrote: post #183

Earlier quoted context omitted.

Better than CPython, regardless of how you put it. EDIT: Also to note, those languages powered whole graphical single workstations, with microcoded CPUs + JIT. "Efficient implementation of the smalltalk-80 system" https://dl.acm.org/doi/10.1145/800017.800542 https://computerhistory.org/blog/introducing-the-smalltalk-z... "Self-Confidence: How SELF Became a High-Performance Language" https://www.cs.cornell.edu/courses…

vs CPython https://benchmarksgame-team.pages.debian.net/benchmarksgame/... vs Node https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Post by pjmlp » Wed, Dec 13, 2023, 7:42 AM UTC

igouy wrote: post #190

lifthrasiir wrote: post #182

Earlier quoted context omitted.

Is there any direct comparison though? Because it can be alternatively argued that these dynamic languages needed new JIT techniques for performance, but they especially work well for more constrained languages like JS. I don't think Smalltalk was ever a good fit for number crunching, for example.

So if one was "Prototyping a Real-Time Embedded System in Smalltalk" one might 'improve frequently invoked methods by recoding, possibly as “primitive” functions in a lower level language such as C or assembler'. https://dl.acm.org/doi/pdf/10.1145/74878.74904

Post by lifthrasiir » Wed, Dec 13, 2023, 10:18 AM UTC

Sesse__ wrote: post #199

lifthrasiir wrote: post #176

Earlier quoted context omitted.

If you want to be return absolutely any value from an iterator, an exception is indeed a reasonable choice though. Python generators came in much later, unlike JS for example.

If that is indeed a requirement, you let your iterator have an .at_end() test instead of trying to shoehorn it into the return value. Or have something like C++'s std::optional or Rust's Option. Or a special EndOfIteration object that you cannot return from an iterator (is that really so bad?). Iteration is extremely common, and should thus be based on as simple primitives as possible if you want things to go fast.

Post by acqq » Wed, Dec 13, 2023, 1:58 PM UTC

monoprotic wrote: post #121

acqq wrote: post #113

Earlier quoted context omitted.

I agree with that estimate, I think it was really the idea of Python to be less than "good" by design. I mean one doesn't need more than: >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit to see. They have that special handling, but they still don't want to let you out, because... IMO, they just want to be annoying. When a solution could be something like: Note: exit() is needed in scripts. In this prompt Ctrl-D (i.e.…

There has been discussion of this change a few times, e.g. https://bugs.python.org/issue44603 I generally agree with your overall sentiment, but I think it's important to note that the behavior is _not_ special handling; it's just the normal `repr` behavior at the REPL, where `exit` is an object like any other, and `repr(exit)` is that message.

    >>> x = open( "/tmp/whatever123", "w" )
    >>> close( x )
    Traceback (most recent call last):
      File "", line 1, in 
    NameError: name 'close' is not defined. Did you mean: 'cosh'?
    ...    
    >>> x.close()
    >>>
    >>> x = "tttt"
    >>> x.len()
    Traceback (most recent call last):
      File "", line 1, in     
    ...
    >>> len( x )
    4

Post by igouy » Wed, Dec 13, 2023, 7:32 PM UTC

lifthrasiir wrote: post #196

igouy wrote: post #192

Earlier quoted context omitted.

> Most languages with enough optimization works can be made performant enough that it's no slower than 10x C. Maybe if we take the slowest C program, CPython no slower than 50x ? https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

CPython had many other concerns besides from performance, and PyPy is much closer to my quote I believe.