secondwtq 最近的时间轴更新
secondwtq

secondwtq

V2EX 第 81805 号会员,加入于 2014-11-16 03:41:33 +08:00
今日活跃度排名 2702
《命令与征服》重置版将以 GPL 3.0 协议开放部分源代码
  •  1   
    Steam  •  secondwtq  •  2020-05-23 03:58:16 AM  •  最后回复来自 Nathanzheng
    6
    又到了让诸位 V 友做人生导师的时候了,关于要不要读研。
    职场话题  •  secondwtq  •  2017-04-22 13:39:18 PM  •  最后回复来自 cpygui
    79
    请教几个关于订票网站的设计问题
    问与答  •  secondwtq  •  2016-01-05 15:22:59 PM
    日经一下, Google 首页改版了?
    分享发现  •  secondwtq  •  2015-09-03 00:18:11 AM  •  最后回复来自 acess
    29
    求推荐一款适合折腾的无线路由器
    问与答  •  secondwtq  •  2015-05-16 09:32:34 AM  •  最后回复来自 Dreista
    14
    secondwtq 最近回复了
    5 小时 35 分钟前
    回复了 jdz 创建的主题 C++ 想买好的 cpu 来做编译用,但是编译又是偶尔才编译一次,纠结
    E5 最后一代产品 v4 顶配貌似是 22c ...
    如果是 Scalable 的话,我一个朋友很好奇“2100 的双路 6152”是哪里买的 ...
    5 小时 42 分钟前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    ***本回复不是给 #28 #30 #33 #34 #36 #37 #40 #41 看的,而是给通过 V 站站内通知、Google 等不同渠道来的有缘人看的***

    不是刻意要“抠字眼”,解释下我为啥以 2 作为普遍的“级别”的粗略定义:

    考虑工资 6k 和工资 8k 的两个人,可以勉强说这两个人的工资是一个级别。工资 6k 和工资 60k 就明显不是了。10 是一般意义上的“数量级”单位。但是在很多情况下这个单位都太大了。工资 12k 相对于工资 6k,已经是“一个级别”的边缘了。同样的规律可以应用在价格上。
    孙子兵法更有意思“十则围之,五则攻之,倍则分之,敌则能战之,少则能逃之,不若则能避之”,,看起来其对于军队数量级差距的定义在 2-5 倍之间,而 10x 在这套标准中已经是顶级的碾压了。
    2 对于程序员来说是比较习惯的选择,我认为也是比较合适的选择。某些时候可能显得有点小,不过无非就是原来的一个数量级变成了现在的 3.3 个数量级。
    意大利有 60M 人口,尼德兰有 17M,这俩也就 3.5 倍的关系,但无论如何不能说是在一个级别上。
    我现在用的显示器是 2560 × 1440 的分辨率,相对于 1920 × 1080 的屏幕是 1.78 倍像素点,而 1920 × 1080 相对于 1280 × 720 是 2.25 倍的像素点,两个比率都在 2 倍“左右”。实际用过的大概知道,这三种分辨率用起来完全不是一个级别的体验。
    一般做性能优化,除去明显的低级错误后,各种 trick 提升的天花板也就是 2x,再往上就要靠并行和程序本身算法优化。但是不考虑实现方式和 KPI 好不好看,作为用户来讲,大量数据占用存储减半,复杂页面加载时间减半,能耗减半,模拟迭代速度速度翻倍,多媒体处理或游戏帧数翻倍,数据传输速率翻倍,这些都是能明显感觉到的东西——实际上对于很多比较成熟的系统做到这些都非常不容易,但是如果做到了,使用体验是超出一个级别的提升。所以我对性能问题的“数量级”定义是低于 2x 的。
    6 小时 22 分钟前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    @mxT52CRuqR6o5

    > 起码 5 倍差距以上吧,不然 O(n)和 O(2n)都不算一个级别了
    你都加 大 O 了常数项还有意义么 ...

    > “一个级别”“基本不用”的用词含义我也不知道是几个意思

    我的意思是
    1. “因为后端一样,所以性能一样(或者一个级别)”的逻辑是错的
    2.
    > 相比 fiber 、webworker 、gpu.js 相比,wasm 考虑优先级要低
    这个比“基本不用”看上去合理一些,我也觉得 WASM 一般相对于这些不是很合适。
    但是我不觉得到了“基本不用”的程度。

    > 底层的东西性能提升几个百分点是很有价值的,但业务层的东西就不是了

    所以
    3. 那也要看什么业务啊。你直接说
    > 相比 fiber 、webworker 、gpu.js 相比,wasm 考虑优先级要低
    不就得了,为啥非要直接一个“基本不用”扣上以至于引起
    > 纯属抠字眼
    > 用词含义
    的误会呢。
    5 天前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    @mxT52CRuqR6o5 另外我很好奇你说的“一个级别”是什么定义。
    我个人对”一个级别”的定义是 2 倍。但是隔壁组的工作是用几个月甚至半年做几个百分点的提升。这远小于我定义的“一个级别“的差距,然而人家还是在做。
    5 天前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    @mxT52CRuqR6o5 “少数“不等于“基本不用“。
    6 天前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    @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 。
    6 天前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    那么有没有正经的,“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 使用了一样的后端,然而这俩的性能确实差出了一截,可见一个语言的性能和编译器后端是啥根本就没有必然联系。
    6 天前
    回复了 James369 创建的主题 程序员 请教一个 CPU 密集计算多线程优化办法?
    @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 不能用的排除掉之后有可能就不会有“长时间使用”虚拟机的情况了。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1090 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 16ms · UTC 19:16 · PVG 03:16 · LAX 12:16 · JFK 15:16
    ♥ Do have faith in what you're doing.