secondwtq 最近的时间轴更新
secondwtq

secondwtq

V2EX 第 81805 号会员,加入于 2014-11-16 03:41:33 +08:00
secondwtq 最近回复了
turbostat 试下,我这 Intel 是可以显示功耗的
(注意对于 Intel CPU ,这里显示的应该是 RAPL 提供的一个估计值,是通过一个数学模型算出来的,并不是直接测量功耗)
18 天前
回复了 whereisgungun 创建的主题 程序员 Java 求解如何优化 100 个 if 判断?
@whereisgungun 有相关数据的话就简单,找出每个请求走的哪个 if ,命中频率最高的排前面就行
18 天前
回复了 whereisgungun 创建的主题 程序员 Java 求解如何优化 100 个 if 判断?
你是想要优化结构还是优化性能?
18 天前
回复了 vazo 创建的主题 NVIDIA #直播点歌的路人是英伟达创始人黄仁勋#
@jousca 最近正好在整理 GPU 架构,昨天看到 Fermi 的 whitepaper ,第二页写着:
> Dedicated to the World's PC Gamers

www.ece.lsu.edu/gp/refs/gf100-whitepaper.pdf
20 天前
回复了 amlee 创建的主题 问与答 cs61a 的一道题,有大佬讲解一下吗?
那当然是“显然”“易得”啊

假设原链表是 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
21 天前
回复了 haolongsun 创建的主题 硬件 amd 大降价!,历史第一次。
大快所有人心的大好事,看来摩尔定律它又回来了 :)
22 天前
回复了 afirefish 创建的主题 程序员 后续, Win11 下大小核心调度问题。
@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 。但是具体做成什么样还是要看你学弟的心理定位,毕竟纯粹意义的“交流群”也有一堆。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2920 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 08:14 · PVG 16:14 · LAX 00:14 · JFK 03:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.