提到人工智能，為什么總會(huì)說Python？是因?yàn)槟_本語言寫下來很簡單容易。Python雖說慢但它只是因?yàn)閯?dòng)態(tài)創(chuàng)建AI接口，真正的計(jì)算全是C/C寫好的底層，用Python僅僅寫邏輯，即最先怎莫算，第二步怎

提到人工智能，為什么總會(huì)說Python？

是因?yàn)槟_本語言寫下來很簡單容易。

Python雖說慢但它只是因?yàn)閯?dòng)態(tài)創(chuàng)建AI接口，真正的計(jì)算全是C/C寫好的底層，用Python僅僅寫邏輯，即最先怎莫算，第二步怎么算，幾行代碼就進(jìn)去了。

變成C，得先學(xué)1個(gè)月才能編譯器按照。不是什么說用C寫不了上層邏輯，完全是代碼量太大，開發(fā)完畢效率太低，到頭來總體速度實(shí)力提升1%，不最合適。

計(jì)算機(jī)語言各有適用性，即C/C速度快比較適合底層寫算法，Python慢但比較適合上層寫邏輯。

兩者共同牛叉的特點(diǎn)恰好是對(duì)方的特點(diǎn)。

Java和C# 最大的不同是什么？

我感覺先不說語法而談，最主要的應(yīng)該對(duì)底層的控制能力不同。

C#一就開始只不過借鑒Java，但是目的幾乎并非替造一個(gè)betterJava，反而造一個(gè)betterC。游戲引擎?zhèn)兤珢跜#也是有這一層原因在里面。

.例如在C#里面你能干的：

上述事項(xiàng)代碼會(huì)輸出10，我想知道為什么？是因?yàn)?NET中數(shù)組的長度存儲(chǔ)于數(shù)組第一個(gè)元素之前的8字節(jié)內(nèi)存中。要是你再隨后輸出*((way*)p-2)，將會(huì)然后換取這個(gè)對(duì)象的TypeHandle地址：

然后再拎著這個(gè)指針又接著能去不能訪問對(duì)象的MethodTable。

再有你還可以不手動(dòng)啟動(dòng)在棧上分配空間：

接著你想繞到GC然后手動(dòng)啟動(dòng)分配堆內(nèi)存：

根據(jù)上述規(guī)定動(dòng)態(tài)創(chuàng)建互逆于你在C語言中動(dòng)態(tài)鏈接庫的malloc，至于也有AllocAligned、Realloc、AllocZeroed等等，這個(gè)可以然后壓制內(nèi)存環(huán)形折彎。

接下來的你想修改一個(gè)顯式內(nèi)存布局的結(jié)構(gòu)Foo：

然后你就順利演示出了一個(gè)C的Union，本來會(huì)有上面的輸出，是畢竟單精度浮點(diǎn)數(shù)1的二進(jìn)制意思是為0x00111111100000000000000000000000，以小端存儲(chǔ)后占4個(gè)字節(jié)，共有是0x00000000、0x00000000、0x10000000、0x00111111。

一系列，你又能然后從內(nèi)存數(shù)據(jù)沒有任何拷貝開銷地構(gòu)造對(duì)象：

甚至于那樣：

從堆內(nèi)存創(chuàng)建家族自然也沒問題：

再例如，此時(shí)你面前有一個(gè)不使用C編寫的庫，其中有這么多很長代碼：

然后我們編譯程序追加C#代碼：

上面的代碼干了什么事情？我們將C#的函數(shù)指針傳不到了C代碼中，然后把在C側(cè)調(diào)用C#函數(shù)生成氣體了一個(gè)字符串wwwww，后再將這個(gè)字符串返回給C#側(cè)。而就算不用什么函數(shù)指針換成在用委托也沒有區(qū)別，畢竟.NET中的委托下面就是函數(shù)指針。

甚至于，如果我們不想讓.NET導(dǎo)入foo.dll，我們想讓其決定相冊(cè)庫的生命周期，還也可以這么多寫：

上面這些都不是Windows專用，在Linux、macOS上導(dǎo)入.so和.dylib都完全話下。

再有，我們有一些數(shù)據(jù)想?yún)⑴c換算，不過我們想在用SIMD并且處理，那只必須這么說寫：

也可以看看在X86平臺(tái)上生成了什么代碼：

平臺(tái)推測的分支會(huì)被JIT不自動(dòng)消除。但反正除此之外不自動(dòng)c語言設(shè)計(jì)SIMD代碼之外，前兩個(gè)分支完全是可以不寫，而只留下：

因?yàn)楝F(xiàn)階段當(dāng)循環(huán)邊界條件是向量長度時(shí)，.NET會(huì)手動(dòng)為我們做向量化并發(fā)起循環(huán)。

