@mxT52CRuqR6o5 “少数“不等于“基本不用“。

@mxT52CRuqR6o5
第一我针对的是”因为后端一样，所以性能一样”的逻辑
第二，现在 Chrome 和 Firefox 都支持了 WASM 的多线程和 SIMD，楼主想做的不一定不能做。白学文章的结论是“多了一种在性能、开发成本和效果之间权衡的选择”，你这“基本不用”，我也不好说😅

我用同一个帐号，在 iPad 上需要翻两三页才看到大量这个站群的结果，在 PC 上一突开就满脸都是 ... 看起来 Google 在这种奇怪的地方下了不少功夫
另外对于用户来讲，这个最好的手段应该是在服务器端把结果过滤掉，就不会出现“过滤之后首页根本没有结果”的现象了，不过 Google 貌似没有直接提供一个域名的全局黑名单。最骚的是这个站对“-知识网 -百科网”的关键词完全免疫，观察之后，用“-上一篇”把它干掉了（明明“百科网”在标题和正文里面都有，可能 Google 给文本分了词？虽然其实中文不需要这么干）。不过这个关键词居然貌似没有误伤 CNBlogs 。

对于这个关键词（“c 语言二进制输出 -上一篇”）来讲，我的搜索结果中唯一值得关注的只有 CNBlogs，其实还有 CSDN 和百度知道的不少结果，但是这种结果会不会仔细去看就是个人喜好了。不过我最希望 Google 给出的其实是这个：
https://zhihu.com/question/438434182/answer/1699713812 C 语言中为什么没有直接提供二进制数的输出？ - 暮无井见铃的回答 - 知乎 看到 jajuju 的这个答案，我这个实验就算没白做。
可惜在 Google 给出的一共不到一百个结果中，并没有这个结果（只有个知乎专栏的），好消息是如果你 site:zhihu.com 的话还是能找到的，我就是这么找到的。可见结果权重排序基本是乱的。

从实际的角度来说，要想最大限度地“净化”搜索结果，那么应该可以搞一个白名单，Google Custom Search 貌似是可以这么做的，把 reddit.com wikipedia.org zhihu.com bilibili.com youtube.com bbs.nga.cn v2ex.com chiphell.com 等一干网站加进去就行了。这几个差不多 cover 了我需要的简体中文内容的一大半，另外还有百度贴吧，百度的结果明显比 Google 要好，这个没救。
（我注意到 Google 还喜欢：对于同一个域名的结果，只显示他认为最 relevant 的，剩下的不给你看，或者有但是在二级页面里而不是全给你直接列出来。如果中文网络内容确实如此中心化的话，在 Google 这种策略下域名白名单反倒是更优的选择）
这么搞有一个直接的缺点就是干掉了所有的独立博客，这个是没法穷举的。但是我发现好像就算不加任何过滤，中文独立博客的结果也很有限，所以直接大网站白名单好像也不会差太多。
一个典型的例子是，刚才那个关键词几乎没有来自 github.io 的结果。但是单独 site:github.io 的话可以发现并不是没有有用的结果（虽然不多，大概是被“-上一篇”给干掉了）。鉴于确实有不少人往 github.io 上放博客，所以独立博客作者可以考虑往 github.io 上扔个副本然后链到主站，这样不需要审查，也算是间接 SEO 。

那么有没有正经的，“WASM 与所谓‘写的好一点’的 js”之间的对比呢？
www.sable.mcgill.ca/publications/techreports/2018-2/techrep.pdf WebAssembly and JavaScript Challenge: Numerical program performance using modern browser technologies and devices 这篇文章对比了同一套数值计算 benchmark 在 C 、WebAssembly 和 JavaScript 等不同平台下的性能，结果性能提升普遍在 1.5 到 2 倍之间。
当然，可以 argue 这个 benchmark 里面的 JS 并不是“最优化”的 JS （这个 JS 代码是他们重写过的，用了 Typed Array 之类的优化），真正“最优化”能做到什么程度呢？

