fp32、fp16 與 bf16

nanoGPT 這個專案下面看到 bf16 這個浮點格式:(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16,是由 Google 的團隊所提出來的想法,主打是與 fp32 相同的表示範圍,但是犧牲精度,這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement):

然後同一頁也看到各家自己推出不同的格式,這邊看起來比較像是市場競爭的關係...

0.1 + 0.2 = 0.30000000000000004

看到「http://0.30000000000000004.com/」這個網站對經典的 0.1 + 0.2 問題整理了各語言的結果。這個網址名稱也很機車啊 XD

開頭的說明講述 IEEE 754 二進制表示法的問題:

Your language isn't broken, it's doing floating point math. Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That's why, more often than not, .1 + .2 != .3.

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.

這邊主要是討論 IEEE 754-1985 這個標準,後來在 IEEE 754-2008 提出了新的表示方法,支援十進位的表示法來解這個問題 (雖然還沒普及)。

DigitalOcean 提供 Floating IP 功能

DigitalOcean 推出的新功能,可以註冊 IP 並且動態掛到某個 droplet 上:「Floating IPs: Start Architecting Your Applications for High Availability」。

如果沒有掛到 droplet 上會收取 USD$0.006/hour 的費用,以一個月 720 小時來計算,大約是 USD$4.32/month。另外也限制在同一個 data center 內才能換來換去。

類似的功能在 Linode 很久前就有了 (2007 年底),雖然不是完全一樣:「Support for High Availability / IP Failover」,但 Amazon EC2 的 Elastic IP 功能幾乎就相同了,在 2008 年初開放:「New EC2 Features: Static IP Addresses, Availability Zones, and User Selectable Kernels」,所以只能算是補產品線,把大家都有的功能實作出來...

以往只能用 DNS 做 High Availability 的,現在可以用這種方法做,使得 downtime 可以更低。另外這樣做也可以架設 proxy server,使得對外的 IP 不變,讓 firewall 設定變得單純。

DEC64 浮點數

Hacker News Daily 上看到「DEC64: Decimal Floating Point」:

公式是:

value = coefficient * 10exponent

是以 10 為底。

0 與 NaN 是特別處理:

There are 255 possible representations of zero. They are all considered to be equal.

There is a special value called nan that has a coefficient of 0 and an exponent of -128. The result of division by zero is nan. nan is also the result of operations that produce results that are too large to be represented. nan is equal to itself.

網域也註冊一段時間了,不知道為什麼被突然提起...:

   Domain Name: DEC64.COM
   Registrar: 1 & 1 INTERNET AG
   Whois Server: whois.schlund.info
   Referral URL: http://1and1.com
   Name Server: NS57.1AND1.COM
   Name Server: NS58.1AND1.COM
   Status: ok
   Updated Date: 03-jun-2013
   Creation Date: 02-jun-2009
   Expiration Date: 02-jun-2014

Fast Inverse Square Root 演算法...

中文稱為「平方根倒數速演算法」,英文則是「Fast Inverse Square Root」。

好像是在 Twitter 還是 Facebook 上看到的 (還是是在其他管道?),仔細看中文版維基百科條目,發現中文版的資料相當完整了 (看了一下歷史記錄,是去年 2012 年 6 月的時候從英文版翻出來的)。

當時很有名的 magic hack,比查表法快:

在1990年代初(也即該演算法發明的大概時間),軟體開發時通用的平方根計算方法多是從尋找表中取得近似值,而這段代碼取近似值耗時比之更短,達到精確度要求的速度也比通常使用的浮點除法計演算法快四倍,

然後還比 CPU 指令集快 XD

由於演算法所生成的用於輸入牛頓法的首次近似值已經相當精確,此演算法所得近似值的精度已可接受,而若使用與《雷神之鎚III競技場》同為1999年發行的Pentium III中的SSE指令rsqrtss計算,則計算平方根倒數的收斂速度更慢,精度也更低。

Update:請參考 comment,看起來中文版有誤譯...

我本來以為我之前寫過,找了找沒翻到... 補記錄下來 :p