程序員真的不怎麼需要關心底層代碼優化嗎？

12-26

根據amd的優化指南優化的ipc
代碼是
vmovupd xmmword ptr[tempdd1], xmm0;
vextractf128 xmmword ptr[tempdd1 + 16], ymm0, 1;

沒有優化的
vmovupd ymmword ptr[tempdd1], ymm0;

前一個基本可以做到每周期一個128bit的寫入，AMD渣渣的數據寫入能力實在是弱的要死

因為用戶會怪amd做的不好，不會管你的軟體寫得爛，然後他們就去買新手機，你的軟體就免費得到了優化，大家都開心啊。

那要看你是寫操作系統的程序員呢，寫驅動的程序員，寫編譯器的程序員，還是寫普通應用程序的程序員。
你寫的程序是在哪種系統上運行的，實時系統，還是非實時系統。
你的程序是在唯一的操作系統平台運行呢，還是需要能跨操作系統平台運行。
你的程序運行在特定的硬體平台呢，還是需要能在不同的硬體平台運行。
...
還有很多這樣的問題，所以是否需要根據底層這是根據項目而定的。不同的場景採取不同的策略。

對於大部分開發普通應用程序項目的程序員來說，答案是基本不需要關心底層，或者說已經沒辦法關心，用C/C++的程序員也許還能對內存使用進行一些優化，但是敢問一個用java或C#做開發的程序員，你如何去關心你寫的程序在AMD平台上會執行怎樣的彙編語句？這是寫虛擬機和編譯器和操作系統的人應該關心的事情。他們關心這些事情，目的就是上更上層的程序員不需要關心這個，大家各司其職。
一層一層之間應該是鬆散耦合的關係，我接受上一層提供的服務，但是我不關心上一層是如何實現的。

軟體成本= 開發成本+維護成本

維護成本=理解成本+修改成本+測試成本+部署成本等

通常情況下,維護成本是大於開發成本的.

很多軟體其實更看中可維護性. 因為很多軟體要維護幾年或十年以上,鐵打的營盤,流水的程序員.
做為項目的負責人,應該更看中誰的代碼寫的易懂,靈活,最後才是是否高效.
Kent Beck 曾在說過,優秀的代碼應該是簡單 ,溝通,靈活
而優秀的代碼往往更容易優化.
所以我們通常先寫好代碼,再把代碼寫快

個人感覺對太底層的就沒有必要關心了。。只要關心下面的那一層就夠。。

有必要，我正在做。。。。特別是一些定製晶元功能轉向x86軟體實現時，很需要底層提升性能。

有時間是可以了解底層優化的，主要是學習優化的思維。因為思維是相同的，不管你是做軟體還是硬體，只是實現手段不同而已。

分工問題啊。不是說不重要，而是沒必要，應該有專人負責。不然敲個代碼都需要從挖礦開始了