幹壞事是進步最大的原動力
作者 Mark Callaghan 在討論 MySQL 在量小的時候，新版可能反而比舊版慢：「The history of low-concurrency performance regressions in MySQL 5.6, 5.7 and 5.8」。
One example of the regression occurs for in-memory sysbench where MySQL 5.7 and MySQL 8 get 60% to 70% of the QPS compared to 5.6, which is the same as writing that 5.6 gets 1.43X to 1.67X more QPS than MySQL 5.7 and MySQL 8.
其實不算太意外，因為功能愈來愈多，而且最佳化的重心都放在用量大的各種情境下。並沒有針對 single thread 時的情境最佳化...
Mark Callaghan 寫了篇關於 performance_schema 的用法 (很短)，讓大家先把這個參數開習慣，雖是入門推廣班：「Short guide on using performance_schema for user & table stats」。
他推薦的兩個資訊是：
select * from table_io_waits_summary_by_table select * from events_statements_summary_by_account_by_event_name
當使用 5.7+ 時，可以考慮這兩個：
SELECT * FROM sys.schema_table_statistics SELECT * FROM sys.user_summary
簡單到不行，但卻可以幫不少忙... 很棒的入門推廣班 XDDD
半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫：「MySQL 8.0: Retiring Support for the Query Cache」。
作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明：
Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.
主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale，很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法，將 cache 放到 client 的效能比較好：
We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:
可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了：「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。
一般如果要 cache 的話，透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。
看到 OpenBSD 可以跑 Docker 的消息：「Docker on OpenBSD 6.1 (-current)」：
整個步驟其實還是很 hack，文章裡可以看到一堆奇怪的方法，有種虛擬機惡搞的氣氛 XDDD (因為是透過 Alpine 弄出來的)
雖然這篇用的方法很簡單，但因為太符合本 blog 的副標，所以還是寫下來介紹：「Extracting Chinese Hard Subs from a Video, Part 1」。
作者想要把字幕拉出來，他直接把這張圖丟進 OCR，然後失敗 XDDD：
他決定拉出下半段：
再做 thresholding：
最後再 OCR 取得文字：
′…′二′′′'′ 怎么去逯么远的地方 '/′
雖然很粗糙，但已經可以感覺到「幹壞事是進步最大的原動力」的感覺了 XDDD 而且看起來會有續集，會用比較精緻的技巧來處理？
PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越，參考下面的連結)，這使得後來大家為了相容性與擴充性的考量，HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊，作者從 packagist.org 上得到的數據)：
這使得 Symfony 決定在 Twitter 上蒐集意見，而後決定下一個 major version (4) 將不再支援 HHVM：「Symfony 4: End of HHVM support」。
Is it time to drop #HHVM support in #Symfony 4? Or anyone willing to see how make tests pass? https://t.co/qm3fQbcFat
— Fabien Potencier (@fabpot) May 18, 2017
馬上想到的是 Laravel 用了一堆 Symfony 的元件啊，之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用，甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。
這個禮拜被 AlphaGo 洗臉後，又看到來搶工作的東西了：「pix2code: Generating Code from a Graphical User Interface Screenshot」。
直接把 Mockup 圖檔丟進去，然後就把 iOS 或是 HTML 程式碼生出來：
不過「刻 UI」的確是工程師最討厭的事情啦，這部份能自動化要怎麼說呢... 好像也是不錯的事情啦 @_@
Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。
以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：
The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!
維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：
The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.
第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：
Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.
可以注意到把 Redis 當作 cache 層而非 storage 層。
主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。
在「Apps with hardware: enabling run-time architectural customization in smart phones」這邊看到去年就有論文在討論在手機上使用 FPGA 的想法...
的確現在 FPGA 的價錢其實是蠻平價的了... 除了透過 GPU 加速外，FPGA 聽起來也是個不錯的方向 @_@
最直接的例子就是 AES 運算來看，可以看到比現在最快的實做快了半個數量級，大約三倍？(跟支援硬體加速的 OpenSSL 比，看格子大約是半格，也就是 100.5，約 3.16 倍)。
而如果是純軟體的應用，有些會差到四個數量級... (萬？)
