Pyston 改變方向,將主推模組載入的方式使用

Pyston 專案是一個想要提供更快速的 Python,而前陣子決定改變開發的方向:「Announcing 3.7-3.10 support and a new direction」。

本來的 Pyston-full 是直接修改 CPython 的 codebase 加速:

Our original product, which we’re retroactively calling Pyston-full, is a fork of the entire CPython codebase. Having users install a fully-custom version of Python lets us make changes across the Python implementation, leading to the most optimizations and largest speedups.

但這種方式的安裝與維護都需要另外搞,而且因為 ABI 不相容的問題,遇到一些套件可能會需要自己編 (甚至自己改?),不能直接用編好的 binary:

The flip side is that it is fairly intensive to set up. While we believe Pyston-full is one of the most highly-compatible alternative Python implementations available, it can be difficult to switch Python implementations regardless of the ease of use of either implementation. Compounded on this, we decided to break the ABI which requires users to recompile extension modules. In theory this is not a big deal, but in practice the lack of available binary packages is a significant disincentive to use an alternative implementation.

這樣雖然有 30% 的效能提昇,但對使用者的吸引力不高,所以打算要轉變方向,讓使用者更容易使用,這也是決定發展可以用 pip 安裝的 Pyston-lite 版本:

The sum of all of this was that while we were very happy to achieve a 30% speedup with Pyston-full, it was very difficult to get people to start using it. We decided to try a different form factor: a pip-installable extension module called Pyston-lite.

但效能的提昇就不像 Pyston-full 這麼高,Pyston-lite 只剩下 10% 了:

So while it’s a bit difficult to accept that we are now providing a 10% speedup instead of 30%, we’ve decided that it’s much more important to provide something that people are willing to use.

另外在文末有列出各版本的效能提昇 (與 CPython 3.8 比較),可以看到 CPython 3.11rc2 的提昇其實跟 Pyston-lite 差不多,除非 Pyston-lite 可以把效能疊加上去,不然就有點尷尬了:

但 Pyston 要支援 3.11 看起來會花不少功夫:

In the longer-term future we are planning to submit our JIT upstream as well, but we expect retargeting it to 3.11 to be significantly more work than the other versions due to the extensive amount of changes that were made to the interpreter in that version.

不過手上一些既有的東西好像可以掛上去測看看...

Python 3.7+ 保證 dict 內容的順序

在「Dicts are now ordered, get used to it」這邊看到的,因為 Python 官方 (也就是 CPython) 實做 dict 的方式改變,然後決定把這個特性當作是 social contract,而不是當作 side effect 的特性 (也就是不保證之後版本會有相同特性)。

Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.

作者裡面的兩張圖清楚表示出來以前的版本怎麼實做,與 3.7+ 的版本怎麼實做:

這樣就很好理解了。

不過考慮到還是有些系統用 Python 3.5 (像是 Ubuntu 16.04 內建的 python3) 與 Python 3.6 (Ubuntu 18.04 內建的 python3,雖然沒問題,但當時還沒有寫出來),也許還是先不要依賴這個行為會比較好。

不過以插入的順序列出好像不是很常用到...

Google 弄出來的 Grumpy:把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy,可以把 Python 2.7 的程式碼轉成 Go:「Grumpy: Go running Python!」。

下面看到一個留言頗有趣的:

This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文,這次的需求主要是出自 YouTube 的需求:

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍:

除了 C extension 不支援外,還是有些「過於動態」的語法不支援:

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少,這個專案可以當作 YouTube 這種規模的網站所做的改善,而不是什麼可以拿來用的工具 :o