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

提到人工智能，為什么總會說Python？

是因為腳本語言寫下來很簡單容易。

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

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

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

兩者共同牛叉的特點恰好是對方的特點。

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

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

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

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

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

然后再拎著這個指針又接著能去不能訪問對象的MethodTable。

再有你還可以不手動啟動在棧上分配空間：

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

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

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

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

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

甚至于那樣：

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

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

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

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

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

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

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

也可以看看在X86平臺上生成了什么代碼：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

除此之外，我們又能在運行時重新指定GC的模式來最大化性能：

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

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

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

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

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

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