unix.stackexchange.com/questions/269098/silent-disk-errors-and-reliability-of-linux-swap Silent disk errors and reliability of Linux swap - Unix & Linux Stack Exchange 不知道是不是你想要的

1. 不要完全用软件的思路揣测硬件实现，硬件可以定制任意位数的加法器的 ...
2. 不止 LOOP ，JMP 就很常用这样的模式
3. 由于各种原因，LOOP 这条指令基本早就不用了，编译器也不会生成。

我觉得比较合适的是强制使用“符合某些条件”的开放标准，而不是钦定一个特定的标准。
反正苹果只要自己能躺是不在乎恶心了谁的，也别怪别人天天恶心你

... 噢对了，如果楼主说的"native"是指移动端的话，那么现有解决方案比 Qt Web 更成熟
楼主的 idea ，再一次地，是 Atwood's Law 的一个体现——类似的事情桌面 GUI 早就做完了，叫做 DirectUI 。

并且 DirectUI 一般并不会直接写 3D API 函数或 Shader ，一般的 DirectUI 的架构是，由一个 Window System Abstraction 提供窗口、事件处理和 3D API Context 等平台相关的，最基本的东西，然后由一个 Vector Graphics Library 提供高层绘图 API ，然后上层的组件调用 Vector Graphics Library 绘图，Vector Graphics Library （可能）会调用 3D API ，也可能直接 CPU 渲染了（我现在打字用的这个 Firefox 就是没法用 GPU 加速的 ... 而我打开上面那个 Qt Web 的 demo 页面会直接告诉我不资瓷，所以依赖于 3D API 是有问题的，而 Vector Graphics Library 可以帮你解决）。

而 Web 浏览器本身就可以看成 DirectUI 的一种实现。比如在 Chromium 系浏览器中，Window System Abstraction 的角色由 Aura 担任，Vector Graphics Library 由 Skia 担任。
要实现所谓的“跨平台 native 体验”，最简单的是干掉 Web ，而不是设法绕过 Web——绕过 Web 其实就相当于在 Web 这个 DirectUI 上再做一层 DirectUI ，让浏览器来当 Window System Abstraction ，这不是画 Python 舔 jio 么。而干掉 Web 的结果就是 Flutter ... 你要 JS 生态的话 React Native 也行，或者 Flutter Web ，Qt Web ... 但是大的 idea 是不变的

所以你看局早就设好了，只是鸡还在炖没开始吃而已 ...

@MMMMMMMMMMMMMMMM 其实有现成的，Qt 就能： https://www.qt.io/qt-examples-for-webassembly

问题是人家 Qt 没能做到你要的那个程度啊
我的意思是，specific 的技术和微小的细节被看得太重了。你所担心的，卷来卷去的事情，历史上已经多次发生，以后很可能继续发生。Mac 有 Cocoa 踢掉 Pascal ，现在又要 SwiftUI 和 Cocoa 共存，Gamedev 有 shader 踢掉 fixed pipeline ，然后是底层 API 和高层 API 共存，就连 Qt 也一点点 QtWidgets 换 QML 了，至于微软和 Web 的破事就不用我说了。我不会有“以后不会再发生类似的事情”的想法。
作为一个开发者，什么适合当前的问题就用什么。在这个上下文里，Web 并不特殊，特殊的是它的*生态位*。你所述的使用场景（跨平台）之所以常用 Web 是因为它占据了这个生态位。如果这个位置换人了就再用新的就是。更应该关心的，不仅是作为开发者，更是作为用户，是新的和旧的哪个更屎，屎多少，你的系统里会最后会有多少 XX 引擎。

Canvas 和 WebGL 是两个东西啊 ... 而且很多事情 SVG 也能做
然后就是上面这些都是实现细节，你这个想法关键是在你的那个“游戏引擎”上
这就要说到 Web 这个东西的特殊性了，就是现在这个局面本质上是 GUI 框架之外的层级对 GUI 框架这一层级长期巴尔干化的现状不满意后果，Web 是个通用的东西。
那你这个“游戏引擎”要怎么做成另一个通用的东西？就算真做成了，历史是一个圈，最多不过是做成另一个 Web 而已。