这就要说回刚才那个答案了，答案回复里引用了一篇文章，干货比答案本身那是多得多： https://zhuanlan.zhihu.com/p/102692865 一个白学家眼里的 WebAssembly （以下称为“白学文章”，因为实在是浓度过高 ...）
这个文章声称：“只要你懂得如何让 JS 引擎走在 Happy Path 上，那么在浏览器里，JS 就敢和 Rust 五五开。”
这里有个前提“JS 引擎走在 Happy Path 上”，这个的难度我前面说过。另外，在这篇文章的上下文中，Rust to WebAssembly 貌似无论是在文件大小、工具链完善程度和运行时性能还是上都没有 C to WebAssembly 更好，也就是换 C 可能就是四六开了 :)
精彩的是这个 claim 后面的证据，这是来自 Firefox 和 V8 两家浏览器引擎官方的内卷成果：

https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly Oxidizing Source Maps with Rust and WebAssembly 这个作者 Nick Fitzgerald 应该是专门搞 Rust 和 WASM 的，立场应该有一定偏向。这篇文章是讲通过把 source-map 这个包里的 hot code 改成 使用 Rust 编译成的 WebAssembly 实现，在作者定义的一组 benchmark 上实现了成倍的性能提升。文章不短，不过主要是介绍 source-map 这个库，介绍 WASM 以及怎么用，怎么做 WASM 和 JS 之间的 binding，以及 benchmark 的结果。
前 V8 开发者 Vyacheslav Egorov 看了之后就写了一篇 https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html Maybe you don't need Rust and WASM to speed up your JS，他声称自己不站队，只是对优化感兴趣。这篇文章同样不短，全文大部分都是关于他怎么做的优化，包括：
1. 通过使用一个“*almost* default x64.release build of the V8”——也就是他重新 build 了一个 V8 来方便自己做分析，对 V8 引擎进行 profile，发现函数调用的时候 arity 不匹配或导致性能损失，改掉之后提升了一些性能。
2. 通过手动进行 monomorphisation，提升了更多的性能。
3. 通过分析发现原来包里中加入的 cache 并没有必要，删掉之后又提升了一截性能。
4. 把原来包里的内置排序算法改成桶排序，又是一截。类似的还有去除不必要的排序，并把快排换成插入排序。
5. 通过手动模拟静态类型语言的内存布局，优化 GC 。
6. 使用 Typed Array 继续优化（这个貌似需要重写整个逻辑，作者没有真的去重写只是预测了一下性能）。
做完这一切之后——V8 下性能差不多是刚才的 WASM 版本的 1.3-1.6 倍，而 SpiderMonkey （ Firefox 的 JS 引擎）下面的性能差距要小一点。
注意这六个主要优化中，1 是 V8-specific 的，这需要你了解 V8 的实现细节，3 和 4 是对程序算法本身的优化，和使用什么语言没有关系。2，5，6 则是 C/C++/Rust 等静态类型语言的语言特性自身就有的，而为了在 JS 中“模拟”这些特性，你需要这么写代码： https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html#optimizing-parsing---reducing-gc-pressure
之后 Nick Fitzgerald 又单独发了一篇文章： https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html Speed Without Wizardry 先吹了一下 Vyacheslav 的 expertise 和文章本身的质量，然后解释了下啥叫“wizardry”，最后把上面的 3 和 4 也在 WASM 版里面实现了，最后结果就是那个白学文章里面那个图：JS 和 WASM 在 V8 上完全打平，而在 SpiderMonkey 上，WASM 依然有明显的性能优势。