那就一直，我們另外ref、outside、土爆來做摘錄傳遞。

打比方我們有一個(gè)比較大的struct，我們是為盡量避免傳遞時(shí)突然發(fā)生拷入，這個(gè)可以就用into來做只讀模式引用傳遞：

而對(duì)于小的struct，.NET有專門的優(yōu)化幫我們徹底消滅掉內(nèi)存分配，全部將struct放在旁邊寄存器中，例如:代碼：

上述代碼GetDistance考慮到是個(gè)熱點(diǎn)路徑，因此我加來指導(dǎo)JIT有保證地內(nèi)聯(lián)此函數(shù)，最后為Test化合了不勝感激的代碼：

50分鐘沒有一句指令訪存，更加的高效穩(wěn)定。

我們還是可以利用ref的摘錄語義來做原地自動(dòng)更新：

甚至連能配搭指針和不自動(dòng)分配內(nèi)存來建議使用：

C#的泛型不像Java需要擦除數(shù)據(jù)，而是真正地會(huì)對(duì)所有的類型參數(shù)特化代碼（盡管是對(duì)摘錄類型會(huì)鏈接共享實(shí)現(xiàn)方法區(qū)分運(yùn)行時(shí)交回），這不能最大程度必須保證性能，而且對(duì)應(yīng)的類型具備依據(jù)什么類型參數(shù)大小完全不同而特化的內(nèi)存布局。應(yīng)該上面那個(gè)Point的例子，我們將下面的數(shù)據(jù)int換成泛型參數(shù)T，并做值類型數(shù)字的泛型約束：

哪怕Test1那就Test2，生成沉淀的代碼都的很極優(yōu)秀，不光不未知任何的裝箱拆箱，哪怕沒有任何的訪存你的操作：

隨后講，我們有時(shí)是為更高性能是想預(yù)備先暫停GC的回收，只必須簡單的一句：

就能提醒GC如果不是能分配128mb內(nèi)存那肯定最好別做回收公司了，然后一段時(shí)間內(nèi)以后的代碼我們事實(shí)上在這個(gè)預(yù)算內(nèi)分區(qū)分配內(nèi)存，任何GC都不可能發(fā)生。甚至還也能攔阻在內(nèi)存太差分配的情況下接受堵塞式largeGC：

代碼執(zhí)行完了，到最后的時(shí)候動(dòng)態(tài)創(chuàng)建一句：

即可恢復(fù)GC行為。

除此之外，我們又能在運(yùn)行時(shí)重新指定GC的模式來最大化性能：

更及時(shí)，我們甚至于也可以就將堆內(nèi)存中的代碼執(zhí)行，在.NET上自己造一個(gè)JIT，就從內(nèi)存創(chuàng)建那塊可想執(zhí)行的區(qū)域然后往里面塞一段代碼用來將兩個(gè)32位整數(shù)相加：

外，C#還有更多成百上千的底層寫法來和操作系統(tǒng)交互，甚至還依靠C#的編譯器取消后鏈接到自己的標(biāo)準(zhǔn)庫，真接用從0又開始造基礎(chǔ)類型然后把是從NativeAOT編譯出完全無GC、都能夠在裸機(jī)硬件上先執(zhí)行強(qiáng)行系統(tǒng)的EFI固件全是沒有問題的，參考

另還有一個(gè)ILGPU讓你把C#代碼再跑在GPU上面，這些跑在嵌入式設(shè)備上真接你的操作I2C、PWM、GPIO等等，就繼續(xù)舉例子了。

而C#早進(jìn)了roadmap的后續(xù)更新內(nèi)容：不允許聲明引用字段、直接添加表達(dá)出固定設(shè)置長度內(nèi)存的類型、允許傳數(shù)組時(shí)永久消除數(shù)組分配、允許在棧上怎么分配任何對(duì)象等等，無一不是在改進(jìn)這些底層性能設(shè)施。

以上應(yīng)該是我以為的C#和Java大的不同。

在C#中當(dāng)你不要上面這些的東西時(shí)，它們仿若從來都不存在地，不允許日志類型、不停吸收各種函數(shù)式特性、還有一個(gè)各種語法糖加持，簡潔度和靈話度甚至于不輸Python，相當(dāng)娛快和簡單地就能c語言設(shè)計(jì)各種代碼；而一但你不需要，你可以不擁有從上層到底層的幾乎完全的控制能力，而這些能力將能讓你有需要時(shí)不需認(rèn)真的思考各種奇怪的workaround就能然后榨光機(jī)器，提升到C、C的性能，甚至還而且有運(yùn)行時(shí)PGO而遠(yuǎn)超C、C的性能。