@cwcc Red Alert 两个词可以不要的~

哦对，最重要的一点是，我不觉得这是个致命问题。人都有各种奇怪的习惯，各种“错误”的认知，以及很多不懂的事情。如果以人的标准来衡量 ChatGPT 的话，它比大多数人做得都要好。

试了两天，太牛逼了

给他一个 API ，让他写例子，写出来之后可以继续 follow-up 根据你的需求让他加功能，哪行不懂可以让他解释，然后我还让他封装了一个类 ...
感觉好像在面试人，然后我试了下能不能让他面试我，好像还特么真的可以，可是我现在没有被面试的心理准备 ... 所以过两天再说吧，回头接个 TTS 和语音识别就可以 mock interview 了 :)

缺点是他告诉你的很多东西是有问题的，包括代码也得改一点才能用，保守一点大概有一两成的东西有明显的事实错误，并且不会给你来源。我试着问了一下，他只会不断重复”我是个 language model”或者叫你 consult documentation 。可能还需要再调教调教
主要是很多细节上的东西会出问题，比如我让他写 PKGBUILD ，居然真写出来了，可是参数基本都对不上。不过这倒可以理解，毕竟不是专门干这个的，不过我跟他讨论拉丁语，他说 "la" 是个定冠词我就呵呵了 ...

turbostat 试下，我这 Intel 是可以显示功耗的
（注意对于 Intel CPU ，这里显示的应该是 RAPL 提供的一个估计值，是通过一个数学模型算出来的，并不是直接测量功耗）

@whereisgungun 有相关数据的话就简单，找出每个请求走的哪个 if ，命中频率最高的排前面就行

你是想要优化结构还是优化性能？

@jousca 最近正好在整理 GPU 架构，昨天看到 Fermi 的 whitepaper ，第二页写着：
> Dedicated to the World's PC Gamers

www.ece.lsu.edu/gp/refs/gf100-whitepaper.pdf

那当然是“显然”“易得”啊

假设原链表是 x_1 => x_2 => x_3 => x_4 => ... => x_n
根据最后一行可知 step 一定返回一个有一个参数的函数，进而可知在 foldr 执行过程中每一步都要生成一个函数
根据 foldl 的示例，设最后生成的，用 z 为参数调用的函数为：
foo_0 z = ... fn(fn(fn(fn z x_1) x_2) x_3) x_4 ...
（注意以上的 fn 是 foldl 传入的，即示例中的 add/sub/mul ...，z 也是 foldl 传入的）

现在来推导 foldr 执行过程中间生成的那些函数，观察 foo_0 的形态，设其中的 (fn z x_1) 为 rest_1 ，进而有 fn(fn z x_1) x_2 为 rest_2 ，etc. 于是有：
foo_1 rest_1 = ... fn(fn(fn rest_1 x_2) x_3) x_4 ...
...
foo_m rest_m = ... fn(fn(fn rest_m x_m+1) x_m+2) x_m+3 ...
...
foo_n-1 rest_n-1 = fn rest_n-1 x_n
foo_n rest_n = rest_n
其中运行时的参数 rest_m 应等于 fn(... fn(fn z x_1) x_2) ...) x_m (m <= n)，z 也就是 rest_0 了

然后看看 foo_m 能不能套在 foldr 上，foldr 的 inductive case 可以写成：bar x_m (foldr ...)
因为最后返回的是 foo_0 ，所以上面说的“中间生成的那些函数”其实就是这里每次 (foldr ...) 递归调用返回的函数，即：
foo_0 = bar x_1 foo_1
...
foo_m = bar x_m+1 foo_m+1
...
foo_n = identity
那 foo_m+1 是啥呢：
foo_m+1 rest_m+1 = ... fn(fn(fn rest_m+1 x_m+2) x_m+3) x_m+4 ...

