Tag: in

Fork 自微軟的 Pyjion 專案的 Python 3.10 + JIT 方案

在 Hacker News 上看到「Pyjion – A Python JIT Compiler (trypyjion.com)」這個專案，也是一個想要透過 JIT 加速 Python 的專案：

Pyjion is a drop-in JIT Compiler for Python 3.10. It can be pip installed into a CPython 3.10 installation on Linux, Mac OS X, or Windows.

看了一下是從微軟的 Pyjion 專案 fork 出來的，原來的專案最後一次 commit 是一年前，而且專案也已經標示為 archived (read-only mode)，但有留下轉移的說明，也就是上面提到的專案：

Development has moved to https://github.com/tonybaloney/Pyjion

可以看到大部分的效能都已經進入改善階段 (很多導入 JIT 的專案在初期時會先變慢)：

跟其他的 JIT 方案相比，Pyjion 的目標是高度相容現有 Python 的程式，包括各種 extension，這點的確是在用 PyPy 這些軟體時的痛點沒錯...

看起來透過 pip 裝好後就可以直接 import 進來用，後續就會生效：

import pyjion; pyjion.enable()

另外提一下，翻 Hacker News 留言的時候翻到這個害我笑出來，有夠新 XD

zatarc 3 days ago | unvote | prev | next [–]

Pyjion requires: CPython 3.10 and .NET 6

.NET 6 Release: 19 hours ago (https://github.com/dotnet/core/blob/main/release-notes/6.0/6...)

... ok.

Google 在南韓開放 app 裡面使用其他付款機制了

先前在「南韓對 Apple 與 Google 的 In-App 付款機制的提案」這邊提到南韓的法案將會強迫 Apple 與 Google 開放 IAP 的通路，前幾天 Google 正式發出公告會支援其他通路了：「Enabling alternative billing systems for users in South Korea」。

不免俗的，還是會放話說一些 FUD：

Alternative billing systems may not offer the same protections or payment options and features of Google Play's billing system—such as parental controls, family payment methods, subscription management, Google Play gift cards, and Play Points.

然後拖一下時間，說正在開發這些功能中：

In the coming weeks and months, we will share implementation details for developers, including instructions for submitting security and customer service verifications and a set of user experience guidelines so users can make an informed choice.

但這應該是第一個強制開放的市場？來等後續 payment gateway 給的數字...

YJIT 帶給 Ruby 大量的效能提昇

在 Hacker News 首頁上看到的消息，由 Shopify 贊助的 YJIT 被 Ruby 官方接受了：「Merge YJIT: an in-process JIT compiler (github.com/ruby)」。

YJIT currently provides average speedups of 23% over the CRuby interpreter on realistic benchmarks, and near-instant warm-up time.

實做 YJIT 的 Maxime Chevalier-Boisvert 在他自己的 blog 上有提到這次的實做：「YJIT: Building a New JIT Compiler Inside CRuby」，裡面選擇的方法是他的 PhD 論文：「Simple and Effective Type Check Removal through Lazy Basic Block Versioning」。

可以看到在六月寫文章的時候，改善其實還沒這麼大，而且作者提到有不少可以再提昇的空間：

That being said, according to our benchmarks, we’ve been able to achieve speedups over the CRuby interpreter of 7% on railsbench, 19% on liquid template rendering, and 19% on activerecord.

Currently, only about 50% of instructions in railsbench are executed by YJIT, and the rest run in the interpreter, meaning that there is still a lot we can do to improve upon our current results.

本來的 MJIT 看起來會慢慢淡出...

南韓對 Apple 與 Google 的 In-App 付款機制的提案

在 WSJ 上看到南韓對 Apple 與 Google 的 in-app 付款機制提案，強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台：「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇，裡面有引用韓國的媒體報導 (英文版)：「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過，目前過委員會而已 (parliamentary committee)，接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來，然後參議院提的法案也還在進行中，看起來還有很硬的仗要打：「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展，可以想見 Apple 與 Google 一定會想辦法抵制...

Mitmproxy 7 支援 TLS over TCP 的分析了

在 Hacker News 首頁上看到 Mitmproxy 7 的消息：「Mitmproxy 7」。

比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了：

不過像是 STARTTLS 這類先在 plaintext 溝通，然後送出指令進入 TLS 的方式，目前就還沒支援：

Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!

另外是可以分析 WebSocket 內的傳輸資料：

應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)

Amazon SNS 也支援 FIFO 模式了

看到 Amazon SNS 也支援 FIFO 模式了：「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。

Amazon SQS 在 2016 年就已經先支援了：「Amazon SQS 支援 FIFO 了」，官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。

在使用 FIFO mode 時與 SQS 有一樣的速度限制，每個 topic 只能到 300 TPS：

You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.

不過之前有需要保持順序的應用應該都先用 SQS workaround 了，不然就是自己搞能夠 FIFO 的 pub/sub 架構了。

Facebook 推出了 Hermes，為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine：「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy，針對行動裝置的特性而設計：避免 JIT 產生的 overhead，以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊：

不過沒有提到 CPU usage 會上升多少，只是帶過去：

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量，但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Amazon Aurora for MySQL 支援 Point-in-Time Recovery 了

繼四月出 DynamoDB 推出的 PITR 後 (參考「Amazon DynamoDB 的 Point-In-Time Recovery」這篇)，Amazon Aurora for MySQL 也宣佈支援 PITR 了：「Amazon Aurora Backtrack – Turn Back Time」。

從截圖可以看到支援到秒層級：

然後最多 72 小時，會有額外費用：

這樣又讓 DBA 少了一些事情 XD

Amazon DynamoDB 的 Point-In-Time Recovery

Amazon DynamoDB 在 3/26 發出來的功能，以秒為單位的備份與還原機制：「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。

先打開這個功能：

打開後就會開始記錄，最多可以還原 35 天內的任何一個時間點的資料：

DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.

這時候就算改變資料或是刪除資料，實際上在系統內都是 Copy-on-write 操作，所以需要另外的空間，這部份會另外計價：

Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.

有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果)，現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD

最後有提到支援的地區，是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援：

PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.

比對一下，應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域，另一個是本來上新功能就偏慢的區域。