Nick 最后那篇文章有点阴阳怪气的意思，简单来说：但是，古尔丹，代价是什么呢？
标题的意思就是 Vyacheslav 的优化有一半属于“wizardry”，而使用 WASM 则完全不需要。他还特地摘出了 GC 优化那段，用 Vyacheslav 自己的话（“verbose and error prone code”）嘲讽了一番，然后大大的字体把 Vyacheslav 的代码 “memory[mappingA + 3] - memory[mappingB + 3]” “memory[mappingA + 4] - memory[mappingB + 4]” ... 贴出来。
（当然，他没有强调这代码之所以写成这德行，部分原因是照顾 SpiderMonkey 优化的一些短板）
他最后说：
> But a distinction between JavaScript and Rust+WebAssembly emerges when we consider the effort required to *attain* inlining and monomorphization, or to avoid allocations. Rust lets us explicitly state our desires to the compiler, we can rely on the optimizations occurring, and Rust’s natural idioms guide us towards fast code, so we don’t have to be performance wizards to get fast code. In JavaScript, on the other hand, we must communicate with oblique incantations to match each JavaScript engine’s JIT’s heuristics.
并且他同意 Vyacheslav 说的：
> Obviously each developer and each team are free to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend M hours rewriting their stuff in a language X.
实际上，Vyacheslav 所做的优化，已经接近于重写代码了，我不认为这是“写的好一点”的问题。
这些具体的问题，那篇白学文章并没有细讲，白学文章自己推导出一个结论，就是“WASM 主要是方便把更复杂的原生应用直接搬进 Web”。其实完全不需要，WASM 自己的官方 paper （来自各大厂商的一线实现者） dl.acm.org/doi/pdf/10.1145/3062341.3062363 Bringing the Web up to Speed with WebAssembly 就明确指出了
> The initial version of WebAssembly presented here focuses on supporting low-level code, specifically compiled from C/C++.
也就是设计上就不是让你从 JS port 过去的。之后才是
> A highly important goal is to provide access to the advanced and highly tuned garbage collectors that are built into all Web browsers, thus eliminating the main shortcoming relative to JavaScript when compiling to the Web.

而在折腾了这么半天之后，JS 版在 SpiderMonkey 上终究还是没打过 WASM 。吊诡的是哪怕 JS 版的性能，貌似 V8 也没打过 SpiderMonkey，证明 V8 并非是上天入地无所不能天下无敌的神器。
Vyacheslav 还有一些观点 Nick 并没有提：
* 他认为像上述 1 一样的 V8 的坑会越来越少。我个人对此不是很乐观，主要是在工具层面，而不是语言层面解决，依然是治标不治本的“wizardry”。
* 当然他也提到了从“language features”和“tools”层面一起解决。因为他也强调“Language and Optimizations Must Be Friends”，不是什么语言都可以随便优化的。
* 而其他的优化是“universal knowledge that spans across implementations and languages”，其中算法优化自不必说，而至于 JS 和 WASM 的对比，他没有给结论，只是用“N”和“M”一笔带过。并且强调“你都可以选择”，以及“language designers and implementors”都要加油奥利给。
* 以及“Clever Optimizations Must be Diagnosable"——对于 JS 引擎自身的 magic，浏览器并没有提供任何易用的接口，开发者基本没法知道我这个代码是不是什么地方惹 JS 引擎不爽了——应该不是每个前端开发者都会自己 build 一个 V8 的吧。这方面传统编译器反而做得要好得多，以 Clang 为例，最简单地，用户可以生成 optimization report 查看重要的优化有哪些做了哪些没做，再进一步可以查看生成的 LLVM IR 和 汇编，还可以看 IR 在每一个 pass 中的变化。GCC 和 Clang 传统编译器通常还会加入大量的 option 和 extension 方便性能优化。

这个涉及另外一个问题，就是通常 WASM 就是由某种形式的“传统编译器”生成的，这个编译器一般自身就是一个优化编译器。也就是说某种程度上讲，WASM 其实在编译器层面比 JS 更优越——它既有 V8 的婆罗门优化，又有传统编译器的刹帝利优化。之前说到 JIT 优化的不确定性，类似的问题在传统编译器中同样存在，区别是总的来说传统编译器做优化一般更容易，开发者可以访问更多优化的信息，并且实际性能受运行时情况的影响更小。总的来说 WASM 依然能够提供更好的 predictability 。