最后就是 bar 怎么写的问题，其实到这比较明显了，就是想办法用 foo_m+1 实现 foo_m
把 foo_m 展开：
bar x_m+1 foo_m+1 = \rest_m -> [ ... fn(fn(fn rest_m x_m+1) x_m+2) x_m+3 ... ]
需要替换掉大括号里面那块，这里唯一可以利用的函数是 foo_m+1 ，两边 x_m+2) x_m+3 ... 这些在 foo_m+1 里面都有，而 rest_m+1 = fn rest_m x_m+1 ，所以 bar x_m+1 foo_m+1 = \rest_m -> foo_m+1 (fn rest_m x_m+1)

@likunyan 6k 块钱其中 5k 用来买 React 课程？

@winglight2016 是，所以我看到标题就想推荐 www.vatican.va/latin/latin_index.html

大快所有人心的大好事，看来摩尔定律它又回来了 :)

@mrzx
> 因为调度真正是由 cpu 硬件里的 ITD 来调度的

错误。调度依然是由 OS 控制。
根据 Intel SDM 14.6 的描述，ITD 的功能是 "Hardware provides guidance to the Operating System (OS) scheduler to perform optimal workload scheduling through a memory resident table and software thread specific index (Class ID) that points into that table and selects which data to use for that software thread."

实际上 ITD 是对 Hardware Feedback Interface (HFI) 的扩展（这东西之前就有个名字叫 EHFI ），后者是 LKF 开始加入的一个比较初步的版本（当时貌似叫 Hardware *Guided* Scheduling ，鉴于 LKF 是 2020 年的东西，理论上 Win10 应该是有 HFI 支持的 ...）。Intel SDM 对 HFI 的描述是 "Hardware provides guidance to the Operating System (OS) scheduler to perform optimal workload scheduling through a hardware feedback interface structure in memory." 具体说来，就是 CPU 会评估每个 logical thread 的能力（ capability ），目前包括在性能方面的和能效方面的，然后会给 OS 传一个表，表中用一个数值表示每个 logical processor 的不同 capability 。 就这么一个东西。

ITD 的扩展是加入了"Class"的概念，根据优化手册和白皮书，目前有四个 Class ，分别是标量，向量，较新的指令，和自旋等待。ITD 表和 HFI 表类似，但是每个 logical processor 的 capability 不再是一个值，而是会给出执行不同 Class 软件时的 capability （也就是说 HFI 表可以被看做只有一个 class 的 ITD 表）。另外，ITD 加入了一个“Run Time Characteristics”的功能，CPU 会试图将一段时间内运行的代码归类到某一个 Class 中。OS 会读取这些信息，ITD 本身并不决定如何调度。
在描述这些功能时，SDM 使用了如下措辞：
> the lowest performance level of 0 indicates a *recommendation* to the OS to not schedule any software threads on it for performance reasons.
> When the OS Scheduler needs to decide which one of multiple free logical processors to assign to a software
thread that is ready to execute, it *can* choose ...
> When the two software threads in question belong to the same Class ID, the OS Scheduler *can* schedule to higher performance ...
> Zeroing a performance or energy efficiency cell *hints* to the OS that it is beneficial not to schedule ...

类似地，优化手册中对 ITD 的描述如下：
> Intel® Thread Director continually monitors software in real-time giving *hints* to the operating system's
scheduler *allowing* it to make more intelligent and data-driven decisions on thread scheduling. With Intel
Thread Director, hardware provides runtime *feedback* to the OS per thread based on various IPC perfor-
mance characteristics, in the form of ...

白皮书中描述如下：
> ... we wanted to develop a hardware solution that would *assist* the OS achieve optimal runtime scheduling by the Intel Thread Director giving the OS more *information* by monitoring instruction mix, the current state of each core, and the relevant microarchitecture telemetry at much more granular level than would be available via instrumentation
> The Intel Thread Director provides *hints* to the OS scheduler with thread-related information. Using these hints, the OS *can* choose between energy efficiency (EE) and performance (PERF) depending on system parameters like power policy, battery slider, etc.

