Tag Archives: cpu

在一連串的安全更新後,AMD 的 CPU 比 Intel 快了...

在「Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches」這邊看到的測試:

把現有的安全性更新都開啟後,Intel CPU 的效能掉了 20% 左右 (在 Intel 上需要把 HT 關掉):

While the impacts vary tremendously from virtually nothing too significant on an application-by-application level, the collective whack is ~15-16 percent on all Intel CPUs without Hyper-Threading disabled. Disabling increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K).

The AMD CPUs are not tested with HT disabled, because disabling SMT isn’t a required fix for the situation on AMD chips, but the cumulative impact of the decline is much smaller. AMD loses ~3 percent with all fixes enabled

可以注意到兩家目前桌機的頂規在上了安全性更新後,AMD 的 2990WX 比 Intel 的 7980XE 快了一些些... 當初擠牙膏擠出來的都吐回去了,不知道之後出的 security issue 還需要再吐多少回去。

針對 JavaScript 時代調整網頁的效能評估指標

早期網頁的效能評估指標都沒有考慮 JavaScript 的情況,大多都是 TTFB (Time to First Byte) 或是網頁大小以及 DOMContentLoaded 或是 load 這類 DOM event 為主,但因為 Goodhart's law,現代的網頁設計會故意將許多 JavaScript 要做的事情搬到 load 以後開始做,以降低 load 被延遲的問題,讓前端的「KPI」比較好看:

When a measure becomes a target, it ceases to be a good measure.

但在 load 之後整個網站還是不能用,使用者的體驗其實很差,這個評估方式的價值變低不少。所以「Measuring Jank and UX」這篇就再找出一些新的指標,來評估 JavaScript 造成的問題。

可以看到文章裡面評估了很多關於 CPU loading 與操作時間的指標,也許這一兩年還會有用,不過我覺得還是會遇到 Goodhart's law 描述的問題... XD

AWS 推出使用 AMD CPU 的 t3a.*

AWS 推出了 t3a.* 的 EC2 instance:「Now Available – AMD EPYC-Powered Amazon EC2 T3a Instances」。

目前開放的區域有限,但算是個開始:

You can launch T3a instances today in seven sizes in the US East (N. Virginia), US West (Oregon), Europe (Ireland), US East (Ohio), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance form.

價錢大約再低個 10% 左右:

Pricing is 10% lower than the equivalent existing T3 instances; see the On-Demand, Spot, and Reserved Instance pricing pages for more info.

有些超小的機器可以考慮重開的時候就順便換過去...

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...

組一台 RISC-V 的 PC

RISC-V 是目前最有名的 open source 指令集,但似乎不太好找對應的硬體... 在「Building a RISC-V PC」這篇則是介紹了怎麼弄一台 RISC-V 的 PC:

採用的硬體是 HiFive Unleashed (USD$999),硬體架構包括了:

  • SiFive Freedom U540 SoC
  • 8 GB DDR4 with ECC
  • Gigabit Ethernet port
  • 32 MB quad SPI flash from ISSI
  • microSD card for removable storage
  • FMC connector for future expansion

沒有 USB 與 HDMI,作者是透過 HiFive Unleashed Expansion Board (USD$1999) 接出來的,不過這張還包括了 FPGA,這好像有點超過,兩個套件再加上 M.2 或是 SATA 的 disk 應該是超過台幣十萬...

不過畢竟算是早期的產品,之後有規模後應該會開始有中低價位的產品出現...

Linode 推出 Dedicated CPU Instances

Linode 決定要推出 Dedicated CPU Instances,看起來相當於 AWSEC2 裡一般性的 EC2 instance (指非 t 系列的),跟之前 CPU 共用而導致 CPU 可能時快時慢不同,這個方案讓 CPU resource 穩定輸出:「Introducing: Linode Dedicated CPU Instances」。

Dedicated instances are optimized for workloads where consistent performance is required or where full-duty work (100% CPU all day, every day) needs doing.

拿 EC2 裡的 c5.large (2vCPU + 4GB) 比較差不多是一半的價錢,但實際不知道差多少... 回台灣的時候測試看看好了。看起來如果真的要在 Linode 上跑 Kubernetes 的話反而要用這種機器?

JavaScript Framework 不可避免的成本

看到「The Baseline Costs of JavaScript Frameworks」這篇文章在研究目前主流 JavaScript Framework 無法避免的成本到底有多高。

文章的結論是目前常見的 JavaScript Framework 其實都很肥重,在網路速度不快的地方得花不少時間下載,在非旗艦的手機上會需要花不少時間處理 (parse & compile)。

這是 gzip 後的大小:

這是 parse & compile 的時間:

這是下載時間 (扣除 latency 與 TLS connection 建立時間):

並不是說不能用,但重點會在客群:

But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.

最後有建議如果只是要呈現資訊,不要用整套 JavaScript Framework,在有需要互動的地方另外寫就好了:

For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.

EC2 推出 ARM 架構的機器...

看到 AWS 推出使用 ARM 架構的 EC2 instance 了:「New – EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors」。

在 Quick Start 頁面有 Ubuntu 18.04 (ARM) 可以選,開起來後操作跟標準的 Ubuntu 差不多... 連進去後 uname -a 可以看到是 aarch64:

ubuntu@ip-172-30-2-207:~$ uname -a
Linux ip-172-30-2-207 4.15.0-1028-aws #29+nutmeg8-Ubuntu SMP Tue Nov 20 02:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

然後來看硬體規格,從最大台的 a1.4xlarge 來看是 16 vCPU + 32 GB RAM,定價是 $0.408/hr (這邊都拿 us-east-1 比較)。

對照 General Purpose 的 m5.4xlarge 是 16 vCPU + 60 GB RAM,定價是 $0.768/hr。如果看記憶體比較接近的 m5.2xlarge 則是 8 vCPU + 31 GB RAM,定價是 $0.384/hr。

對照 Compute Optimized 的 c5.4xlarge 是 16 vCPU + 68 GB RAM,定價是 $0.68/hr。

實際跑一些測試,包括 md5、sha256 與 aes (最後 aes 這個通常都有硬體加速),都用 -mutli 16 跑。

ARM 的 a1.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1064103.21k  2484789.44k  4436178.60k  5521370.45k  5943380.65k  5963896.15k
sha256         2059690.93k  5652827.82k 11792656.30k 16108863.15k 18086602.36k 18250851.29k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1593981.48k  1723960.38k  1752940.20k  1767321.94k  1770212.01k  1768281.43k
aes-192 cbc    1400010.40k  1496414.83k  1516962.99k  1527643.82k  1529834.15k  1527563.26k
aes-256 cbc    1222067.79k  1296972.50k  1313348.18k  1321350.83k  1322947.93k  1321850.20k
blowfish cbc   1384982.01k  1500548.63k  1529793.02k  1540091.22k  1540937.05k  1540767.74k

Intelm5.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1370869.17k  3276978.66k  5929591.13k  7441276.93k  8026330.45k  8071796.05k
sha256          592719.47k  1325135.04k  2506009.09k  3184234.50k  3455729.66k  3480365.74k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1060996.96k  1121951.87k  1135376.21k  1141487.96k  1143270.06k  1143499.43k
aes-192 cbc     890438.97k   934047.98k   943446.44k   947576.49k   948857.51k   949026.82k
aes-256 cbc     768686.53k   800152.85k   806883.93k   809804.12k   810784.09k   810937.00k
blowfish cbc   1735490.97k  1884059.78k  1923876.10k  1932711.94k  1934477.99k  1928680.79k

Intel 的 c5.4xlarge

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1501870.92k  3593434.20k  6503591.25k  8162811.90k  8804605.95k  8855147.86k
sha256          650179.22k  1453635.18k  2749318.83k  3492912.13k  3791164.76k  3818105.51k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1163898.98k  1230539.07k  1244414.63k  1252080.98k  1254110.55k  1254206.12k
aes-192 cbc     976610.23k  1024570.03k  1034886.66k  1039442.26k  1040872.79k  1041143.13k
aes-256 cbc     843184.42k   877695.30k   885125.46k   888408.06k   889503.74k   889766.83k
blowfish cbc   1877162.34k  2056925.74k  2107008.26k  2119893.67k  2121979.22k  2115720.53k

這些數字頗有趣的... 看起來 ARM 上面應該有對某些演算法加速,使得常見的情境會快很多。不過如果是其他應用的話看起來就會比較辛苦了... 目前就價錢來看未必有絕對的優勢,還是得看應用來決定。

Linux Kernel 4.20 修正了一卡車 Intel CPU bug,然後效能掉光了...

看到「Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower」這篇測試了目前還在 RC 的 4.20.0,可以看到 AMD 的效能沒有太大影響,但 Intel i9 的效能掉了很嚴重:

從說明可以看到有測出 30%~50%:

This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.

另外在其他 Intel CPU 上測試也發現不是只有 i9 有影響,低階的機器也是:

Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems.

透過 bisect 有找到是哪個 commit 造成的:

That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

但這又是屬於 security patch,不太能關... 加上自從 MeltdownSpectre 後,讓安全研究人員發現了全新的天地,之後應該只會愈來愈慘 :o

用 ESP8266 模擬 PC-XT...

看到拿 ESP8266 模擬 PC-XT,是個懷古時間:「IBM PC-XT Emulator on an ESP8266」。

現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了,直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑:

然後也可以跑 Windows 3.0:

純粹 hacking 的專案 XD