Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Q1. How is this possible?</strong></p> <p>Manual memory management (which is what CPython does with its counting) can be slower than automatic management in some cases. </p> <p>Limitations in the implementation of the CPython interpreter preclude certain optimisations that PyPy can do (eg. fine grained locks).</p> <p>As Marcelo mentioned, the JIT. Being able to on the fly confirm the type of an object can save you the need to do multiple pointer dereferences to finally arrive at the method you want to call. </p> <p><strong>Q2. Which Python implementation was used to implement PyPy?</strong></p> <p>The PyPy interpreter is implemented in RPython which is a statically typed subset of Python (the language and not the CPython interpreter). - Refer <a href="https://pypy.readthedocs.org/en/latest/architecture.html" rel="noreferrer">https://pypy.readthedocs.org/en/latest/architecture.html</a> for details.</p> <p><strong>Q3. And what are the chances of a PyPyPy or PyPyPyPy beating their score?</strong></p> <p>That would depend on the implementation of these hypothetical interpreters. If one of them for example took the source, did some kind of analysis on it and converted it directly into tight target specific assembly code after running for a while, I imagine it would be quite faster than CPython. </p> <p><strong>Update:</strong> Recently, on a <a href="http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html" rel="noreferrer">carefully crafted example</a>, PyPy outperformed a similar C program compiled with <code>gcc -O3</code>. It's a contrived case but does exhibit some ideas.</p> <p><strong>Q4. Why would anyone try something like this?</strong></p> <p>From the official site. <a href="https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement" rel="noreferrer">https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement</a></p> <blockquote> <p>We aim to provide:</p> <ul> <li><p>a common translation and support framework for producing<br> implementations of dynamic languages, emphasizing a clean<br> separation between language specification and implementation<br> aspects. We call this the <code>RPython toolchain</code>_.</p></li> <li><p>a compliant, flexible and fast implementation of the Python_ Language which uses the above toolchain to enable new advanced high-level features without having to encode the low-level details.</p></li> </ul> <p>By separating concerns in this way, our implementation of Python - and other dynamic languages - is able to automatically generate a Just-in-Time compiler for any dynamic language. It also allows a mix-and-match approach to implementation decisions, including many that have historically been outside of a user's control, such as target platform, memory and threading models, garbage collection strategies, and optimizations applied, including whether or not to have a JIT in the first place.</p> </blockquote> <p>The C compiler gcc is implemented in C, The Haskell compiler GHC is written in Haskell. Do you have any reason for the Python interpreter/compiler to not be written in Python?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload