c 標(biāo)準(zhǔn)庫(kù)中為什么沒有網(wǎng)絡(luò)庫(kù)？或則很有可能是是因?yàn)槊總€(gè)平臺(tái)提供的最優(yōu)方案網(wǎng)絡(luò)編程模型變不一樣，甚至于還可優(yōu)化。因?yàn)椋蚁?，?shí)現(xiàn)標(biāo)準(zhǔn)化限制修改了發(fā)揮空間，畢竟它還沒法能找到一個(gè)類似于最優(yōu)解的解。就像e

c 標(biāo)準(zhǔn)庫(kù)中為什么沒有網(wǎng)絡(luò)庫(kù)？

或則很有可能是是因?yàn)槊總€(gè)平臺(tái)提供的最優(yōu)方案網(wǎng)絡(luò)編程模型變不一樣，甚至于還可優(yōu)化。因?yàn)?，我想，?shí)現(xiàn)標(biāo)準(zhǔn)化限制修改了發(fā)揮空間，畢竟它還沒法能找到一個(gè)類似于最優(yōu)解的解。

就像epoll是所謂的的reactor模型，而iocp是proactor型。所以，縱然目前文件系統(tǒng)的庫(kù)進(jìn)了標(biāo)準(zhǔn)庫(kù)，而網(wǎng)絡(luò)庫(kù)目前還沒有。

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

Python語言其實(shí)很慢，為什么機(jī)器學(xué)習(xí)這種快速算法步驟通常還是用呢？

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

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

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

如果能這個(gè)回答極大幫助，歡迎別人交流，一起進(jìn)步?。。?/p>