@fivee 其实本来真没什么，只是这几年花粉骂小米的时候时不时提一嘴这个，大家看得多了慢慢就觉得这是个负面的东西了。
但只要稍微动脑想一想，就会觉得他们的很多说法其实都毫无根据，莫名其妙。

转译的效率是原生的 72%，不过跑分测的是纯转译的性能，因为不涉及调用系统库，只是纯粹的计算。
大多数应用调用系统库来完成某些操作，因为 ARM64EC 允许 x64 和 ARM64 指令集互相调用，可以算作程序里有一部分是不需要转译的。

我猜用.NET 开发的程序表现还会更好。

大多数可以，效率还不低：
https://i.imgur.com/703xn2x.png

依赖驱动程序或者 AVX 指令集的就不行了。

@CatCode 这种情况是运算性能有瓶颈，而显存带宽无瓶颈。
量化之后实际上并不会真的用量化的精度来计算，计算时都会还原到 fp16 或者 fp32 。（不同的算子好像要求不同）。

而还原到 fp16/fp32 的过程需要消耗额外的算力。

技术方面还好，美术方面比较厉害……

@Mithril 其实 Python 可以不打成单文件包，这样里面的 DLL 可以轻松替换

@anUglyDog 3700U 的性能跟 N100 差不多，单核几乎一样，多核有一点优势，超线程给的优势。

好处是核显图形渲染性能更强，如果有游戏需求的话。
但 N100 的视频硬件编码性能强，质量好，功耗也低，适合作为服务器（尤其是流媒体服务器）用途。

但是 3700U 待机功耗比 N100 高，Ryzen 处理器只有 4xxx 以后的功耗才开始变低。

3700U 有一个优势是 PCIe 通道多了 4 条，但最终有没有用上还得看主板……

我甚至用来作为主力机……

@daveh 对了，至于换 JBR17 跑一下这个事情，因为我已经第一时间升级到 14.4.1 了，所以已经没有必要测了。

@daveh
我确实看不懂，得向你请教一下

> 一些恶意程序、poc 程序最喜欢在进程全地址空间扫描
能不能具体说明是哪个恶意程序或者 poc 程序，利用的是哪个漏洞。如果只是漫无目的地扫描，那么它接下来该做什么？

> 触发提权漏洞
看来范围更小了，能更详细一些吗？

现代的操作系统进程的地址空间都是虚拟地址，程序获取自己申请的内存和加载的动态链接库的内存地址不需要通过一个个扫描地址的方式来探测，一般都可以通过操作系统提供的接口来得到。

为什么会存在需要全地址扫描才能得知的内存地址，而且这个应用程序居然还能有权访问（即不会触发 SIGSEGV 、SIGBUS ，因此程序能够通过是否收到信号的方式来找到它）。我对 macOS 的内核完全不了解，如果这是 macOS 特有机制，可以简单介绍一下，或者给我相关信息供我检索吗？


你的说法听起来也适用于 Linux 。为何从未听说过有云服务厂商担心这个问题，尤其是提供 Docker 容器服务、云函数等功能的厂商

@daveh
公司的项目并不会崩溃，开发工具（例如 DBeaver ）之类的偶尔会崩溃。而且不是升级 JDK 就能解决，大多数软件只兼容 JDK 17 ，兼容不同版本的 JDK 得改代码适配。而且非 LTS 版本能用的第三方库不全，大家都不会花时间精力在这种版本上。

这种事情都是说起来轻松，实际做起来，还不如直接抛弃 macOS 改用 Windows ，省下的时间活都干完了。

这和安全也没有什么关系，我没见过有任何有信服力的说法能证明这个改动提升了安全性，只见过果粉用这个说法来给苹果的行为辩护。

@daveh 还有，如果是苹果故意这么做的，那给我的印象就更糟糕了，比工程师改代码测试忘记改回来还合并进去了的情况糟糕。

这意味着，当苹果想更改系统行为的时候，有这些选择：
1. 发布公告说明 macOS 即将发生重大改变，可能会对应用兼容性产生影响。在公告里说明为什么要作出这项更改，有什么好处，让各大开发商尽快完成适配工作（或选择放弃兼容 macOS ）。

2. 偷偷发布正式版更新，直接对最终消费者进行惩罚，通过引发严重故障让他们来倒逼软件开发商适配。像 Java 这种有人买了商业支持，客户有要求，不能不做。

苹果觉得 2 比 1 好。

@daveh 我根本享受不到这些，只有忍受每天不定时崩溃……

不升级不行，我在 14.4 天天忍受折磨，Java 应用随机崩溃

@niunaisuan93 这模型的效果其实很差，大多数时候都会乱讲……我已经放弃了
之前找的网上的开源代码，简单改了改