雜談20190505

原本寫在部落格的 圖比較少就直接搬運一下~

---

本來說是每個月至少寫一篇的,似乎上個月不小心直接鴿了...

有一些想寫的東西,比如之前看到blazor或者LiveView,寫點前後端渲染相關的,但又感覺自己的知識面過於狹窄,內容不夠全不說可能還會寫錯誤導別人所以作罷.甚至還想寫瓶頸優化類的,但自己寫的程式碼那麼屎都沒自覺還寫文說怎麼優化... ...
就雜聊一些近況吧.
(說到blazor,這東西改名真夠頻繁的,最開始是一個實驗性質專案,之後吸收到 .NET Core 3.最開始是blazor,服務端渲染是razor component,在某一次改動後變成了整個叫razor component,blazor是client hosting model,最近因為概念理解起來會造成障礙又改回了第一個....真的是夠折騰的)

最近在(重新)看elixir,上一次似乎是4年多快5年前了,過了這麼多年,elixir的流行程式依舊那樣,看來是火不了了:(,適合做中介軟體的語言,結果始終沒有火起來,然而新興的Rust和Go已經在攻城略地.
這充分說明語言的流行與否與語言本身優秀與否可能關係不大(舉個不恰當的例子,java和C#在國內的流行程度),而與宣發和大廠背書可能關係大一點.
更悲慘的是erlang了,在流行度上面.
說到這個,上個月erlang之父 Joe Armstrong過世了,非常突然,畢竟前幾天還看到在推上和人聊硬體程式設計相關的事,還有之前的阿怪,一些熟悉的人名不經意間就已經不在了.

說到elixir有一些感悟,詳細的實現還沒看,基本也是看一些說明性質的東西. 因為本身就是基於BEAM的,所以天然獲得了搶佔式的process排程,這點和協作式的協程有很大不同,基於yield主動放棄控制權轉移給其他人的協程 vs 每個process有固定的時間片,各有利弊.
但這一切也都是基於系統執行緒上的,所以遇到的問題也是類似,遇上阻塞的系統呼叫怎麼辦.
elixir(BEAM)這邊的話還是老套路用IO執行緒池,排程器發現阻塞呼叫時會把阻塞的任務丟給執行緒池,把當前process掛起,讓對應的執行緒去執行其他process,這點和Go的思想是類似的(但Go的做法是將當前P的goroutine交給其他的P).
這些本質上其實都是一些魔法.
便於編寫程式碼的魔法.
回到java的世界,沒有這樣的執行時,沒有這樣的發現阻塞呼叫的機制.這些操作都是手動做的,把阻塞的IO扔到IO執行緒池做非同步化自己寫回撥,實現的東西是類似的,不過因為是要手寫,所以程式碼的好壞取決於人,又因為是協作的,所以java在少糖少魔法的情況下,程式碼的質量水平可能會相對堪憂.
語法糖和各種魔法還是很重要的.在工程角度上.

上面說到Go,想起了群裡討論的時候M P G裡的P被說成了核,但是一臉矇蔽,M已經是系統執行緒了,M應該是接近排程器之類的東西吧,M下掛個核是什麼意思? 後來找了下原文,發現原來是個類比... ...

A P can be thought of like a CPU in the OS scheduler and the contents of the p type like per-CPU state.

一些翻譯不走心然後各種引用就這麼傳下來了...

基礎概念不也是這樣嗎,感覺自己年少無知的一些概念完全是錯的,最近也是打自己臉打得疼,這些概念可能不直接影響寫的程式碼,但是影響看事的廣度和深度.比如把AIO和多執行緒繫結,覺得使用AIO會造成執行緒數增多,上下文開銷增加,但首先使用IOCP這種和執行緒無關的實現不會增加多少執行緒,其次,IO執行緒池的執行緒主要被阻塞並不會有執行CPU密集任務那樣來的那麼大開銷,不過開多了記憶體佔用倒是會變多.(上述這些話不知道什麼時候又要打臉了)

差不多也到這樣.
本來想寫點工作之類的,但想想畢竟和公司相關,還是算了.工作這種每個人有自己感悟,每個人也參與其中,寫出來大抵也差不多,還是算了.

---

一些資料:
https://dotnet.microsoft.com/apps/aspnet/web-apps/client

https://shift.infinite.red/phoenix-liveview-round-up-the-story-so-far-3cbb1648e940

https://hackernoon.com/remembering-joe-a-quarter-of-a-century-of-inspiration-and-friendship-3ddded0831ab

https://github.com/golang/go/blob/master/src/runtime/HACKING.md