正在載入軌跡
—
分子動力學引擎
把 23,558 個原子
推進兩飛秒，要 3.325 毫秒
你看到的是 DHFR 這顆酶在顯式水裡的真實軌跡。它由一支自製的 CUDA 引擎在 RTX 3080 上算完， 瀏覽器只負責播放——物理發生在那張卡上，不在這個分頁裡。
3.325
毫秒／步
23,558 原子、2 飛秒、含 PME 與剛性約束
5.98×
落後同卡 OpenMM
起點是 12.4 倍，三刀之後收到這裡
52.0
奈秒／日
同一張卡、同一組設定
0.0144
kJ/mol/ps 守能漂移
一奈秒長跑；OpenMM 同設定是 0.0221
排序是量出來的，不是猜的
兩個外部審查一致指認「生產路徑上的雙精度 PME」是最大的效能缺陷。把逐段計時做出來之後， PME 全部六段加起來只占每步的 6.6%；真正的大頭是兩邊都沒提到的鄰居表建表，占 43%。
照量到的順序下了三刀，每步從 6.872 毫秒收到 3.325 毫秒，而且三刀全部 逐位元不改變輸出——重跑的力場比對證據對已提交的數字每一欄都相同。
| 段 | 起點 | 現在 | 占比 |
|---|---|---|---|
| 直接空間 | 2,471 | 1,362 | 39.5% |
| 鄰居表建表 | 2,994 | 572 | 16.6% |
| PME 倒空間 | 458 | 458 | 13.3% |
| 鄰居表 cell 排序 | 229 | 245 | 7.1% |
| 剛性約束投影 | 398 | 399 | 11.5% |
| 合計 | 6,872 | 3,325 | 100% |
單位微秒／步，攤平到整段跑。
另外兩個看起來該有效的改動，量出來是 0%，已經還原：把約束叢集的區域陣列縮小， 以及讓相鄰執行緒處理空間上相鄰的原子。兩次實測反駁讓下一刀的方向變得清楚—— 直接空間卡的既不是雙精度、也不是記憶體聚集，而是平行度。
這段軌跡自己的能量
下面這條線是你正在看的這段軌跡的總能量，逐幀從引擎讀出來的。NVE 系綜裡它應該守恆， 所以線的平坦程度就是積分器的誠實度。
短跑的斜率是隨機漫步噪音，不是長期漂移——同一個系統 4 皮秒量到的斜率比 1 奈秒大兩個量級。 上面那個 0.0144 的守能數字來自五十萬步的長跑，不是這段。
為什麼不是把引擎搬進瀏覽器
瀏覽器碰不到 CUDA，這是結構性的：頁面無法載入原生程式碼，而網頁的 GPU 介面必須驗證所有輸入 才送到驅動。剩下的選項是把運算核心改寫成網頁著色語言，而那條路卡在正確性而不是速度。
網頁著色語言沒有雙精度浮點數，規格全文一次都沒出現；而這具引擎與參考實作的對齊， 建立在雙精度的最小鏡像上——把盒長降成單精度，實測每顆原子的力會差 0.18 kJ/mol/nm。 常見的替代方案是用兩個單精度數模擬一個雙精度數，但那套演算法依賴運算不被重新結合， 而規格明文允許實作重新結合。
六十四位元的定點累加倒是有解，可以用兩個三十二位元原子操作加進位精確模擬，逐位元可重現性保得住。 卡死的只有雙精度那一項。所以這頁的做法是：計算留在卡上，瀏覽器拿到的是它的輸出。