Visual Studio 為何沒有 64 位的版本？

01-04

單獨為每個子系統分別編譯一次貌似不是什麼難事

來自msdn blog：

Visual Studio: Why is there no 64 bit version? (yet)

主要觀點翻譯過來是：

為什麼現在沒有64bit的VS？

1、指針佔用空間變大，cpu的cache size不變，會帶來性能問題。
2、對VS團隊來說，移植到64bit最好辦法是把native code移植到managed code。但這樣成本太高。
對於一個IDE，與其移植到64bit以使用4GB內存，不如把精力花在優化內存使用上。
3、VS現有的extension都是32bit的，64bit需要重新建立生態系統。

把VS移植到64位的工作量很大，特別是對做過很多優化的程序，不是重新編譯那麼簡單。

不做64位IDE是工作量和性能的權衡。

如 @Belleve 所說，32位的VS能夠編譯64bit程序，並且有64bit的編譯工具，所以64位VS的好處僅僅在於可以載入和調試超大的工程。前者的情況較少，而且可以通過優化內存使用達到。

Cross debugging很難做。簡單的說，32位debugger，64位App，或者是64位debugger，32位App。解決辦法是做shim。但用戶體驗很差。profiling什麼的也有很多問題。不能為了64位而做64位，是吧？

x64 系統可以運行 32 位的 Visual studio，編譯器也同時支持 x86 和 x64 輸出，幹嘛多此一舉？x86 IDE + x64-支持的編譯器 + x64-支持的調試器足夠了。

詳情：How to: Enable a 64-Bit Visual C++ Toolset at the Command Line

如果是開發桌面程序的話，你就當交叉編譯好了，反正都差不多

我就題主的問題來解說一下，64 位 VS 並非象你想像的那樣只是再編譯一次就解決了。

目前移動端基本都還是 32 位的。作為開發平台，如果你要開發 32 位應用，就必須有 32 位編譯器，所以，如果要同時支持移動端開發，就必須在 64 位 VS 中同時提供 64 位跟 32 位編譯器。——但對於 32 位 VS 而言，只需要提供 32 位編譯器就夠了。——這意味著 64 位的 VS 需要比 32 位 VS 做更多額外的工作。更重要的是， 32 位 Windows 系統仍然活著，還佔據了主要地位。

實際上單就桌面應用來說，只提供 64 位沒什麼問題（除了部分對 64 位有著明顯刻板偏見的人群的心理因素以外），目前的 OSX 就已經是全 64 位，並未存在任何性能問題。但作為開發工具，移動端還沒有全部轉化為 64 位晶元的今天，移動開發又如此的火爆，那麼 VS 64 位版本就面臨著需要同時提供兩個版本的問題。這就會比只提供一個 32 位版本 VS 要複雜。

鑒於目前 Linux /OSX 都可以很完美的使用 64 位開發環境，所以，全 64 位開發環境在技術上自然完全是可行的，不可行的原因更多時候只是為了省事，換句話說就是偷懶。微軟只是現在還沒有安排好做這件事情而已，也許等時機成熟，自然就會做了。

普通的應用一般只有一個或很少幾個執行文件，Visual Studio的話則有上百個（大部分是各種小工具），只支持一種處理器架構就是很高的測試成本了，更何況有很多工具甚至是從Win16時代繼承過來的，使用的API沒有64位版。

首先，從性能的角度來看，64位需要龐大的指針，因此造成的數據結構更具規模，但處理器高速緩存大小保持不變的情況下，這容易導致運行速度變得極慢。舉個例子，好比你自己挖了一個洞，然後你通過使用額外的4G以上內存來把自己再刨出來然後繼續做自己要做的事情。在Visual Studio中，可能會存在一些大規模計算的解決方案，但我認為維護一個環境一個最好的tradeoff是只使用較少的內存。很多的VS的演算法是適合的。effectiveness和efficiency比fashion和fabulous要好得多。

下面列出64位的優劣：

from http://blogs.msdn.com/b/joshwil/archive/2006/07/18/670090.aspx
Pluses:
- more memory (+++++)
- better 64-bit math (+++)

- X64 OS kernel takes advantage of more memory to do good things for a lot of stuff (+++)
Minuses:
- things need more memory (pointers are bigger, and especially in managed code references are everything and are everywhere) (--)
- the processor"s cache is effectively smaller (when comparing against the same machine in 32-bit vs 64-bit mode) because of the prior point (----)
- code also tends to be bigger because of extra prefix bytes and instructions that carry around 8-byte immediate values instead of 4 byte immediate values

