转译的效率是原生的 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 这模型的效果其实很差，大多数时候都会乱讲……我已经放弃了
之前找的网上的开源代码，简单改了改

@WilsonGGG 然而这个问题对比的是 macOS 和 Windows 。

低分屏上 Ubuntu 还真比 macOS 好，至少 hinting 管用，也可以开次像素渲染。
我现在正在用低分屏+macOS ，字体渲染真的跟果粉说的一样，就像印刷出来的……
只是他们少了一个定语，像非法出版物的印刷。

我还给 macOS 装了一个点阵字体（字体名 Unifont ），现在的 macOS 渲染点阵字体也有一圈阴影了，虽然总体上看起来还是锐利的，能对齐到像素。不过旧版 macOS 和 Ubuntu 都没有这个问题。

Ubuntu 的字体渲染不是没有缺点，有些字体会有间距不一致的问题，同样的字体放到 Windows 和 macOS 下都挺好。

只能说各有优缺点吧。

也许是微软保留了各种曾经出现过的 API ，不少软件底层代码历史悠久能用就不改，所以整体看起来比较差。

比如获取系统默认字体就有一套 API 能拿到宋体，一套能拿到微软雅黑……

Windows 里面也有字体渲染看起来比较好的东西。

在 Windows 版 IDEA 里，把抗锯齿改成灰度，字体不用微软雅黑，看起来就挺好的。

Windows 10 的开始菜单界面字体效果也还可以。

Windows Terminal 不显示微软雅黑字体的时候也不错。

@nrtEBH 我突然想起了什么用隐私换便利之类的……

@jfv 求指路，顺便问一下，docker 最低给多少内存能跑

@NavilleZhang 简单看了看，感觉这玩意像 SELinux 而不是 Sandboxie……
Sandboxie 并不会让 API 调用失败，只是会让文件、注册表等读写操作都重定向到沙盒目录下，或者让程序读不到剪贴板之类的。基本上是开箱即用的，就好像装虚拟机来跑软件一样。
sandbox-exec 像是要么应用得改造适配，要么手动找出应用所需的权限一个个放行。
相比起来，虚拟机更接近我的需求，只是虚拟机占用的资源实在太多了。