c 標準庫中為什么沒有網(wǎng)絡庫？或則很有可能是是因為每個平臺提供的最優(yōu)方案網(wǎng)絡編程模型變不一樣，甚至于還可優(yōu)化。因為，我想，實現(xiàn)標準化限制修改了發(fā)揮空間，畢竟它還沒法能找到一個類似于最優(yōu)解的解。就像e

c 標準庫中為什么沒有網(wǎng)絡庫？

或則很有可能是是因為每個平臺提供的最優(yōu)方案網(wǎng)絡編程模型變不一樣，甚至于還可優(yōu)化。因為，我想，實現(xiàn)標準化限制修改了發(fā)揮空間，畢竟它還沒法能找到一個類似于最優(yōu)解的解。

就像epoll是所謂的的reactor模型，而iocp是proactor型。所以，縱然目前文件系統(tǒng)的庫進了標準庫，而網(wǎng)絡庫目前還沒有。

或則，這一切都出當然了C的哲學：找到最靠近事物本質的最優(yōu)解。如果沒有，請用第三方或自己解。但，不排除腎炎未來或許會決定分解重組可選解（標準庫之易變的選擇性解，看上去像java的deprecated一樣的）——目前是有這個傾向的。

Python語言其實很慢，為什么機器學習這種快速算法步驟通常還是用呢？

Python語言的執(zhí)行效率確實是不高，也就是許多人所說的“慢”,這要注意是基于組件Python語言本身的設計實現(xiàn)方法:Python是相冊語言而且是講解執(zhí)行的而不是像C等都屬于靜態(tài)編譯型語言；這令Python語言的執(zhí)行并非像其他語言像由CPU就先執(zhí)行而是按照一個虛擬機執(zhí)行（也就是Python中的解釋器），在CPU之上又加了一層抽像使得先執(zhí)行出聲更慢點。

但，“慢”確實是相對于的。不能執(zhí)行“慢”不代表上帝開發(fā)“慢”，在許多應用形式的場景中，代碼的執(zhí)行性能高低不是什么關鍵因素。舉個例子，如果沒有你有個簡單的任務要自動化，你不可能關心你的腳本是不能執(zhí)行了0.0001s那就0.01s(慢了100倍），你很可能更冷淡的是你會花費一個小時還是一分鐘完成這個自動化任務。

而這對機器學習的任務中，它比較普遍的工作流程中包括了（數(shù)據(jù)收集、數(shù)據(jù)處理、數(shù)據(jù)建模、模型評估、布署等），在整個流程過程中會包涵了大量試錯、應用完全不同算法、調參等實驗，開發(fā)速度對于這類問題格外十分重要；而是對性能提升方面，Python也這個可以有幾種方法來可以解決：一是依靠一些C/C實現(xiàn)程序的庫，如Numpy不能加速負責執(zhí)行；反而憑借Python先提出機器學習的原型設計，這對超級大數(shù)據(jù)量的任務可以不來回切換到其他framework如Spark等負責執(zhí)行。

如果能這個回答極大幫助，歡迎別人交流，一起進步！！！