其次，性能問題，從成本的角度來看，如果要全部從已有的32位移植到64位，最短的路徑可以是先移植大部分保證增量開發的代碼，然後移植那些剩餘的，不是那麼重要的那些。然而本機代碼的完整移植的成本將是相當高的，而且當然所有已知的擴展將被破壞。我們還要創建一個64位的生態系統，這非常像你部署一次全新的64位驅動程序。f*ck。

更麻煩的，如果所有你想要做的是將64位的代碼移植而並非重新開發，最方便的路徑確實是直接點對點移植。但是，這種情況根本不可能！！！在實踐中，移植是有很大機會成本的，它與M￥ sorry不是，M$其他的業務競爭時間和資源。因此，情況是更可能是這樣的：微軟的32位C＋＋團隊說「我想要往裡添加一個OOXX功能，如果我基於已有的環境里開發新的，我可以更容易的做出功能OOXX，並且加上其他的東西比如OOOXXX特效，比如OOOOXXXX的連續自動化量產方案，這樣，OOOXXX，OOOOXXXX的成本就很低了「，這也是他們喜歡託管代碼原因。但現在，他們也有64位的一個path。在現實中就變成有是越來越多的Visual Studio版本而不僅僅是32和64兩種。

所以基於以上考慮，我感覺最好部署VS的方法就是微軟想出的策略，使用64位系統運行32位模擬模式的VS，這可以增加一倍可用空間而且不會導致空間問題，並且你也有了64位開發環境。

儘管如此，我知道肯定有很多用戶會更加受益於64位的版本，但其實，我覺得，更好的做法不是簡單的移植，而是努力優化IDE現有的結構，以圖可以更好地減少內存佔用。

下面回答一些更詳細的問題，

1. 移植成本高是不是因為老代碼質量差？

差的只是一小部分，VS太大了對於人類來說。而且大部分軟體包都不會有64位地址優勢。而且絕大部分的軟體演算法並沒有優化，更有甚者許多繼承了效率很低的代碼佔用了很大的空間，這不是微軟自己能解決的。所以移植成64位以後微軟也就要跟開發者們說拜拜了。

2. 64位程序出錯就會少么？page faults。。。

不是的，64位進程的地址空間反而會引起更多問題因為你數據塊多了，地址多了，很多棘手的問題就接踵而來。然而一個64位的系統則會使問題迎刃而解，假設你在一個64bit OS上運行一個32位程序，你得到的使整個4GB空間，即使你不是直接使用那些64位指針，操作系統自己會判斷。你的硬碟緩存會變得很小，即使你有很多其他程序也在運行。比如你的瞬態組件和數據都跑物理內存里了而非佔用地址空間。

增加地址空間的真正意義在於允許你分配更多內存，但如果本身已經適應了4GB地址的程序你再把它的指針加大，那問題就來了，你會發現它有多少內存吃多少。別忘了cache大小是不變滴。你也許會發現更大的地址空間允許你創建更少的分區，更多的共享空間，但是auto-relocates這個東西會做得更好。也許更多得指令集是移植得又一好處吧。所以移植的好處就僅僅變成當系統無法再適應4G了，但那個時候你是覺得這個系統還tm能用么？回去用UNIX算了。

有一些必須使用龐大數據處理比如「復共線性空間數據回歸模型挖掘」，那另當別論了。估計很少人會經常使用吧。所以即便只支持32位顯得不是那麼fashion，但是我們做產品要力求—— 簡，而非減。

3. 但為啥微軟很多其他軟體都傾向於部署64位？比如OFFICE2013...

首先，OFFICE的根本問題不應是確保新的代碼能運行的很流暢，而是要力求新的文件格式在新的代碼生成這些文件時候，要和之前的版本兼容，（之後的版本也是）。所以記住，現在的64位word就應當想到：「我有很多數據結構有了64位偏移」。畢竟幾乎所有的二進位文件格式都會有指針尺寸問題，然而Office已經解決了這一難題，使用了壓縮格式的XML，所以他們可能已經不用內嵌指針了。

其次，像是EXCEL之類的，很多處理文檔的人原因導入大於4G的data，但是想像一下你什麼時候需要讓VS也處理這麼大的數據呢？你如果處理那些大的分析系統，你就安裝一個64位的分析調試工具包即可。

One more thing，至今我還是認為32位系統已經足以適合各種開發和使用，64位儘管有那麼那麼多的好處，它根本上（用戶方面）把許多不應該存在的問題複雜化了，所以

你儘管用你的32位，讓別人說去吧。

如果是個彙編語言編譯器的話，本質上就是個二進位字串翻譯器，寫的英語代碼翻譯成32位二進位指令和64位二進位指令都行。理論上VS肯定也可以，如果.net虛擬機有64位的話。

通用…

關於 VS的操作系統系統，一直很迷糊。