最后，在 V8 中，JS 和 WASM 都是通过 TurboFan 后端编译，但是在 SpiderMonkey 中，情况也是一样的。SpiderMonkey 的资料更少，但是其官方文档 https://firefox-source-docs.mozilla.org/js/index.html 说明，SpiderMonkey 最高级的 JS 后端，原来叫 IonMonkey，后来叫 WarpMonkey （最近改的名，其实 SpiderMonkey 这么多年已经养了一堆的猴儿了），但是 IR 还是叫 Ion MIR 和 Ion LIR 。而其最高级的 WASM 后端叫 BaldrMonkey，或 WASM-Ion，是“translates the WASM input into same MIR form that WarpMonkey uses and uses the IonBackend to optimize”。“IonBackend”具体指代什么不明，但是 IR 是一样的 IR 就基本是一样的后端。在 SpiderMonkey 的 WASM 实现源码中（ https://searchfox.org/mozilla-central/source/js/src/wasm/WasmIonCompile.cpp#5824 ）一些关键模块，如 js::jit::OptimizeMIR 同样在 JS 编译时使用（ https://searchfox.org/mozilla-central/source/js/src/jit/Ion.cpp#1577 ）。https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/spidermonkey.md 这里明确说 SpiderMonkey 中 WebAssembly 使用“IonMonkey-based tier 2 compiler”。前面提到的 WASM 的 paper，也包含了实现部分，是这么说的：
> V8 (the JavaScript engine in Google’s Chrome), SpiderMonkey (the JavaScript engine in Mozilla’s Firefox) and JavaScriptCore (the JavaScript engine in WebKit) reuse their optimizing JIT compilers to compile modules ahead-of-time before instantiation.
> The baseline JIT is designed only for fast startup while the Ion optimizing JIT is compiling the module in parallel in the background. The Ion JIT is also used by SpiderMonkey as its top tier for JavaScript.
> V8, SpiderMonkey, JavaScriptCore, and Chakra all include optimizing JITs for their top tier execution of JavaScript and reuse them for maximum peak performance of WebAssembly.
> Our experience reusing the advanced JITs from 4 different JavaScript engines has been a resounding success, allowing all engines to achieve high performance in a short time.
其实并不难理解，编译器本身差别并不大，既然已经有了一个非常不错的编译器，就没必要再写一个了。

最有意思的是把这个和之前的测试结果结合起来看：SpiderMonkey 同样给 JS 和 WASM 使用了一样的后端，然而这俩的性能确实差出了一截，可见一个语言的性能和编译器后端是啥根本就没有必然联系。

@mxT52CRuqR6o5
这个答案说的是“如果你的应用不是非常计算密集”，“加上 js 和 wasm 之间通信的额外消耗”，并且不“使用其他的高级 的 wasm 特性”，#28 直接就说“wasm 其实是最没用的”是不是太快了点？

另外，“chrome 里 wasm 的和 js jit 用的同一个后端”其实是很正常并且意料之中的事情，但是“因为‘chrome 里 wasm 的和 js jit 用的同一个后端’，所以‘js 写的好一点和 wasm 的运行效率是一个级别的’”这个逻辑是不通的，这一点原来的答案犯了错误。我理解原答主是想 debunk WASM 的 myth，但是这个部分是纯粹的 misinformation 。总体来说答案本身质量一般（不仅存在逻辑错误，也缺乏足够的数据和细节），但是里面的链接好东西不少，这个等会细嗦。

首先，性能是个非常复杂的问题，而编译器只是其中的一环，不能简单以粗暴的编译器比较来确定性能。几个例子：
* Rust，Julia 的官方实现都使用 LLVM 作为后端，而 Haskell 也有个 LLVM 后端，那么能说 Rust，Julia 和 Haskell （使用 LLVM 后端）的性能是一样的么？更直接的一个例子是，Safari 的 JS 引擎 JavaScriptCore （ JSC ），以前有个 FTL 模块，就是把 JSC 接入 LLVM 后端，那么能说 JavaScript （在 JSC 引擎上）和 Rust 的性能是一样的么？
* GCC 和 Clang 使用了完全不同的后端实现（ GCC 是自己写的后端，Clang 也是 LLVM ），然而总体性能却差不多。
* 编译器本身就是个非常复杂的问题，就算限定到 WebAssembly + LLVM 的组合，https://00f.net/2021/02/22/webassembly-runtimes-benchmarks#battle-of-the-llvms 这里有一个不同 WASM runtime 的 benchmark，其中的“Battle of the LLVMs”一节展示了若干个不同的基于 LLVM 的 runtime 的测试，可见同样是 LLVM 后端，性能也存在不小的差异。