www.computerbase.de/2021-08/hot-chips-33-intel-alder-lake-steht-und-faellt-mit-dem-thread-director Hot Chips 33: Intel Alder Lake steht und fällt mit dem Thread Director - ComputerBase 这里有 ADL 在 HC33 上的胶片，其中一大块是有关 ITD 的
lore.kernel.org/lkml/[email protected] [RFC PATCH 00/23] sched: Introduce classes of tasks for load balance - Ricardo Neri 这是 ITD 在 Linux 上的 patch ，邮件正文也包含了对 ITD 工作模型的描述，当然由于 Linux Kernel 是跨平台的，这堆 patch 是先在 Linux 调度器上做了一个根据 Class 调度的框架，然后再把 ITD 作为 x86 的实现塞进去，所以描述本身并不涉及太多细节。

主要由硬件控制的东西倒是有，就是用于调整频率的 Speed Shift （ SDM 中叫 Hardware P-State (HWP)），效果见 chipsandcheese.com/2022/09/15/how-quickly-do-cpus-change-clock-speeds How Quickly do CPUs Change Clock Speeds? – Chips and Cheese ，不过这东西 SKL 就有了。而且 HWP ，HFI ，ITD 都是可以禁用的 ...

“单一时间线的即时通讯”其实不是完全不可以，很多社区都这么干，比如 ArchLinux CN 的群，各种 IRC ，甚至好像 Clojure 大半个社区都是在 Slack 上的
我觉得 IM 和其他形式并不冲突，这不是个 N 选 1 的问题

比如单纯的 Q&A ，可以使用类似 StackOverflow 的平台，把群里的问题引流过去。“微信群里十几条”不是完全没有意义的，对同一个问题，不同的人可能有不同的看法和不同的角度。尤其是 Blender 不 是 微 信（也不是 Python （狗头）），这些专业 DCC 都是非常灵活的东西，同一个问题的正确答案往往不唯一。而很多 YouTube 教程只能给出单一角度的答案，并且往往整上好几分钟，其中一半还是 Logistics ... 反倒是 IM 的即时性很容易激发“just-in-time”的讨论，大家会发出很多小的有意思的点，这是 IM 的优点也是缺点，比如这也导致了“非线性”的问题，但只要没碰到这类问题，效率是很高的。

说到这个“非线性”问题，用类似 BBS 的平台是无法解决的，因为 BBS 的主题虽然有更多的 context ，但是依然具有很强的时效性，所以还是类似 StackOverflow 、知乎之类的问答平台更合适。

你说的什么看不到历史消息，图片已过期之类的问题，更多的是微信这个 IM 特定的问题。但是作为一个 IM 重度用户，我的经验是所有 IM 在本身的功能和体验上都有很大的提升空间（低情商：每一坨屎都有独特的风味），从一个 IM 换到另一个 IM ，只是从一坨屎换到另一坨屎。特别地，我发现我使用的这些 IM 在历史消息的处理上都非常敷衍，没有一个 IM 能高效地搜索和备份历史消息——这方面反倒是 IRC 优势最大，中心化的 IM 会以把用户当傻逼为 prime directive ，试图接管用户的一切操作，导致用户必须完全依赖 IM 提供的服务处理历史消息，这才是万恶之源。

所以如果要用 IM ，可以考虑通过一些手段规避掉这个限制，同时还需要考虑如何把 IM 中的信息沉淀下来，减轻对历史消息的依赖。我觉得你学弟这个想法让人觉得别扭的根本就是这个——一个微信群可以用来“交流”，但它不是“社区”，社区是需要有内容积累的，而一般 IM 的消息，设计上是你想不看就可以不看的，没办法形成“积累”，所以不是不能用 IM ，而是不能完全依赖于 IM 。但是具体做成什么样还是要看你学弟的心理定位，毕竟纯粹意义的“交流群”也有一堆。