关键词 Dynamic Binary Translation

这事就挺纠结：
我们假设 Speedometer 这 benchmark 是靠谱的
所谓”靠谱“，是指”反映‘实际’场景“，从而能够用来评估”实际性能“。
我看貌似就跑了一堆各种框架的 TodoMVC，看上去还算靠谱

但是‘实际场景‘里，本站大多数用户都会装几个甚至几十个扩展。开了之后跑分两位数百分比的往下掉
关了之后跑分能上去了，但是这明显不是’实际‘场景，又有什么意义呢（除非你是浏览器开发者，或者苹果这样的垂直集成者）

#23 是正解，JS 这语言和政府一样，有天然的垄断性，所以其实很多时候是作为目标语言。但是 JS 从设计之初（如果这破玩意真的有“设计”的话）又是作为编程语言来设计的，所以 JS 有直接的编程语言和间接的目标语言两面（有意思的是，JS 无论作为编程语言，还是作为目标语言，都挺烂的 ...）。
前端圈开始是把 JS 作为编程语言来用，后来发掘出了目标语言的潜力，这才有了各种 source-to-source transformer，后来又有了各路 Script 。TypeScript 作为各路 Script 中的一个实例，虽然以兼容 JS 为核心设计理念，在作为“JS 的‘超集’的同时”依然可以理解为“以 JS 为目标语言的船新的编程语言”（忒修斯：阿嚏！）

如果把目标定在 JS 上的话，那 Babel 则是一个静态的 Rosetta，Reason 相当于 ocamlopt，TypeScript 类似 C 语言。在 naive 领域，目标语言是具体 ISA 的机器码，CPython 实际上是“用 C 实现的一个脚本语言解释器”，从目标语言的角度来看已经可以和 TypeScript 有一定的可比性，所以说 CPython 汁己就已经是 TypeScript 了，同时还有对等的 Ruby 、Perl 和一些无 JIT 的 Scheme 实现等。（ CPython 放在 JS 上应该是“用 JS 实现的一个脚本语言解释器”——因为 JS 作为目标实在是太慢了，所以除了练手项目之外很少见，可以说前端在应用层“AOT 编译"占绝对主导）

和 JS 有类似情况的语言其实不少，C 是最接近的之一，有很多 C 的”超集“，以及一些和 C 完全不同的编程语言是编译到 C 的，同时 C 也广泛作为通用编程语言使用。还有 JVM Bytecode/MSIL/LLVM IR 等，不过这些语言本身设计就是目标语言 /中间语言，并不能作为编程语言。

结论其实没错，不过这个帖子总体挺让人无语的
这么说吧，30 系就是老黄强行拔出来的，不知道具体出于什么目的（刚出那会乱七八糟的说法太多了，狙击主机，收购 ARM，狙击 AMD，存心耍猴 ... 或者单纯为了感谢客户向玩家送出一份“大礼”），但是 30 系各方面整体都挺烂的，不是一个好的对比对象。
另外 PC 平台上现在几乎所有芯片都喜欢往功耗曲线最右边拉，最近两年尤甚（俗称“官超”），虽说如此，楼主哪怕挑 RX 6000 系来比，都比 30 系要好 ...

当然不会，比如牙膏厂很早之前就开始搞了，但是消费级价格基本稳定甚至在降

我自己把终端模拟器的快捷键改成 Meta 开头了
终端模拟器还是比较简单的，没法全部改，比如 VSCode，我可以把编辑器里面的复制改成 Meta+C，但是拿查找框里面的快捷键没辙，还不如不改
总结就是 Linux 要改快捷键建议改源码重新编译 Chromium，GTK 等基础软件...

你没发现这次就是原来的壳子换了个零件么
很明显厨子是想先赶紧把东西上了，并没想出新产品，大的肯定还在后面
往好处想，这次这东西这么设计有可能就是为了方便 NMB 用

backtracking 了解下