“因为编译器后端一样，所以性能一样”这个逻辑的问题是，如果从编译器的角度考虑性能问题的话，简单来说分三个部分，第一个是给编译器的输入，第二个是编译器本身，在传统编译器中，这两个唯一确定了编译器的输出（ JIT 编译器需要加上一些运行时数据，不过简单起见可以认为已经跑到了最优化的程度），第三个是编译器的目标（目标硬件，目标语言+编译器的组合，或目标 VM ）。
对于 V8 引擎这个问题来说，编译器本身不变，编译器目标无法控制，所以主要就在输入上。也就是要想做到性能一样，就得做到给编译器的输入一样。而做到这一点很难，最根本原因是 JavaScript 本身并不是适合写高性能应用的语言，WASM 则更多地考虑了性能。
举个例子：很多编程语言的 primitive value 涉及到了 boxing，而 boxing 会影响性能。编译器通过优化，可能能把很多 boxing 优化掉，从而在这一方面做到和没有 boxing 的语言类似的性能，但是第一编译器不保证一定有 boxing 的优化，第二就算编译器有 boxing 优化，也不保证一定能把每个 boxing 优化掉。而如果一开始就使用没有 boxing 的语言，就根本不存在这一问题，一定是保证没有 boxing 发生的。
这只是一个简单的例子。很多语言，特别是 Tracing GC 语言中，类似的情况很多。而我刚才说过编译器是个非常复杂的东西，有可能有哪个条件没有满足，优化就不会发生。现在人类的高质量 JIT 优化编译器，比如 V8，可能确实能优化掉大部分的 boxing，但是只要 hot code 中恰好有一个地方没有优化掉，性能就下去了。而就算简单的情况能够优化，复杂的情况可能也难以优化。（另外，编译器优化复杂性的来源之一是，一个优化经常会依赖于之前的优化，也就是“前面的优化为后面的优化创造更多的机会”，而一步错了就意味着后面的相关优化都会受到影响）
V8 在优化 JS 方面确实很强，但这也意味着它优化 WASM 并不会更差，也就是 WASM 至少能提供更强的保证。WASM 给编译器的输入通常是比 JS 更优质的输入。更多需要考虑的是 JS 和 WASM 交互的 overhead 之类的问题。

说白了，没人瞧不起 V8，瞧不起的是，并且只是 JavaScript 罢了。
这也是编译器开发者的无奈——编译器开发者对自己的产品有完全的自由，然而对其输入和输出却缺乏控制力，输入是语言标准定好的，输出是硬件 ISA 标准定好的，夹在中间两头受罪。
不过现在问题并不这么简单，因为很多编程语言标准委员会的成员，自己就是该语言编译器的开发者，也就是说*某些*编译器开发者是有能力影响编程语言标准的。同样地，通过某些渠道（比如处于同一公司，或者通过各种公开或私下的反馈），编译器开发者也可以影响硬件，虽然流程可能会复杂很多？这一定程度上改变了编译器尴尬的定位，但是没有改变编译器本身的性能高度依赖于输入和输出语言的表达能力的根本逻辑——编译器开发者为了提高编译器性能而试图改变编程语言和硬件的设计这一现象，反而恰恰证明了该逻辑的正确性。
一个典型例子是 ES5 的 use strict，这里 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode 提到了该功能“Fixes mistakes that make it difficult for JavaScript engines to perform optimizations”，ES5 fix 了一些，不代表 ES5 没 fix 掉的就不需要 fix 了。
更具体的我在 https://v2ex.com/t/632869#r_8401400 讨论过一些。

当然，上面只是纸上谈兵，没有实际的数据，这里有几个例子：

