新思科技（Synopsys）家的VCS，在半導體行業使用率極高，背景我們就不多說了。
對經常跑EDA或其他算力密集型任務的用戶來說，在深度掌握本行業業務知識及熟練運用常見EDA工具以外，通常還需要在技能樹上點上一門技能——IT，就是怎么（順利）使用機器把手里的任務給（高效）跑完。
他們的IT技能升級打怪之旅一般分為三個階段：
第一階段：單機單CPU核，單任務
第二階段：單機多CPU核，多任務
第三階段：多機多CPU核，多任務
據我們觀察，很多用戶都已經處在第二階段。
但是，依然有部分用戶尚處在第一階段，比如我們今天的實證主角。
我們之前的六篇實證都直接一步到位——上云后。
HSPICE │ Bladed │ Vina │ OPC │ Fluent │ Amber
今天我們看看上云前的幕后系列，又名：搬桌子的故事。
用戶需求
某IC設計公司運行EDA仿真前端設計和后端設計的分析任務，進行機電一體芯片技術的開發。現有機房設備較為老舊，共有8臺單機，需要同時服務數字和模擬兩個研發部門。
隨著公司業務的發展，相關部門負責人幾乎同時反饋業務峰值時計算資源嚴重不足，排隊現象嚴重。
實證目標
1、fastone平臺是否能有效提升VCS任務運行效率？
2、fastone平臺是否能有效提升本地機器資源利用率？
3、fastone平臺是否支持大規模VCS任務自動化穩定運行？
實證參數
平臺：
fastone企業版產品
應用：
Synopsys VCS
適用場景：
數模混合電路仿真
系統：
Red Hat Enterprise release 5.7（Tikanga）
實證結果
我們先來看看用戶自己跑20000個任務和我們來跑的效果：
大規模任務驗證 20000個任務
我們將本地機房的8臺單機構建為一個統一管理的集群，運行20000個VCS任務的時間是用戶自己所需時間的約1/50。
實證過程：
1、用戶使用一臺單機C1運行20000個VCS任務，耗時40485分鐘；
2、將本地機房的所有8臺單機構建為集群A，使用集群A運行20000個VCS任務，耗時809分鐘。
用戶按常理推斷，本地機房共有8臺單機，將所有機器一起來運行大規模VCS任務的時間大概應該是使用一臺機器機耗時的6-7倍（理想值為8倍，但由于存在長尾任務，存在一定差異）。
但實證中50倍的提升大大超出了他們的預期。
中間發生了什么？
回到我們開頭說的三個階段——
第一階段：單機單CPU核，單任務
單任務狀態下的單機單核，就是一個任務只在一臺機器上的一個CPU上跑。不管這臺機器其實有幾個CPU，反正就只用一個。資源利用率極其低下，可以說是暴殄天物。
再細一點，這里其實還有個1.5階段：單機多CPU核，單任務。效果類似。
假設給你幾個人（CPU核），完成一個叫做“搬桌子”的任務。
單任務的處理方式分為單進程和多進程：
單進程的處理方式是：
不管你有幾個人，同一時間永遠只有1個人在搬整張桌子，其他人在圍觀。
多進程的處理方式是：
先拆桌子。比如把一張桌子拆成4個零部件，分給4個人來同時搬，有的搬桌子腿，有的搬桌面等等，搬得最慢的人決定任務的完成速度。
但是，哪怕你有8個人，一次也只有4個人在搬。
搬完一張桌子再搬下一張，依次往復。
補充一個背景信息：2009年4月，新思科技就發布了VCS的多核技術，通過將耗時的計算處理動態地分配至多個CPU內核來突破芯片驗證的瓶頸，從而提高驗證的速度。
也就是說，應用十多年前就支持單任務多進程了，現在這個技術的名字叫Fine-Grained Parallelism，FGP。
第二階段：單機多CPU核，多任務
多任務狀態下的單機多核，就是多個任務能同時在一臺機器上的數個CPU上跑，受制于單臺機器的最大核數，目前最多也就96個核了。
我們繼續講“搬桌子”。
上一階段的多進程處理方式，存在一個明顯的問題。哪怕你有8個人，一次也只有4個人在搬。搬完一張桌子再搬下一張。
這就很不合理了。
于是我們在此基礎上改進了一下。
在你有8個人的情況下，一張桌子4個人搬，我們可以同時搬兩張桌子啦。這樣可以明顯加快任務的完成速度。
但是，單臺機器的總CPU核數就是上限了。
當然這一階段還是會存在一些問題，會出現有人突然跳出來跟你搶人或者你也搞不清楚哪些人現在有空來幫你。
因為資源使用的不透明和缺乏有序管理，會出現不同人對同一資源的爭搶，任務排隊等現象。同時，你會發現資源利用率還是不高。
不少用戶已經處在這一階段。
我們看看從第一階段到第二階段的實際VCS驗證效果：
應用并行化驗證
400個任務
對VCS進行多任務并行化處理后，一臺單機運行相同VCS任務的時間縮短為原先的15%-16%，極大提升了運行效率。
實證過程：
1、使用一臺單機C1（8核）運行400個VCS任務，耗時806分鐘；
2、使用一臺單機C2（8核）運行400個VCS任務，耗時793分鐘；
3、對VCS應用進行多任務并行化處理后，使用一臺單機C1（8核）運行400個VCS任務，耗時130分鐘；
4、對VCS應用進行多任務并行化處理后，使用一臺單機C2（8核）運行400個VCS任務，耗時122分鐘。
第三階段：多機多CPU核，多任務
多任務狀態下的多機多核，就是多個任務能同時在數臺機器的數個CPU上跑，這個我們稱之為集群化管理，一般都需要有調度器的參與。
關于調度器的相關知識，看這里：億萬打工人的夢：16萬個CPU隨你用
前面講到我們已經可以同時安排搬兩張桌子啦。
但其實，如果你的機器足夠多，人（CPU核）足夠多，你完全可以同時搬更多的桌子。
這個時候，必然要面臨一個如何調兵遣將的問題。
這么多機器，這么多任務，怎么順利一一配置、啟動、關閉，提高整體資源利用率，最好還能自動化管理等等。這就需要一點技術了。
至于云上資源的大規模動態化調度和管理，要更加高階一點。
在《生信云實證Vol.3：提速2920倍！用AutoDockVina對接2800萬個分子》中，我們最多調用了10萬核CPU資源對整個VS數據庫進行虛擬篩選。
當集群達到如此規模之后，手動管理是不可想象的。
而且云上資源跟本地不同，往往是個動態使用的過程，有時候甚至要搶。
更不用說還要考慮不同用戶在不同階段的策略和需求。
我們看看從第二階段到第三階段的實際VCS驗證效果：
集群化驗證
400個任務
由2臺單機構建的集群運行相同VCS任務的時間為單機的約60%，并實現了自動化資源管理。
實證過程：
1、使用一臺單機C1（8核）運行400個VCS任務，耗時130分鐘；
2、使用一臺單機C2（8核）運行400個VCS任務，耗時122分鐘；
3、將C1和C2構建為集群B，使用集群B運行400個VCS任務，耗時75分鐘。
最后，我們回顧一下，我們到底做了哪些事：
應用并行化：從單任務到多任務
fastone幫助用戶實現了應用并行化，可以充分使用一臺單機上的全部CPU資源，確保了最大的計算效率。
資源集群化：從單機到集群
fastone幫助用戶實現了集群化管理，讓多臺機器能夠并行化運行VCS任務，實現了數據、應用、資源的統一化管理。
規模自動化：從400個任務到20000個任務
用戶希望在面臨大規模VCS任務時，上述方案的穩定性能夠得到充分驗證。
fastone幫助用戶充分驗證了20000個VCS任務場景下，能夠自動化規模化地調度資源高效完成任務，滿足用戶需求。
到現在為止，我們成功幫助用戶從單機單任務單進程運行的階段大幅度跨越到了大規模任務自動化集群化運行階段。
萬事俱備，下一步，上云。
我們的前兩篇EDA云實證可以了解一下：
《從30天到17小時，如何讓HSPICE仿真效率提升42倍？》
《國內最大規模OPC上云，5000核并行，效率提升53倍》
本次EDA行業云實證系列Vol.7就到這里了。
下一期的EDA云實證，我們聊Virtuoso。
請保持關注哦！