我现在最好奇的不是坚果 M1 这个芯片到底咋样，而是楼主体系结构的老师是哪位大神，我觉得他 /她的学术观点一定会很有意思。

不过我可以确定的是，计算机处理的数据并非无源之水，楼主体系结构老师的观点也不是。
从一只鸽子的视角来看，计算机处理数据的流程大概是 输入 => 处理 => 输出。在主流的体系结构中（包括 ARM ），数据可以存储在寄存器、主存或外部设备里，而 ISA 是管理这整个过程的接口。也就是说，写程序的思路和把大象放进冰箱里是差不多的，分三步，第一步是把大象啊，啊不是，把数据从冰箱里，啊不是，从某个地方（寄存器、主存或外部设备里）取出来，然后处理数据，然后再把处理好的数据放到另外的某个地方去。在计算机高速不断把大象放进冰箱，即处理数据的过程中，这三步中的每一步都会影响处理的性能。

现在你有 32 位的数据需要处理，处理的速度和处理器运算性能是差不多的。
现在你有 32KiB 的数据需要处理，处理的速度不会高于 L1 缓存的带宽。
现在你有 320KiB 的数据需要处理，处理的速度不会高于 L2 缓存的带宽。
现在你有 32MiB 的数据需要处理，处理的速度不会高于 L3 缓存的带宽。
现在你有 320MiB 的数据需要处理，处理的速度不会高于主存的带宽。
现在你有 32GiB 的数据需要处理，处理的速度不会高于存储设备的带宽。
数据量越大，处理器核心流水线之外的限制就越严重，因为处理器在上百万的周期中一直闲着思考人生，和刷 V 站的网友一样，不知道该做些什么。

现在楼主说好像苹果又改变世界了，好像现在不需要走主存了，我圣·蒂姆·库珂·玛丽亚直接就可以凭空生成耶稣 ... 啊不大象 ... 啊不数据 ... 然后凭空就想出了宇宙的真理，但是最后被 V 站野蛮的网友钉在了十字架上 ...

真是悲伤的故事。

SPEC 最大的问题其实是他 TM 是收费的 ...（ benchmark 本身倒是开源软件+自己攒的数据拼起来的）
CB 其实也类似，免费，但是是闭源的
所以对于普通人来说，CB 可以粗略看，但是对于理解帮助不大
SPEC 由于维度比较多所以稍微好一点
这个角度来讲不如 Blender Benchmark，Phoronix Test Suite 之类免费开源的

@murmur #20 CB 只能反映一方面的性能，SPEC 就是通过各种不同的应用来全面地体现性能。
SPEC CPU 可以大致分为四套 benchmark，一个维度是 INT 和 FP，另一个维度是 speed (6xx) 和 rate (5xx)。rate 可以大致理解为全核性能，speed 可以大致理解为单核性能（但是部分是允许用 OpenMP 的）。两套跑的东西大致相同，有一点点区别。
在现代主流 x86 处理器上跑，每个 benchmark 的时间在几分钟到二十来分钟不等。标准的 SPEC 跑分要求跑多次（标准的 SPEC 跑分还要求披露大量的硬件信息、系统版本、编译器选项的信息，即保证结果可重现）。
由于每项都是不同的应用，所以在不同的条件下跑的时候，不同项之间结果的关系不是简单的线性关系。有大量的纸研究 SPEC 各项跑分的性能特征。

“不知道是云服务器垃圾，还是 vs code 有问题”
为什么不能是都有问题呢

我 VSCode 跑在隔壁 100 多 GB 内存的 Xeon Gold 物理机上，用 VNC 连，基本没啥问题

把 VSCode 调成纯黑主题即可

iPhone ？

“维护这个映射关系的开销不会很大么”
这个开销由硬件承担。可能有其他的方案，但是现在主流硬件都针对这个优化，已经形成了路径依赖

全是头上带点绿的……