首先是 WASM 的前身，asm.js 和 WASM 的对比：
www.usenix.org/system/files/atc19-jangda.pdf Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code 这篇文章把 SPEC CPU benchmark，使用 Emscripten 分别编译到 asm.js 和 WASM，在 Chrome 和 Firefox 两个浏览器上跑，同时结合 native 运行测试进行对比，结论是 WASM 版本的运行时间平均是 native 的 1.5-2 倍，而 asm.js 版本的运行时间平均是 WASM 的 1.3-1.5 倍。
pspdfkit.com/blog/2018/a-real-world-webassembly-benchmark A Real-World WebAssembly Benchmark 这个则是把 PSPDFKit 这个 native 库，编译到 WebAssembly 和 asm.js （这个貌似有一定 impact，各大浏览器后来都针对这玩意做了一定优化，V8 更是直接在 blog 中引用了这个 benchmark ），然后再做 benchmark，这个可以直接在线跑。这个 workload 的结果貌似是，直到目前为止，Chrome 上 WebAssembly 和 asm.js 之间的性能并没有拉开明显差距。

有意思的也就在这：注意这两个例子都是 asm.js 和 WASM 的对比，这两者本质上其实都是差不多的东西（就是作为其他语言的目标 IR ）。这并非我们想要看到的，WASM 与所谓“写的好一点”的 JS （即大多数 JavaScript 原生程序所实际使用的语言）的对比——asm.js 虽然看上去是 JS，但是压根就不是人写的 JS，而是精简掉 JS 中大量对性能不友好的特性之后的子集。特别是 PSPDFKit 这个狗东西，它占了 “iswebassemblyfastyet.com”，并且 claim 自己是在 WebAssembly，和 “JavaScript version of PSPDFKit”之间做对比。这对于我们要讨论的问题来说是有些 misleading 的。
但是，从 SPEC CPU 的结果中可以发现，哪怕是类似的两个东西（有理由相信 V8 中 WebAssembly 和 asm.js 用的也是“同一个后端”），性能同样可以有不小的差别，这就是因为编译器的输入不一样。

还真不一定有搞头，Wine 现在做得很不错，把 Wine 不能用的排除掉之后有可能就不会有“长时间使用”虚拟机的情况了。

真不一定小，模板一 monomorphize 教你做人

顺便可以看看这个 https://www.youtube.com/watch?v=b0zxIfJJLAY

@mxT52CRuqR6o5
> 因为 chrome 里 wasm 的和 js jit 用的同一个后端
来源请求

有点像 C++ 的 name mangling

楼主不如跟这位老兄认识一下：
https://v2ex.com/t/801641 仔细想了想，所谓 "尊贵会员" 独享功能，不过是开发好的接口拒绝普通用户使用

中转我倒觉得没啥，我记得 Steam 和 Telegram 都有中转页，如果能从根本不让用进化到中转，至少算是和国际接轨了。

实际上大多数常用的语言实现前端用的都是手写递归下降。原因无非就是方便 hack，灵活。
不过也有例外，比如 OCaml 和 Haskell 貌似都是用的自家的 generator 。
自己玩可以用 parser combinator 。所以你把这块绕过去也无所谓，后面有的你看。

编译方面最牛逼的书私以为是 Optimizing Compilers for Modern Architectures，这书能让你了解最牛逼的那些编译器（传统意义上）都在做些什么。

如果我到时间升级到新版 JDK 还需要收费么？
如果不需要的话那就有逼人升级的成分了，这样我巴不得所有 JDK 全都这么干 :)

评论比主题有趣系列 ...

https://github.com/ice1000/CompilerWorks

虽然 outdated & incomplete 但是还是可以参考一下。

Teams 好用么？

@ysc3839 细节我肯定不知道，Windows 上的细节更不知道。
Linux 上的话倒是可以看看 Mesa 里面的 PRIME 实现。

这是 Optimus 的 whitepaper https://aps2.support.emea.dynabook.com/kb0/TSB2803DK0000R01_Optimus_Whitepaper_FINAL.pdf

当然文档是十几年前的了，不过总体架构应该不会有大的改变。跟 VirtualGL/Primus 干的事情差不多，就是显示输出接 iGPU 上，但是图形 API 指令发到 dGPU 上渲染，渲染完了再把结果通过 PCIe 传回来。
理论上软件可以实现，硬件和软件的主要区别应该在于性能，比如软件只能利用现有 API 做各种 hack，而硬件实现的数据传输可以更快。

