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

@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 。但是具体做成什么样还是要看你学弟的心理定位，毕竟纯粹意义的“交流群”也有一堆。

巧了，我之前是 HHKB 用户，现在是 NIZ 用户，为啥换了呢，就是因为 HHKB 进水坏了

@wcsjtu 还是那句话，非常依赖于具体的细节
比如“可以把 Python 看做静态语言”这一条，假设有 y = foo(x)，在静态类型语言中，foo 一般有一个预定义的类型，比如需要一个 int 并返回一个 int ，这时如果 x 原本是个 float ，调用 foo 时会被 coerce 成 int ，但是在动态类型语言中，x 传进去之后依然是个 float ，并且可能在 foo 内一直以 float 的形式参与计算。自然就可以推出，在两种语言中实现并调用逻辑类似的 foo 函数，得到的 y 可能是不同的值。这两种情况的类型推导的处理方式也不一样。
再比如“类型标注”这一条，如果可以做到所有的函数和函数参数、返回值以及 class 的成员都有类型标注，问题会 trivial 很多，因为这样就和普通的静态类型语言没啥区别了，甚至大多数情况下都不需要怎么“类型推导”，而只需要按程序顺序根据类型标注给出的信息 check 一下函数的形参和实参类型是否匹配，需要“推导”的主要是泛型参数和 lambda ，问题的规模一般都比较小。
但是如果项目的目的是兼容一些已有的 Python 代码，那上面这两条都会有坑，所以我之前的看法一直都比较保守。

@lymith 其实就是这个意思，程序成为世界规则，世界规则由程序制定，和个人应不应该继续写程序，没有逻辑关系。
类比一下就是，马云可以通过写字来制定世界规则 => 世界规则由写字制定，所以每个人都应该学写字。

目前最简单的答案就是无脑 Unity ，除了更偏商业化之外，Unity 就是游戏引擎中的 Python 。
放在十五年前这个答案可能是 Flash ，可惜啊 ... 现在简单点的话用 Web 也可以

而且我很纳闷为啥学了游戏设计和游戏引擎，却不熟编程，难道没写过小游戏 demo ，学游戏引擎只是像我一样学学概念纸上谈兵没摸过代码？

感觉哪里不对
打个比方吧，我和马云，都会写自己的名字。马云写个名字可以好几亿的折腾，我写名字就只能折腾几百块。
难道可以说“写字过去是，目前是，可预见的未来内依然是世界规则”

你买了么玩了么？

另外表明一下我个人的立场，对于我个人来说，Hybrid 和 Disaggregation 都是卖点——因为我自己没事会研究下 CPU 架构之类的东西，Hybrid 就像那句话：“两件快乐事情重合在一起。而这两份快乐，又给我带来更多的快乐 ...”
其实我觉得程序员应该是乐见这些花活的，整得越多，程序员发挥的空间就越大。现在“寒气”都不算啥，哪天真人人都能无限算力+ AI 编程了，对于程序员来说才是绝对零度。

桌面这里 Hybrid 和 Disaggregation 解决的都是同一个问题，并且是对于这个市场来说很重要的问题，就是成本问题。
同样的多核性能（就 general purpose compute 来说），做多个 die 比做单个 die 更便宜，多用小核比多用大核更便宜。这俩本来就不冲突。所以最后两家给出了一样的答案——我都要，Intel 在 MTL 和 SPR 也要搞 Disaggregation ，AMD 在桌面要不要搞 Hybrid 不知道，但是如果他们想搞但现在还没搞的话，楼主说的问题大概是一个重要的原因，所以他们干脆就“先”不搞。

注意是“先”不搞，https://www.pcgamer.com/amd-ryzen-hybrid-architecture-big-little-intel-alder-lake Intel's pinning its future on Alder Lake's hybrid design, but AMD won't follow suit 'just to have a bigger number 这个 AMD 高管的言论很多网站都在报道，但是 PC GAMER 报道得最好，因为他帮你划好了重点“Just driving up the core count with little isn't going to be that useful until software comes along”——也就是说 AMD 不做软件上的脏活（可能是被推土机整怕了），那谁来做呢？纯软件开发者肯定不做，所有硬件都是一样的核心干嘛要做；硬件厂商再都像你 AMD 这样，那就永远别做了？
这个言论虽然是两年前的，但是在这个十月再来看尤其有趣，因为相同的事情其实刚刚就在 AVX-512 上发生了。

还有人说为啥服务器不 Hybrid 。其实 Hybrid 是 Intel 全局的一个方向，服务器也有对应的产品计划 SRF ，这个和 AMD 的路线其实更像。那为啥不把两种核心放一个 package 上呢？当然是因为这个市场的客户都知道自己要啥，HPC 的就买内存性能高的就行，要功能全高性能就买传统线，云厂就买小核，跑什么东西就买什么机器。也就是桌面这群**，既要单核性能，又要多核性能，还要便宜，怎么不去咬打火机呢

实际上 13900 的 die size 已经非常接近同产品线历史上最大的 11900 ，而考虑到后者本来就是不太正常的过渡产品，想像一下同样的多核性能全用 P 核实现是什么画面 ... （当然另一方面是目前 Intel 的 P 核效率有点问题） CHH 不懂尚且“可以理解”，毕竟“CHH 那里的水平”实际上就是连贴吧和微博都不如的水平。V2EX 作为一个程序员为主的社区，如果也不懂工程中 trade-off 的意义，我就不得不开始怀疑“V2EX 这里的水平”了。

#13 说的倒是比较中肯，杀死 HEDT 这事简直可以算是“U 界”的“4080 12GB”。我前段时间做的一个东西放 MSDT 的双通道 DDR4 上，别说什么 24C32T 了，跑仨核心就把内存带宽跑满了，再加核心一点用没有。

强迫自己每天 14 点 53 分落一次泪

Linux 下面 nvidia-smi 那个 GPU Memory Usage 不是 N/A ，是能显示出数据的。
比如我这 Steam 就占了 1GB 多，桌面占 350M 不到。