每日HackerNews RSS

## Emacs 作为 Lisp 运行时:系统设计视角 本文深入探讨 GNU Emacs 的系统设计,将其定位为一个用 C 构建的 Lisp 运行时,而不仅仅是文本编辑器。它从回顾 Lisp 的基本原理开始,强调数据和操作可以互换的核心概念。现代编译器,如 LLVM 和 MLIR,也秉持这一原则,专注于通过中间表示将高级操作降级到机器码。 Emacs 的核心数据类型 `Lisp_Object` 采用“带标签指针”技术——将类型信息嵌入到未使用的内存地址位中——这是系统编程中常见的优化手段。这允许动态类型,而无需单独的元数据存储开销。本文将麦卡锡最初的七条 Lisp 公理直接映射到 Emacs 中使用的 C 宏,说明了 Lisp 的基本概念如何在低级别实现。 最终,作者认为理解 Emacs 需要从其数据表示 (`Lisp_Object`) 开始,并将操作视为对该数据的转换,这与函数式和数据导向编程范式相符。下一篇文章将探讨带标签联合在各种语言的系统编程中的更广泛应用。

## Emacs 内部结构与 Lisp 对象表示 一则 Hacker News 讨论围绕“Emacs 内部结构:用 C 解构 Lisp_Object(第二部分)”,探讨 Emacs Lisp 的底层实现细节。对话的核心在于 Emacs 如何用 C 表示数据——特别是数字和符号。 关键点包括使用单个位标签来表示整数(将值翻倍以便表示),允许直接相加而无需解码。参与者讨论了使用低位与高位标记指针的权衡,低位由于对齐保证和历史原因而更受青睐。存在争论,即这些微优化在现代 CPU 架构下是否仍然相关。 讨论还涉及 Emacs 与 GCC 的关系(考虑到共享作者),以及 GCC 的中间表示出人意料的“Lisp 风格”。一位用户分享了他们尝试将 Emacs 逐行移植到 JavaScript 的经验,赞扬了代码库设计和背后的逻辑。原始文章的作者表示有兴趣进一步探索编译器历史,并欢迎反馈。

本文探讨了在C++中实现单例模式时的性能考量。作者以`DisplayManager`为例,展示了构造函数选择(默认 vs. 用户自定义)对生成代码和性能的显著影响。 用户自定义的构造函数需要编译器在每次`Instance()`调用时插入保护变量和检查,从而引入来自`__cxa_guard_acquire`和`__cxa_guard_release`等函数的开销。这与默认构造函数形成对比,后者生成更简单、更快的代码。 文章还比较了使用块局部静态变量(如原始实现)与私有静态数据成员。当使用默认构造函数时,两者性能等效;但当需要用户自定义构造函数时,静态数据成员方法*优于*块局部静态变量,因为它避免了保护变量的需求。 最终,作者建议在需要构造函数时使用静态数据成员以获得最佳性能,并在可以使用默认构造函数时使用块局部静态变量以简化代码。文章提供了Compiler Explorer链接,用于详细的代码比较。

## C++ 单例性能争论 一篇最近的文章探讨了 C++ 单例的性能,引发了 Hacker News 上的讨论。文章强调了使用函数局部静态变量代替传统的静态数据成员可能带来的速度提升,但评论者指出了关键的权衡。 函数局部静态变量的方法牺牲了 C++11 保证的线程安全静态初始化,依赖开发者来确保线程安全。它也重新引入了“静态初始化顺序混乱”问题——这是 Meyers 单例模式旨在解决的问题——不同代码单元之间的初始化顺序变得不确定,可能导致崩溃。 许多人认为,过度关注单例性能通常是一种过早的优化。如果单例访问*确实*是一个瓶颈,那么根本问题可能在于整体设计,而不是守护变量。 许多用户提倡使用替代方案,例如 `std::call_once`,或者干脆避免使用单例,而选择带有函数的命名空间,尤其是在不需要管理状态时。 讨论强调了在尝试微优化之前,对*实际*瓶颈进行分析的重要性。