另外我的理解，无论硬件还是软件，很多用户看上去很 magic 的东西，核心思想都不难，想通了关键点就能做出原型。当然 devil is in the details，具体做成产品是另外一回事。比如某款芯片新版本把缓存增大了多少多少，因此提升了多少多少性能，外人看起来很简单，但是做的时候从“怎么提升性能”出发，到“加多少缓存能提升多少性能”，“加缓存理论有用但设计上能否实现”“加了缓存会不会影响其他指标”之类会有一堆问题。

当然最后发布的时候，就会挂上一堆 marketing 的黑话，外人看上去就很牛逼的样子，感觉“我们香蕉真是太厉害啦”。但是如果其他家不缺实现的基本能力和钱的话，没必要直接“共享”技术细节。当然 A 可能一开始没想到这个 idea，不过 NV 的 whitepaper 已经把关键点说出来了（实际上远程渲染老早就有，应用到本地多 GPU 上是不是 NV 第一个就不知道了）。

所谓切换显卡的功能，台式倒不是完全没有。

这东西用 NV 的黑话叫 Optimus，Linux 社区叫 PRIME （ NV 一开始应该就在玩 Transformers 里面的梗）。原本 Linux 可以通过社区搞的 bumblebee （就是上次热情帮用户 rm -rf /usr 的那个）来“模拟”，所谓模拟就是在 dGPU 上开一个 X server，拦截 GL 调用放到那边执行，再把结果读回来显示。这个一直能用，虽然不是官方解决方案（并且不支持 Vulkan，虽然后来有另一个项目做 Vulkan 的）。官方的是在大概 450 驱动的时候，加了 PRIME 的支持。根据文档 http://us.download.nvidia.com/XFree86/Linux-x86_64/470.63.01/README/primerenderoffload.html 并没有提到需要 laptop，只是要“systems with both an integrated GPU and an NVIDIA discrete GPU”。

OpenGL 程序是通过 GLVND 实现的（因为 OpenGL 标准只告诉你怎么和设备交互，没告诉你和*哪个*设备交互，也就是说执行你 OpenGL 调用的可能是只母猪，或者是个土豆），在我这貌似不太稳定。跑 glxgears 十次有七次能跑，两次 crash，一次黑屏。自己写的 GL 程序也差不多，游戏没找到能跑的。
Vulkan 自己有选 Device 的功能，好像直接就选到 dGPU 了，可能有些程序自作多情，觉得我比用户牛逼别教我写程序，帮你选了，也可以通过设置 VK_ICD_FILENAMES 改回来。我这 Vulkan 的 PRIME 出奇的稳定，并且完全可以和 DXVK 一块用。

如果你用 Valve 的 Proton 跑游戏的话，新版本 Proton 中以上全部无效，因为较新版本的 Proton 用了 pressure-vessel 容器，会把所有安排全都搞乱，官方回复是这种 scenario 太复杂没法支持。不过官方提供的不用 pressure-vessel 的最后一个版本（ 5.0 ）也不是太老，还很能用。
由于 Linux native 的游戏大多没 Vulkan 支持（ V 社给 Portal 做 Vulkan 支持还是用 DXVK 做的 ...），在这种设定下，除了星露谷这种根本用不上 GPU 之外的游戏之外，最佳的方式居然是用 Win 版+老版 Proton+DXVK+官方 PRIME ...

另外还有一点就是为什么要折腾这么麻烦，因为我只有一个 PCIe 槽，但是遇到 Proton 搞不定的情况要开虚拟机 ... 所以必须蹭 iGPU （大部分 AU 和 F 版都不行），并且 host 显示输出只能接 iGPU 。不过本来如果只挂 nvidia 模块用 bumblebee，就可以在需要的时候把卡卸掉给虚拟机用，用完再挂回来。如果使用官方 PRIME，需要额外挂载 nvidia_modeset 模块，好像之前有一段时间也是可以这么干，但是由于我是该死的 Arch Linux 用户，貌似在升级了一次之后就只能挂上去不能卸下来了 ...

为什么有独显还要用核显？