看起来PyPy不再积极开发,甚至已经被numpy放弃(numpy/numpy#30416)。项目方没有官方声明,但numpy的issue是由PyPy开发者提出的。我添加了一个警告,以避免用户认为PyPy正确支持和开发了Python发行版。

在代码中处理时区向来非常复杂——最好的方法是利用现有的、虽然错综复杂的IANA时区数据库,而不是尝试从头开始构建解决方案。该数据库现在在GitHub上公开跟踪,细致地记录了世界历史和正在进行的时区变化。 除了简单地列出时间,该数据库还揭示了这个复杂主题中令人惊讶的人性化一面。它包含历史轶事,例如一位加拿大知识分子在1947年对夏令时的诙谐批评,反映政治分歧的“对峙”时钟面故事,甚至还有调查工作以确定偏远地区的时区历史。 虽然时区本身是编程难题的来源,但管理时区的数据库却是人类尝试组织和理解我们与时间关系的一次迷人记录。

此页面通过您的摄像头响应您的脉搏。没有人能看到您。只有您的心率会被分享。心跳继续体验。由 rdu 制作。这不是医疗设备。检测到另一个存在。想定期发现像这样的酷项目吗?订阅新闻通讯。由 Random Daily URLs 充满爱意地制作 · 项目第 19/25 个 · 在 X 上关注 · 常见问题解答 · 联系我们 · 隐私 · 条款。

## 浏览器视频中的脉搏检测:黑客新闻摘要 一个名为pulsefeedback.io的新项目在黑客新闻上展示,声称可以直接从用户的网络摄像头视频中检测出他们的脉搏速率。该技术利用血液流动引起的皮肤细微颜色变化,采用诸如欧拉视频放大(EVM)等技术,并可能使用基于人工智能的分析。 尽管引人入胜,评论者对其实际准确性和潜在滥用表示怀疑。担忧集中在技术被用于操纵、画像(例如,被雇主或执法部门利用)或不准确的健康评估。许多人指出该技术已经研究了几十年,但并未被广泛且有问题地采用。 讨论强调了这项技术的伦理考量,并提到了预见潜在有害应用的重要性——这一点在一篇链接的关于避免“分心”开发的博文中得到了强调。用户还报告了不同的准确性水平、浏览器兼容性问题以及对通过API端点收集数据的隐私担忧。一些用户指出,类似的功能已经存在于Google Fit等应用程序中。

## 科幻景观的变迁 书面科幻正面临着一个有趣的悖论:虽然该类型在电影、电视和游戏中蓬勃发展,但在书店货架上的存在感却在下降。然而,科幻理念正在触达*新的*读者,渗透到主流文学中,以时间旅行、人工智能和反乌托邦未来为主题——出现在被提名享有声望的文学奖项的作品中,而不仅仅是科幻奖项。 这种“后科幻”不同于该类型的传统形式。虽然经典的科幻小说诞生于20世纪初的廉价杂志,并受到雨果·格恩斯巴克等人的倡导,培养了一批忠实的粉丝和迭代发展理念,但如今的科幻小说往往缺乏这种专注的、类型驱动的创新。奇幻小说目前在类型奖项中占据主导地位,掩盖了科幻小说的光芒。 主流接受度的提高是一把双刃剑。虽然扩大了影响力,但也面临着失去历史上推动该类型的忠实社群和实验精神的风险。作者们正在为普通读者写作,优先考虑散文和角色发展,而不是复杂的世界构建和思辨概念。 最终,科幻的未来取决于这种理念的传播能否持续下去,或者失去专门的“类型机器”是否会导致停滞。尽管存在潜在的衰退,作者仍然表达了对后科幻小说持续发展以及传统类型在潜在终结前迸发最后一次创造力的希望。

这段C++代码使用模板元编程实现了一个素数筛法,模仿了Lisp(特别是Scheme)的风格。它利用C++17的特性进行编译时计算。 核心函数包括`infinite_integers`,生成一个无限的整数列表;`filter_mod`,过滤列表以移除能被给定数字整除的元素;以及`prime_sieve`,递归地应用`filter_mod`来生成素数列表。`let_lazy`引入了延迟求值,类似于Scheme的`delay`,防止编译期间发生无限递归。 `primes`类型被定义为将`prime_sieve`应用于从2开始的无限整数列表的结果。一系列`static_assert`语句验证了前六个素数(2, 3, 5, 7, 11, 13)在编译时被正确计算,展示了元程序的运行功能。包含的Scheme代码提供了直接等效的实现以供比较。

这次黑客新闻的讨论围绕着Lisp风格的C++模板元编程,并在GitHub上展示了一个项目。 许多评论者分享了他们几年前构建类似库的经验,主要用于链式数值运算和利用SIMD优化——令人惊讶的是,GCC对此支持良好。 一个关键点是C++模板的“动态类型”特性,这可能导致编译期间出现难以理解的错误。 一位用户描述了一个早于Eigen的项目,它对数据流编程的支持更好,但缺乏显式的SIMD指令。 虽然承认模板元编程的乐趣和强大功能,但许多人警告不要在生产代码中使用它,因为它可能导致难以阅读、缺乏文档的代码和漫长的编译时间。 讨论还涉及未来的C++标准(C++26、C++29)可能提供更易于访问的替代方案,以及`constexpr`在某些任务中的适用性。 最终,讨论强调模板元编程是C++中一个引人入胜但通常不切实际的领域。

## 云计算虚拟机比较 (2026) - 摘要 本次全面比较涵盖了7家供应商(AWS、GCP、Azure、OCI、Akamai/Linode、DigitalOcean、Hetzner)的44种虚拟机类型,分析了CPU性能和性价比。测试重点关注2vCPU配置,以评估可扩展性和价值,并显著扩展了区域测试,以考虑性能不一致的情况。 **主要发现:** AMD的EPYC Turin CPU在性能方面占据主导地位,尤其是在AWS的非SMT C8a实例中。Intel的Granite Rapids比Emerald Rapids有了显著提升,解决了之前稳定性问题。Google (Axion)、Azure (Cobalt 100) 和 Ampere 的 ARM 解决方案正变得越来越具有竞争力。 **Hetzner 和 Oracle 一直提供最佳性价比**,Oracle的免费层是一个显著优势。 **性价比:** 竞价实例提供最具成本效益的计算资源,而1-3年预留实例则提供大幅折扣。GCP和Azure在价值方面经常竞争激烈,而AWS往往价格较高。 **建议:** 对于预算解决方案,请考虑Hetzner或Oracle。对于最大性能,Turin驱动的虚拟机是明确的赢家。利用竞价实例和预留实例来优化成本。 **总而言之:** 云计算格局正在迅速发展。升级到现代CPU并仔细考虑定价模式对于最大化性能和价值至关重要。本次比较为明智的决策提供了详细的资源,但还应考虑各个工作负载的需求和供应商的具体因素。 原文链接:[https://dev.to/dimitrioskechagias/cloud-compute-vm-comparison-2026](https://dev.to/dimitrioskechagias/cloud-compute-vm-comparison-2026)

## 自主AI研究:一个新时代 前沿AI研究已从人类主导的实验转向在庞大计算基础设施上运行的完全自主AI代理。该项目于2026年3月启动,展示了核心原则:使AI能够通过连续、自动化的实验来自我改进语言模型。 该系统通过为代理提供一个最小的LLM训练设置(nanochat)和一套指令(`program.md`)来工作。代理修改训练代码(`train.py`),运行5分钟的训练周期,评估结果(使用每字节验证比特数),并重复——有效地“编程程序”而不是直接编程代码。 该仓库故意保持简单,包含三个关键文件:固定的数据准备脚本(`prepare.py`),可编辑的训练循环(`train.py`),以及代理的指令(`program.md`)。这允许集中实验和可管理的代码更改。目前需要单个NVIDIA GPU,该项目旨在展示一种新的范式,即AI驱动自身的进化,目前已进行到第10,205次代码生成(尽管无法验证)。

## LLM 自动研究:Hacker News 摘要 最近 Hacker News 的讨论集中在 Andrej Karpathy 的“autoresearch”项目(github.com/karpathy)上,该项目使用 LLM 自动研究如何改进 nanochat 模型。该系统在一块 GPU 上训练,修改代码和超参数以优化性能。 对话探讨了这种方法的潜力以及风险。担忧范围从自动化恶意软件创建和自我改进的 AI 导致不可预见的后果(甚至“奇点”)到更实际的问题,即它是否仅仅是复杂的超参数调整。许多评论员强调了 AI 研究本身的自动化程度日益提高,一些人已经在尝试类似的自我改进代理。 一个关键的观察是,当前的 LLM 表现出一种“谨慎”的不愿探索真正新颖的研究方向,并且该项目的初始“改进”有时涉及看似随机的更改,例如更改随机种子。尽管如此,该项目被视为朝着完全开放和自我改进的 AI 模型迈出的重要一步,即使资源有限,也具有重大影响的潜力。讨论还涉及为社会准备应对日益强大的 AI 带来的不可避免的变化的必要性。

哈罗德·布鲁姆是一位备受争议的文学评论家,他在学术界引发强烈反应——常常是鄙夷,这源于他大胆的断言,例如莎士比亚“创造了人类”。虽然他的《西方经典》等书籍深受普通读者喜爱,但学术界普遍不认可他的作品,特别是他对影响力的关注以及 perceived 的精英主义。 布鲁姆认为,伟大的作家与他们的前人作斗争,这种“误读”是原创性的关键——这一概念在他的《影响力焦虑》中有所阐述。他相信,文学巨匠的传承塑造了后来的作品,而莎士比亚则至高无上。这种观点与当时流行的强调历史背景和社会因素的批判理论相冲突。 尽管受到学术界的抵制,布鲁姆却与许多寻求对文学充满激情的读者产生了共鸣。他提供了一种将阅读视为精神职业的愿景,一种对抗遗忘的防御。尽管他的理论可能会令人感到无力——强调文学历史的重量——但他最终敦促作家们直面影响,并塑造自己的声音。 最终,布鲁姆的遗产在于他坚持文学的力量、记忆的重要性以及在丰富而有时令人难以承受的传统中创造新事物的持久斗争。他没有提供简单的答案,而是发出了一个具有挑战性的呼吁,即深入参与过去,以塑造艺术的未来。

一场黑客新闻的讨论围绕哈罗德·布鲁姆及其文学批评,特别是他的著作《西方经典》。用户们承认布鲁姆是一位独特的人物,他真正*阅读*并理解文学——根据对斯坦尼斯瓦夫·莱姆关于读者情况的观察,这是一种罕见的情况。 对话涉及对布鲁姆的批评,一位评论员认为一些负面情绪源于他保守的政治观点以及对“怨恨学派”的直言不讳的批评——包括多元文化主义者、女权主义者和马克思主义者。 尽管对他的具体论点存在分歧,但许多人同意,接触布鲁姆推崇的作者可以增强人们对文学的欣赏。这场讨论突出了布鲁姆在文学话语中备受争议但极具影响力的地位。

更多

联系我们 contact @ memedata.com