2025 06 15 HackerNews

2025-06-15 Hacker News Top Stories #

  1. 惠普收购Palm及其失败的教训：惠普因CEO变动和战略调整，未能有效整合Palm的WebOS技术，导致TouchPad以失败收场。
  2. 苹果的液态玻璃设计：苹果的液态玻璃界面设计不仅是视觉更新，更是为未来AR界面奠定的基础。
  3. 子宫内膜异位症：子宫内膜异位症是一种成因不明、缺乏有效治愈方法的复杂疾病，需更多研究和关注。
  4. 用纯PyTorch实现Stable Diffusion 3.5：miniDiffusion是一个用于教育和实验的纯PyTorch实现，代码简洁且结构清晰。
  5. 自适应语言模型：SEAL框架通过自我微调和强化学习优化，提升了语言模型的知识整合和少样本泛化能力。
  6. SIMD友好子串搜索算法：文章探讨了SIMD优化的字符串搜索算法及其在不同指令集下的实现和性能比较。
  7. 实现逻辑编程：文章介绍了Prolog和Datalog的特点及实现，展示了逻辑编程在数据库查询中的潜力。
  8. 科技行业裁员危机：裁员主要由资本成本上升和税收政策变化引发，部分企业通过海外转移研发应对。
  9. Google Cloud服务中断：服务中断源于代码变更缺乏错误处理，暴露了测试和推出流程的不足。
  10. 整数线性规划进展：混合整数线性规划在实际应用中取得显著进展，但仍面临挑战，研究仍然活跃。

I convinced HP’s board to buy Palm and watched them kill it #

https://philmckinney.substack.com/p/i-convinced-hps-board-to-buy-palm

Phil McKinney 在他的博客“Phil McKinney’s Studio Notes: Innovation Decisions”中分享了一个他从未公开讲述过的故事：他如何说服惠普（HP）董事会以 12 亿美元收购 Palm，然后目睹他们在短时间内摧毁了它。这篇文章不仅仅是对技术失败的分析，因为 Phil McKinney 是惠普的首席技术官（CTO），他领导了对 Palm 的技术尽职调查，并在向惠普董事会提出收购建议时充满信心。他认为惠普正在购买移动计算的未来。

文章中，Phil McKinney 详细描述了他为什么相信 WebOS 是一个突破性的平台技术，以及他如何向惠普董事会和当时的 CEO Mark Hurd 展示这一点。他认为 WebOS 代表了惠普在新兴移动计算市场中差异化的关键。在 2010 年 4 月，惠普宣布了这项 12 亿美元的收购，Phil McKinney 对所做的技术工作感到自豪，并对共同构建的未来充满期待。

收购完成后，Phil McKinney 的角色转变为帮助 Palm 团队利用惠普的大规模能力。他们讨论了如何将 WebOS 扩展到平板电脑，可能与惠普的 PC 平台整合，甚至在打印机生态系统中找到应用。一切似乎都为成功做好了准备。

然而，2010 年 8 月，Mark Hurd 被迫辞去 CEO 职务，董事会用前 SAP CEO Leo Apotheker 取代了他，带来了完全不同的战略愿景。Apotheker 计划将惠普从硬件公司转变为软件和服务公司，类似于 IBM 多年前的转型。他希望退出或最小化惠普的硬件业务，包括个人电脑、打印机和移动设备，如 TouchPad。在他看来，WebOS 正是他想要消除的那种硬件干扰。

2011 年 6 月，Phil McKinney 因紧急医疗情况需要立即手术和八周的卧床恢复期，这使得他无法参与关于平台未来的最关键决策。在他康复期间，惠普的整个移动计算格局开始瓦解。

2011 年 7 月 1 日，惠普推出了运行 WebOS 3.0 的 TouchPad 平板电脑。Phil McKinney 从床上观看了这次发布会，希望看到他们所有技术工作和战略规划的成果。然而，他目睹了科技历史上最快的产品失败之一的开始。TouchPad 的定价过高，缺乏应用生态系统和营销力量来证明其高端定位。设备感觉匆忙上市，缺乏可能帮助其竞争的精致感。消费者评价充其量是混合的。初步销售数字令人震惊：惠普只售出了 25,000 台 TouchPad，而向零售商发货了 270,000 台。在同一季度，苹果销售了 900 万台 iPad，而 TouchPad 则在商店货架上积灰。

然后是改变一切的公告。2011 年 8 月 18 日，也就是 TouchPad 发布后的第 49 天，惠普宣布将立即停止所有 WebOS 设备。Phil McKinney 仍然卧床，通过新闻报道和行业分析实时观看他的技术尽职调查工作和战略建议被拆除。49 天，这不足以修复发布问题，建立开发者动力，或建立零售合作伙伴关系。平台业务通常需要 18-24 个月才能展示真正的市场吸引力。但 Leo Apotheker 没有考虑平台时间线，他考虑的是他将惠普转变为软件公司的策略。

最痛苦的部分不仅仅是决策的速度，而是得知 Apotheker 在甚至没有事先通知 Palm 团队的情况下就做出了停止选择。据报道，他似乎急于消除一个不符合他将惠普视为软件公司愿景的产品。Phil McKinney 感到无助、背叛，并且不知何故，他因为没有在那里为他认为的突破性技术而战而感到负责。

HN 热度 634 points | 评论 486 comments | 作者：AndrewDucker | 1 day ago #

https://news.ycombinator.com/item?id=44270709

  • 惠普在推出 TouchPad 时定价过高，缺乏应用生态系统和市场推广力度。
  • 要成功需要多年投资，市场预测失误很常见，关键是要有持续投入。
  • 微软 Windows Phone 失败也是因为设备上市时间太短，未能积累足够的应用。
  • 英特尔 Itanium 销售预测失误，而 IEA 对太阳能的预测则过于保守。
  • 预测错误是常态，关键在于持续预测直到最终正确。
  • 太阳能发电增长速度超出预期，未来可能超过全球能源消耗。
  • Itanium 的预测者随时间调整了预测曲线，而 IEA 似乎无视现实继续预测。
  • AMD 在 64 位服务器市场的影响被低估，Opteron 曾占据 25% 市场份额。
  • 英特尔在多核技术上的延迟是因为其主要软件合作伙伴对多核世界的支持感到担忧。
  • 英特尔直到 2006 年 Core 架构 Xeon 5100 系列推出前，在大众服务器市场上缺乏竞争力。
  • 英特尔希望在 PC 和服务器市场上实现垄断，但未能通过 Itanium 实现，最终不得不与 AMD64 交叉授权。

Apple’s Liquid Glass is prep work for AR interfaces, not just a design refresh #

https://omc345.substack.com/p/from-skeuomorphic-to-liquid-glass

苹果在 2025 年 WWDC 上推出的 “液态玻璃” 界面设计不仅仅是视觉上的更新，而是公司对未来人机交互方式的战略重塑。文章分析了这一设计转变的背景和潜在影响，指出这是苹果为未来十年做出的布局，旨在使用户在体验新技术时感到自然而非陌生。

苹果的设计变迁并非首次引发争议。例如，从 iOS 6 的拟物化设计到 iOS 7 的极简设计时，用户也曾对新设计的可用性和美学提出质疑。然而，苹果的设计改变通常预示着交互方式的根本变化。拟物化设计帮助用户适应触屏技术，而极简设计则反映了用户对触摸交互的熟练度。

“液态玻璃” 设计的推出与苹果的 visionOS 密切相关。在增强现实中，界面元素需要与现实世界共存，因此不能仅仅是遮挡视线的矩形框。液态玻璃通过动态的透明度和层次感，使界面更符合物理现实，从而在用户佩戴增强现实眼镜时，界面看起来更自然和真实。

液态玻璃不仅是一种视觉效果，它展示了苹果硬件和软件之间的紧密结合。动态透明效果和实时模糊等特性，需要强大的图形处理能力和优化的渲染管道。这种技术的高效运作在苹果自家设备上表现优异，而在竞争对手的硬件上可能会出现性能瓶颈，从而提升了苹果产品的价值。

尽管在 WWDC 2025 上，苹果的人工智能相关宣布较少，但其设计理念暗示了更具上下文感知的 AI 交互方式。例如，未来可能出现的智能建议以半透明的形式出现在用户视野中，与当前的工作流程融为一体。这样的设计思路使得 AI 交互显得更自然，而非侵入式的。

尽管液态玻璃界面带来了新的视觉体验，但早期反馈指出其在可读性和认知负担上的问题。透明的界面可能导致文本对比度下降，使得阅读变得更加困难。然而，苹果以往在设计方面的经验表明，他们会根据用户反馈逐步改进设计，以提升可用性和无障碍性。

苹果的设计变化不仅影响自身产品，还可能重塑整个行业。开发者和设计师会倾向于模仿苹果的新设计语言，从而在用户心中形成一种 “文化锁定”，即使是使用其他品牌设备的用户，也会习惯于苹果的设计模式。

通过液态玻璃的推出，苹果为未来的计算模式奠定了基础：人们将朝着混合数字和物理现实的环境界面发展。尽管触控依然重要，但语音、手势和上下文感知的交互方式将会变得更加普遍。苹果希望通过建立这一视觉和概念框架，来为用户和开发者的未来转型做准备，使得当轻便的 AR 眼镜普及时，用户的使用体验能够顺畅无缝。

HN 热度 306 points | 评论 322 comments | 作者：lightningcable | 1 day ago #

https://news.ycombinator.com/item?id=44271630

  • 苹果的液态玻璃设计不仅仅是为了界面设计刷新，而是为了 AR 界面做准备
  • 从 iOS 6 的拟物设计到 iOS 7 的极简主义，引发了关于可用性和审美价值的讨论，但两年后整个行业都采用了扁平化设计原则
  • 技术记者们往往对苹果做的事情视而不见，认为苹果是首次这么做，可能是因为他们主要使用 iPhone，不太了解其他设备
  • 有时候，普通人如果深入研究一个领域，可能会比专业人士更了解那个领域
  • 在医学领域，患者可能比医生更了解自己的特定病症
  • 评论是主观的，如果想要做出满意的选择，最好是找到一个品味相似的评论者
  • 评论者可能存在利益冲突，尤其是对于预售产品
  • 影响者之所以受欢迎，是因为他们可以外包你的想法
  • 人们不能自己做所有的“思考”，人们一直在为他人评论事物，这是一种有价值的服务
  • 苹果经常是第一个成功地做新事情的公司，早期的产品可能没有足够的成功来维持或者只是处于一个小众市场
  • 定义成功很难，如果苹果采用并改变了某个设计趋势，那算是成功吗？仅仅因为广泛采用？
  • 苹果经常等待市场证明某项技术后再去做，Face ID 就是他们购买了制作 Xbox Kinect 的公司
  • 苹果在多触点界面、个人电脑 GUI 和鼠标方面是先行者
  • 将 Kinect 与手机中的 Face ID 进行比较，需要考虑体积和技术的差异
  • 除了 iPhone 的发明，苹果还有什么是成功首创的？那已经是近 20 年前的事了
  • Windows Phone OS 设计简洁实用，功能超前，但微软没有把握好机会
  • Windows Phone 的失败是因为缺乏应用生态，苹果和安卓有 20 年的应用生态积累
  • 如果微软今天推出 Windows Phone，他们可以利用开源生态系统取得成功

Endometriosis is an interesting disease #

https://www.owlposting.com/p/endometriosis-is-an-incredibly-interesting

这篇文章是关于子宫内膜异位症（endometriosis）的详细介绍，这是一种非常有趣的疾病。文章首先提出了子宫内膜异位症的几个有趣之处：其存在的主要原因尚未完全明确，它与癌症相似，没有真正的治愈方法，并且是地球上最普遍且资金不足的疾病之一。

文章介绍了子宫内膜异位症的临床定义，即子宫内膜样组织在子宫外生长的情况。这种组织可能会植入附近的组织，如卵巢和输卵管，甚至更远的器官，如膀胱和肠道。由于激素生长因子（主要是雌激素）的持续影响，这些错位的子宫内膜样细胞会像正常的子宫内膜一样周期性反应。它们在每个月经周期中增厚、破裂和出血，但由于无处排出，这些组织和血液会积累，导致严重疼痛、炎症、纤维化（瘢痕形成）和器官之间的粘连。随着时间的推移，这些反复的炎症和纤维化周期可能导致腹部和盆腔内永久性结构变化，导致慢性盆腔疼痛和不孕。

文章接着讨论了子宫内膜异位症组织最初是如何形成的，以及为什么它们会被困住。主要的假设是逆行月经，这是由妇科医生约翰·桑普森（John Sampson）近 100 年前首次提出的理论。该理论认为，在月经期间，一些脱落的子宫内膜细胞通过输卵管逆流进入盆腔，而不是通过宫颈向外流动。一旦到达那里，这些细胞就会植入、继续生长，并成为子宫内膜异位症特征的子宫内膜样组织。

尽管逆行月经理论在医生中经常被重复，但它不能解释所有子宫内膜异位症病例。首先，逆行月经发生在 75-90% 的女性中，但大多数人从未发展成子宫内膜异位症。其次，子宫内膜异位症有多种形式，有些局限于盆腔区域，但也可以在非常远的区域发生，如胃肠道、肺部，甚至大脑。最后，最令人震惊的是，在从未经历过月经的人中也发现了子宫内膜异位症，如 8.5-13 岁的青春期前女孩、遗传性缺乏子宫的女性，甚至包括顺性别男性。这些男性患者可能雌激素水平较高，原因可能是肝硬化（导致雌激素分解能力下降）、高剂量雌激素治疗前列腺癌或肥胖。

文章最后提到，尽管子宫内膜异位症可能在跨性别女性接受激素替代疗法中发生，但这是一个复杂的问题，需要进一步的研究和讨论。总的来说，子宫内膜异位症是一个复杂且神秘的疾病，需要更多的关注和研究。

HN 热度 296 points | 评论 197 comments | 作者：crescit_eundo | 23 hours ago #

https://news.ycombinator.com/item?id=44272933

  • 女性患者诊断困难，可能与医生的系统性疲劳、傲慢、依赖经验诊断、对女性疾病无知或医疗中的性别歧视有关。
  • 患者不被当作个体对待，而是像处理日常任务一样被快速处理，导致 10% 的特殊病例得不到妥善处理。
  • 无论是公共还是私人医疗，都存在同样的问题，公共系统中没有像约翰霍普金斯这样的机构可以付费解决问题。
  • 人们认为大型语言模型（LLM）可能会超越医生，因为它们能够处理 90% 的常见病例。
  • 通过 LLM 健康项目，有人发现了两位 VA 专家和一位 PCP 未能诊断出的慢性医疗问题。
  • 语言模型擅长自由联想任务，如语义模糊搜索，而下一个标记预测是使用它们的最差方式之一。
  • AI 可以作为新病例的分类工具，将患者直接送往正确的专家那里，从而节省 GP 的时间。
  • 目前不需要 GP 的推荐就可以看专家，只需要支付费用。
  • 专家通常不会接受没有推荐信的直接预约，因为他们不想对 90% 的病例进行分类，而且大多数办公室的预约都排到了几周到几个月后。
  • 能否直接看专家取决于地区和专业。
  • 有人质疑如何阻止那些为了接触医疗专业人员而撒谎的人。
  • 有人认为即使患者撒谎也没关系，因为偶尔的谎言不会导致重大负面结果。
  • 有人提出为什么 AI 要“打败”医生，而不是“增强”或“改善”医疗服务。
  • 有人认为只有 AI 能够解决医疗、教育、销售、人力资源等领域的问题，因为人工官僚系统和系统表现不佳。
  • 任何 AI 都会反映出负责创建它们的官僚机构的偏见。
  • AI 可以被编程为更有耐心，调查边缘案例，并提供定制化服务，从而解决这个问题。
  • 获取数据本身就是一个巨大的问题，尤其是获取高质量的临床数据。
  • OpenAI 不缺投资资本，但缺乏高质量的临床数据源。
  • 即使 AI 存在问题，但在没有完美的非 AI 系统存在的情况下，OpenAI 已经相当好了。

I have reimplemented Stable Diffusion 3.5 from scratch in pure PyTorch #

https://github.com/yousef-rafat/miniDiffusion

miniDiffusion 是一个用纯 PyTorch 重新实现的 Stable Diffusion 3.5 模型，它具有最少的依赖性。这个项目旨在用于教育、实验和黑客攻击目的。它的设计理念是使用最少的代码量从头开始重建 Stable Diffusion 3.5，代码量仅约 2800 行，涵盖了从 VAE 到 DiT 到训练和数据集脚本。

  • 文件：主要的稳定扩散模型代码位于 dit.py、dit_components.py 和 attention.py。dit.py 文件包含主模型，dit_components.py 包含嵌入、归一化、补丁嵌入和 DiT 代码的帮助函数，attention.py 包含联合注意力的实现。 noise.py 是欧拉调度器的所在地，用于解决 Rectified Flow 的 ODE。 文本编码器在 t5_encoder.py 和 clip.py 中，它们的分词器都在 tokenizer.py 中。metrics.py 实现了 Fréchet 初始距离（FID）。 common.py 是训练的帮助函数的存放地，common_ds.py 是一个可迭代数据集的实现，它将图像数据转换为 DiT 模型的训练数据。
  • 文件夹：模型文件夹保存训练后的模型检查点和日志。编码器文件夹保存其他模块的检查点（例如，VAE、CLIP）。

⚠️ 警告：此存储库仍具有实验性功能，需要更多的测试。

组件包括核心图像生成模块、VAE、CLIP 和 T5 文本编码器的实现、字节对和单字节分词器的实现、SD3 组件、多模态扩散变换模型、流匹配欧拉调度器、对数正态采样、联合注意力、SD3 的训练和推理脚本。

开始使用：

  • 获取存储库：通过 git clone “ https://github.com/yousef-rafat/miniDiffusion” 命令。
  • 安装依赖：使用 pip install -r requirements.txt 命令。
  • 安装模型检查点：在运行脚本前，在 get_checkpoints.py 中添加 Hugging Face 令牌。 使用 python3 encoders/get_checkpoints.py 命令。

许可：此项目在 MIT 许可下进行，旨在教育和实验目的。

关于：这是一个用纯 PyTorch 重新实现的 Stable Diffusion 3.5 模型。

资源：提供 Readme 和 MIT 许可证信息。

HN 热度 267 points | 评论 36 comments | 作者：yousef_g | 7 hours ago #

https://news.ycombinator.com/item?id=44276476

  • 参考实现可能存在未维护和错误的问题。
  • Flux 项目和 minRF 项目适合初学者学习和训练小型扩散模型。
  • 参考实现的代码可能因为使用了有错误的 CLIP 参考实现而存在问题。
  • 修复 tokenizer 不应该需要太多努力。
  • 在 Flux 中可以禁用 CLIP，且不会影响质量。
  • 认为代码比训练得到的权重更重要的观点。
  • 提供了 fast.ai 上的 Stable Diffusion 构建课程作为学习资源。
  • 认为 fast.ai 课程涵盖的基础知识仍然有效且有用。
  • 没有许可证限制的 Stable Diffusion 实现。
  • 算法作为数学不可版权，但模型是受版权保护的。
  • 代码实现是可版权的，权重的版权保护是一个灰色地带。
  • 如果 OpenAI GPT 4 的权重泄露，全世界都可以免费使用。
  • 这个项目允许使用现有的 AI 权重进行模型运行和微调，但可能存在许可证问题。
  • 社区许可证限制了某些权重修改方式，不允许在生产中使用并收费。
  • 认为这个项目是一个干净的房间/脏房间重写。
  • 认为 PyTorch 实现可能调用了 CUDA/C/一些专有的东西，比纯 PyTorch 实现更难理解。
  • 认为这个项目是一个从第一原则重新发明轮子的酷项目。
  • 询问原始学术来源的可用性。
  • 询问这个实现是否有特别的属性，某些部分是否变慢或变快。
  • 询问这个实现是否与完整的 SD 3.5 一样捕获跨令牌注意力，或者为了清晰而简化。
  • 认为“从零开始”现在意味着“在 PyTorch 中”。
  • 认为任何“从零开始”的帖子都应该以链接到原始技术视频开始。
  • 除非作者是由黑猩猩抚养长大的，否则对这个项目不感兴趣。
  • 认为应该用汇编语言实现这个项目。

Self-Adapting Language Models #

https://arxiv.org/abs/2506.10943

标题：自适应语言模型

作者：Adam Zweiger, Jyothish Pari, Han Guo, Ekin Akyürek, Yoon Kim, Pulkit Agrawal

摘要：大型语言模型（LLMs）功能强大，但它们是静态的，缺乏根据新任务、知识或示例调整权重的机制。本文介绍了一种名为 SEAL（Self-Adapting LLMs）的框架，它使 LLMs 能够通过生成自己的微调数据和更新指令来自我适应。给定一个新的输入，模型会产生一个自我编辑的生成，这可能以不同的方式重构信息，指定优化超参数，或调用数据增强和基于梯度的更新工具。通过监督式微调（SFT），这些自我编辑会导致持久的权重更新，使模型能够持续适应。为了训练模型产生有效的自我编辑，我们使用了一个以更新模型的下游性能作为奖励信号的强化学习循环。与依赖于单独的适应模块或辅助网络的先前方法不同，SEAL 直接使用模型自身的生成来控制其适应过程。在知识整合和少量样本泛化方面的实验表明，SEAL 是朝着能够自我指导适应的语言模型迈出的有希望的一步。我们的网站和代码可在以下链接访问：[链接]。

主题分类：机器学习（cs.LG）

引用格式：arXiv:2506.10943 [cs.LG]

DOI 链接： https://doi.org/10.48550/arXiv.2506.10943

提交历史：由 Jyothish Pari 提交，2025 年 6 月 12 日。

全文链接：可以查看论文的 PDF 版本，HTML 版本（实验性），TeX 源代码和其他格式。

许可证信息：查看许可证。

当前浏览上下文：cs.LG

参考文献和引用：NASA ADS、Google Scholar、Semantic Scholar 等。

导出 BibTeX 引用：正在加载…

与本文相关的代码、数据和媒体：alphaXiv、CatalyzeX Code Finder for Papers、DagsHub、GotitPub、Huggingface、Papers with Code、ScienceCast 等。

演示：Replicate、Hugging Face Spaces、TXYZ.AI 等。

相关论文推荐：Influence Flower、CORE Recommender、IArxiv Recommender 等。

关于 arXivLabs：arXivLabs 是一个框架，允许合作伙伴在 arXiv 网站上直接开发和共享新的 arXiv 功能。arXiv 致力于开放性、社区、卓越和用户数据隐私的价值观，并只与遵守这些价值观的合作伙伴合作。

HN 热度 197 points | 评论 54 comments | 作者：archon1410 | 1 day ago #

https://news.ycombinator.com/item?id=44271284

  • NEAT/HyperNEAT 算法与本文描述的算法都旨在解决同一问题，但前者进化网络结构，后者进化权重。
  • 自我编辑方法通过强化学习优化模型自身学习信息重构方式，不同知识类型需要不同表示方式。
  • 模型发现更好的训练格式而不仅仅是更多数据，但灾难性遗忘问题仍未解决。
  • 计算开销大，每奖励评估需 30-45 秒，对大多数用例不实用，但对高价值文档处理可能值得。
  • 限制在于需要明确的评估指标，适用于可以生成评估的技术文档或教育内容领域。
  • 大型语言模型（LLMs）强大但静态，缺乏适应新任务的机制，学习与推理过程完全分离。
  • 强化学习可以用于细化 LLM，如 Deepseek 所示。
  • 用户对输出的正负反馈可以用来训练 LLM，以输入和输出进行训练。
  • 从 Anthropic 的自我微调研究，模型可以比人类更好地训练新模型。
  • 研究如何让 LLMs 在工作中学习，以及实现这一目标的障碍，如成本、模型崩溃等。
  • 我们不知道如何实现持续学习，需要在保持原有表示空间几乎不变的情况下扩展模型的表示空间。
  • AI 可能需要“睡眠”或休息来实现持续学习。

SIMD-friendly algorithms for substring searching (2018) #

http://0x80.pl/notesen/2016-11-28-simd-strfind.html

这篇文章由 Wojciech Muła 撰写，主要讨论了字符串搜索算法在 SIMD（单指令多数据）指令集优化下的应用。文章首先介绍了在流行编程语言中用于定位字符串中子串的方法，如 C 语言的 strstr 函数、C++ 的 std::string 类的 find 方法、Python 的字符串方法 pos 和 index 等。这些方法都是为一次性搜索设计的。过去几十年中，出现了许多解决这一问题的算法，这些算法大致可以分为两类：基于确定性有限自动机（DFA）的算法，如 Knuth-Morris-Pratt、Boyer-Moore 等；以及基于简单比较的算法，如 Karp-Rabin 算法。

文章指出，这些标准算法的一个主要问题是它们默认比较字符对、查找额外表和条件是廉价的，而比较两个子串是昂贵的。但现代桌面 CPU 并不满足这一假设，尤其是在 64 位 CPU 上，比较 1、2、4 或 8 字节没有区别。当处理器支持 SIMD 指令时，比较向量（即 16、32 或 64 字节）的成本与比较单个字节一样低。因此，比较短字符序列可以比避免这种比较的复杂算法更快。

文章接着介绍了两种利用 SIMD 指令的方法，这两种方法已经在 SIMD-friendly Rabin-Karp 修改和 SSE4 字符串搜索中描述过。文章合并了这些内容，比较了这两种方法，并扩展了材料。文章还展示了从 SWAR 到 AVX512F 的各种实现的性能结果。

Karp-Rabin 算法在弱哈希相等时执行精确的子串比较。一个哈希是为搜索的子串计算的，另一个是为字符串的部分计算的；在每次迭代中，第二个哈希以很小的成本更新。SIMD 解决方案用向量谓词替换哈希谓词，该谓词是并行计算的，并且希望计算得快。

文章详细介绍了“通用 SIMD”算法，该算法适用于所有 SIMD 指令集和 SWAR 方法。它使用子串的第一个和最后一个字符作为谓词。这两个字符分别填充在两个寄存器 F 和 L 中。然后在每次迭代中加载两个字符串块。第一个块（A）从偏移量 i 读取，第二个块（B）从偏移量 i + k - 1 读取，其中 k 是子串的长度。然后计算向量表达式 F == A 和 B == L。这一步产生一个字节向量（或位掩码），其中“真”值表示潜在子串出现的位置。最后，仅在这些位置执行子串的精确比较。

文章还讨论了如何选择子串的第一个和最后一个字符，以及如何实现 SSE 和 AVX2 版本。SSE 和 AVX2 版本实际上是一样的，都使用最少的指令数量。文章还提到，由于我们已经知道第一个和最后一个字符匹配，我们不需要再次使用 memcmp 与它们进行比较。

最后，文章介绍了 SWAR 方法，它使用位异或操作进行等式比较，当两个字节相等时结果为零。因此，不是对部分结果进行与操作，而是使用位或操作。SWAR 需要更多的工作来定位零字节。文章提供了一个 C++ 实现，用于 64 位向量，并讨论了循环中的一个额外条件，虽然看起来不太优化，但是搜索第一个设置的位然后清除它（如 SSE 版本所做的）会更慢。

HN 热度 179 points | 评论 28 comments | 作者：Rendello | 18 hours ago #

https://news.ycombinator.com/item?id=44274001

  • ripgrep 使用 Rust 的 regex crate 加速搜索，即使是简单正则表达式也能从中受益。
  • SIMD 优化的字符串搜索算法比传统的 Two-Way 或 GNU libc 的 memmem 实现更快。
  • 算法通过背景频率分布来选择两个出现频率较低的字节，而不是总是使用模式串的第一个和最后一个字节。
  • SIMD 算法的实现通常不考虑边界情况，导致未定义行为（UB）。
  • 在实际应用中，处理边界情况可能非常痛苦，除非有非常具体的使用场景，否则不愿触碰 SIMD 字符串搜索。
  • C# 也在 IndexOf 方法中实现了一些 SIMD 优化。
  • 对于已知的 haystack 长度和大的模式串，结合 Quick Search 方法可能更有用。
  • 有多种不同的 SIMD 方法用于搜索和分割字符串。
  • LZ77 窗口搜索的修改版尝试使用 Zig 的通用 SIMD。
  • 使用 SIMD 算法的 hparse 用于快速 HTTP 解析。
  • swar 算法由于将 1 字节对齐的数据强制转换为 8 字节对齐，可能存在未定义行为。
  • 理想化的 SIMD 算法或伪代码通常不考虑边界条件的正确处理。
  • musl 的 strstr 性能优于 libc，但 SIMD 算法与之相比仍有提升空间。
  • SIMD 算法在处理大型、周期性的模式串时可能变得二次方复杂度，而避免二次方行为的算法设置成本更高。
  • 对于小字符串，SIMD（对齐、大小计算等）的设置代码通常比字节导向的基本搜索更昂贵。

Implementing Logic Programming #

https://btmc.substack.com/p/implementing-logic-programming

这篇文章讨论了逻辑编程的实现，作者 Sir Whinesalot 介绍了逻辑编程与其他编程范式（如过程式编程、面向对象编程和函数式编程）的不同之处。尽管逻辑编程不如其他三种范式流行，但它在解决某些特定类型的问题时非常有效。

逻辑编程概述 #

逻辑编程不同于传统编程范式，它不通过函数来定义程序，而是通过关系（或谓词）来进行编程。在逻辑编程中，没有明显的输入和输出的区分，关系的定义是灵活的，可以根据需要进行解释。

Prolog 示例 #

作者以 Prolog 作为示例，展示了如何定义简单的事实和规则。通过定义诸如 “male” 和 “female” 的谓词，程序可以表示某些人的性别。此外，通过定义 “parent” 谓词，可以建立父母与子女之间的关系。

作者还介绍了如何创建规则，例如 “father (X, Y) :- male (X), parent (X, Y)” 表示如果 X 是男性且是 Y 的父母，那么 X 就是 Y 的父亲。

查询 #

通过 Prolog 的查询机制，用户可以提出问题，比如查找特定人的父亲或所有父亲与子女的配对。这种灵活性和强大的查询能力是逻辑编程的一大优势。

递归与复杂关系 #

逻辑编程允许使用递归来定义更复杂的关系，例如祖先关系。作者通过定义 “ancestor (X, Y)” 展示了如何用递归来推导出家庭关系。

逻辑编程的局限性 #

尽管 Prolog 功能强大，但它也有一些限制，例如执行顺序可能影响结果，且 Prolog 本身并不是完全声明性的。执行过程中的不确定性使得编写 Prolog 程序时需要小心处理。

Datalog 的介绍 #

作者转而关注 Datalog，这是一种 Prolog 的子集，不具备图灵完备性。Datalog 专注于建模关系，并且更易于优化和终止。尽管 Datalog 不能开发完整的应用，但它在数据库查询方面的应用潜力巨大，作者认为它应该取代 SQL 作为数据库的主要语言。

Datalog 的实现 #

作者提出了一种简单的 Naïve Evaluation 算法来实现 Datalog。这是一种自底向上的固定点算法，通过不断应用规则直到没有新事实可以推导为止。文章中包含了 Python 代码示例，展示了如何定义变量、值和谓词等基础结构，以及如何管理 “数据库”。

具体实现分为几个类：

  1. Variable: 表示变量。
  2. Atom: 表示谓词的使用，包括谓词名称和参数。
  3. Rule: 表示规则，包含头部和体部。
  4. Predicate: 表示谓词，包含事实和规则的集合。
  5. Datalog: 管理整个 Datalog 数据库，允许添加变量、谓词、事实和规则。

结论 #

文章强调了逻辑编程在建模复杂关系中的优势，并通过 Datalog 的实现示例展现了逻辑编程的潜力。尽管逻辑编程在主流编程中并不常见，但它在某些特定领域（如数据库和关系推理）中仍然具有重要价值。

HN 热度 175 points | 评论 56 comments | 作者：sirwhinesalot | 24 hours ago #

https://news.ycombinator.com/item?id=44272467

  • miniKanren 和 microKanren 是学习逻辑编程的好资源，能够以较少的代码实现完整的逻辑编程引擎。
  • SICP 4.4 提供了易于理解的逻辑编程实现，适合初学者入门。
  • Datalog 不仅适用于数据库，也是理解逻辑编程的好工具。
  • 通过 SICP 学习 Prolog 实现，可以深入了解逻辑编程的内部工作机制。
  • Scheme 语言的同构性（homoiconicity）使得创建逻辑编程语言如 quine 更加容易。
  • 有简化版的 Datalog 实现，可以在牺牲一些功能的情况下获得更简单的语法和非线性变量使用。
  • 可以将 Datalog 程序翻译成 SQL 以利用数据库引擎的功能性和性能。
  • 通过 Python AST + Z3 实现 Datalog 引擎是一种有趣的尝试。
  • 可以将 Datalog 翻译成 PostgreSQL 的递归公共表表达式（CTE）以减少数据库往返。
  • 递归 CTE 可能比逐个查询执行数据逻辑迭代更高效。
  • 需要一些离散数学知识来理解逻辑编程。
  • Brachylog 是一种用于代码高尔夫的逻辑编程语言，提供了不同寻常的解决问题方法。
  • 通过 miniKanren 实现小型类型检查器，可以枚举满足特定类型的程序。
  • 存在尝试使类型安全的 LLM 生成成为可能的研究工作。

The Tech Job Meltdown #

https://www.professoraxelrod.com/p/the-tech-job-meltdown

这篇文章讨论了 2023 年以来超过 50 万科技工作者被裁员的现象，并分析了背后的原因。文章指出，这并非由 COVID、技术工人表现不佳、AI 技术提高效率、过度招聘或 H1B 工人问题等常见原因引起，而是与零利率政策（ZIRP）的结束和资本成本上升有关。这导致风险投资变得不那么吸引人，新公司的资金减少，现有公司更难借到资金。

文章进一步分析了美国国内税收法典第 174 节对研发（R&D）支出的税收处理规定。过去 70 年，美国公司可以立即扣除 100% 的“合格研发支出”，这对创造或改进产品的贡献可以作为税收减免。这种政策促进了美国科技的繁荣，包括贝尔实验室、微软、苹果、谷歌和 Facebook 等。然而，2017 年的《减税与就业法案》（TCJA）修改了第 174 节，从 2022 年开始，研发支出必须在 5 年内摊销（国内研究）和 15 年内摊销（外国研究）。这一变化取消了立即扣除研发成本的选项，短期内增加了公司的税收负担。

文章解释了这一规则变化如何增加了企业的应税收入，因为它们不能再立即扣除研发成本。这导致了现金流紧张，尤其是对于依赖研发的初创企业和小型科技公司。为了应对税收负担，公司不得不采取裁员等措施。例如，一家小公司可能会解雇一名年薪 20 万美元的软件工程师，以支付 18.9 万美元的税单。

文章还提到，尽管 15 年的外国研发支出摊销期可能会使雇佣非美国工程师变得不那么具有税收优势，但实际上并没有带来预期的效果。相反，大公司通过将研发外包到税收制度更有利的国家来应对，导致美国工作岗位的流失。例如，谷歌将部分工作转移到德国，微软将大量研究工作转移到中国，这不仅是因为那里的薪酬更好，还因为当地子公司遵循的是所在国的法律，而不是美国的税法。

最后，文章指出，2017 年通过的《减税与就业法案》（TCJA）是特朗普总统任期内的标志性立法成就，它将公司税率从 35% 降低到 21%，这在纸面上看起来像是联邦政府的巨大收入损失。为了使 2017 年的法案符合参议院预算规则，立法者不得不采取一些措施来抵消这一损失，其中包括修改第 174 节。这一税收策略的结果是，美国工程师被裁员，同时公司在国外重组运营。这并没有按照计划进行。

HN 热度 164 points | 评论 69 comments | 作者：mooreds | 19 hours ago #

https://news.ycombinator.com/item?id=44273790

  • 文章标题具有误导性，内容主要是关于废除第 174 节的论点，而非工作趋势。
  • 作者认为第 174 节是导致技术行业衰退的原因之一，但并非全部原因。
  • 有观点认为，将工作职能转移到海外是裁员的主要原因，而不仅仅是第 174 节。
  • 有人指出，行业成熟度、缺乏新的平台发展以及疫情后对更自信工人的反弹也是导致技术行业衰退的因素。
  • 有人认为第 174 节的影响相对较小，废除它可能不会带来太大变化。
  • 有人提到，2022 年许多事件同时发生，包括疫情影响减弱、隐私政策变化、全球经济氛围、利率上升等，这些都对技术行业产生了影响。
  • 有人指出，参议院正在考虑的拨款法案已经废除了第 174 节。
  • 有人对 HN 上关于第 174 节的讨论表示不满，认为这些讨论忽略了法案已经在预算法案中通过的事实。
  • 有人质疑为什么第 174 节的讨论没有提到它包含在大型预算法案中，这可能是因为法案包含了许多其他不受欢迎的内容。
  • 有人反对第 174 节的变化，认为这将有利于他们的职业，不应该因为其他人可能从中受益更多而反对。
  • 有人指出，大型综合法案是一种故意模糊的立法方式。
  • 有人提到，外国软件工程师的劳动有 15 年的摊销期。
  • 有人质疑为什么文章没有提到特朗普的“大美丽法案”，因为它还包含许多其他有争议和不受欢迎的内容。

Google Cloud Incident Report – 2025-06-13 #

https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

Google Cloud 服务平台健康事件：多个 GCP 产品遭遇服务问题

服务健康页面提供了 Google Cloud 服务的状态信息。如果遇到未列在此页面的问题，请联系支持。更多服务信息，请访问 https://cloud.google.com/。

受影响的服务包括 API Gateway、Agent Assist、AlloyDB for PostgreSQL、Apigee、Apigee Edge Public Cloud、Apigee Hybrid、Cloud Data Fusion、Cloud Firestore、Cloud Logging、Cloud Memorystore、Cloud Monitoring、Cloud Run、Cloud Security Command Center、Cloud Shell、Cloud Spanner、Cloud Workstations、Contact Center AI Platform、Contact Center Insights、Data Catalog、Database Migration Service、Dataform、Dataplex、Dataproc Metastore、Datastream、Dialogflow CX、Dialogflow ES、Google App Engine、Google BigQuery、Google Cloud Bigtable、Google Cloud Composer、Google Cloud Console、Google Cloud DNS、Google Cloud Dataflow、Google Cloud Dataproc、Google Cloud Pub/Sub、Google Cloud SQL、Google Cloud Storage、Google Compute Engine、Identity Platform、Identity and Access Management、Looker Studio、Managed Service for Apache Kafka、Memorystore for Memcached、Memorystore for Redis、Memorystore for Redis Cluster、Persistent Disk、Personalized Service Health、Pub/Sub Lite、Speech-to-Text、Text-to-Speech、Vertex AI Online Prediction、Vertex AI Search、Vertex Gemini API、Vertex Imagen API、reCAPTCHA Enterprise。

多个 GCP 产品遭遇服务问题，事件始于 2025 年 6 月 12 日 10:51，结束于 2025 年 6 月 12 日 18:18（均为美国太平洋时间）。受影响地区包括约翰内斯堡、亚洲多区域、台湾、香港、东京、大阪、首尔、孟买、德里、新加坡、雅加达、澳大利亚多区域、悉尼、墨尔本、欧洲多区域、华沙、芬兰、斯德哥尔摩、马德里、比利时、柏林、都灵、伦敦、法兰克福、荷兰、苏黎世、米兰、巴黎、全球、多哈、达曼、特拉维夫、蒙特利尔、多伦多、墨西哥、圣保罗、圣地亚哥等。

2025 年 6 月 13 日 16:45 PDT 发布的事件报告摘要：

Google Cloud、Google Workspace 和 Google Security Operations 产品遭遇了增加的 503 错误，影响了外部 API 请求的客户。我们对此次中断给客户带来的影响深表歉意，并承诺将做出改进，避免类似情况再次发生。

发生了什么？

Google 和 Google Cloud API 通过我们的 Google API 管理和控制平面提供服务。这些管理和控制平面分布在各个区域，负责确保每个进来的 API 请求都经过授权，并符合策略和适当的检查（如配额）。核心的二进制文件，即服务控制（Service Control），是一个区域性服务，它从区域数据存储中读取配额和策略信息。这些数据存储的元数据几乎瞬间全球复制，以管理 Google Cloud 和客户的配额策略。

2025 年 5 月 29 日，服务控制增加了一个新的功能，用于额外的配额策略检查。这个代码变更和二进制文件发布是逐区域推出的，但由于需要一个策略变更来触发代码，失败的代码路径在推出过程中从未被执行。作为安全预防措施，这个代码变更附带了一个“红色按钮”来关闭特定的策略服务路径。

问题在于这个变更没有适当的错误处理，也没有用特性标志保护。没有适当的错误处理，空指针导致二进制文件崩溃。特性标志用于逐步启用每个区域的项目中的新功能，从内部项目开始，以便我们能够捕捉问题。

如果在 2025 年 6 月 12 日大约上午 10:45 PDT，一个策略变更被插入到服务控制用于策略的区域 Spanner 表中。鉴于配额管理的全球性质，这个元数据在几秒钟内全球复制。这个策略数据包含了意外的空白字段。服务控制随后在每个区域数据存储中对策略进行配额检查。这引入了相应策略变更的空白字段，并执行了导致二进制文件进入崩溃循环的代码路径。由于每个区域部署，这在全球范围内发生。

我们的网站可靠性工程团队在 2 分钟内开始处理此事件。10 分钟内，确定了根本原因，并开始实施“红色按钮”（禁用服务路径）。“红色按钮”准备在事件开始后约 25 分钟内推出。在事件发生后的 40 分钟内，“红色按钮”推广完成，我们开始看到区域恢复，首先是较小的区域。

在一些较大的区域，如 us-central-1，随着服务控制任务的重新启动，它对依赖的底层基础设施（即 Spanner 表）产生了羊群效应，导致基础设施过载。服务控制没有适当的随机指数退避实现以避免这种情况。在 us-central-1 完全解决需要大约 2 小时 40 分钟，因为我们限制了任务创建以最小化对底层基础设施的影响，并将流量路由到多区域数据库以减少负载。那时，服务控制和 API 服务在所有区域都已完全恢复。

相应的 Google 和 Google Cloud 产品开始恢复，一些产品根据其架构需要更长的时间。

我们立即的前进路径是什么？

恢复后，我们冻结了对服务控制堆栈的所有更改，并暂停手动策略推送，直到我们能够完全修复系统。

我们如何沟通？

我们在崩溃开始后约 1 小时发布了第一份事件报告到云服务健康，由于云服务健康基础设施因此次中断而宕机。对于一些客户来说，他们在 Google Cloud 上运行的监控基础设施也失败了，使他们没有事件的信号或对他们的业务和/或基础设施的影响的理解。我们将解决这个问题。

我们的前进方法是什么？

除了上述冻结系统外，我们将优先并安全地完成以下工作：

我们将模块化服务控制的架构，使功能隔离并开放失败。因此，如果相应的检查失败，服务控制仍然可以…

HN 热度 160 points | 评论 147 comments | 作者：denysvitali | 15 hours ago #

https://news.ycombinator.com/item?id=44274563

  • Google Cloud 的事故报告揭示了其在错误处理、测试覆盖和逐步推出等方面的不足，有人质疑 Google 的标准是否已经下降。
  • 有人猜测，大规模裁员和 CEO 对员工的指责可能导致员工更注重速度而非质量，从而影响了公司文化。
  • 有人认为，FAANG 公司并非工程能力的巅峰，他们的标准和成就更多是基于他们需要解决的问题。
  • AWS 在客户数据隔离方面几乎没有事故，相比之下 AWS 的安全性能较为稳固。
  • 有人认为，尽管 FAANG 公司雇佣了一些优秀的专家，但这并不意味着他们在整体工程能力上就是顶尖的。
  • 有人讽刺说，每当听到有公司使用 Azure，他就会去公共泄露网站检查他们的数据。
  • 有人认为，由于项目没有分配足够的工程资源来支持更健壮和弹性的部署模式，导致部署失败，但这并不意味着工程师无能。
  • 有人指出，Google Cloud 的全球性故障通常都是由于快速部署配置错误导致的，但 Google Cloud 在这方面已经有所改进。
  • 有人提出，应该对全局配置推出有更高的标准，以避免最佳实践被绕过。
  • 有人表示，用户通常要求配额更新要快且跨区域一致，这导致人们更重视用户体验而非可用性。
  • 有人引用了 1864 年的一份报告，指出即使是危险的工具，人们在熟悉后也会逐渐失去最初的谨慎。
  • 有人提到，航空业的高可靠性和高标准反驳了上述观点。

Last fifty years of integer linear programming: Recent practical advances #

https://inria.hal.science/hal-04776866v1

这篇文章是关于整数线性规划（Integer Linear Programming, ILP）在过去五十年的发展历程，特别关注近期在实际应用中的进展。文章发表在《欧洲运筹学杂志》（European Journal of Operational Research）上，作者是 François Clautiaux 和 Ivana Ljubić。

文章首先指出，混合整数线性规划（Mixed-Integer Linear Programming, MILP）已经成为运筹学的一个基石。这得益于现代求解器效率的提高，使得求解器能够在几秒钟内找到十年前无法解决的问题的全局最优解。这些求解器的多功能性使得它们在交通、物流、供应链管理、收益管理、金融、电信和制造业等多个领域得到成功应用。

尽管已经取得了令人印象深刻的成功，但文章指出 MILP 领域仍面临许多挑战，并且是一个非常活跃的研究领域。文章提供了 MILP 解决方案方法中取得的最显著成果的概述。鉴于这一主题的文献量巨大，作者有意识地选择关注计算方面和近期的实际性能改进，强调报告计算实验的研究。

文章将调查内容组织成三个主要部分，分别致力于分支定界法（Branch-and-Cut）、Dantzig-Wolfe 分解和 Benders 分解。文章最后强调了 MILP 研究中正在进行的挑战和未来的机遇。

关键词包括组合优化（Combinatorial Optimization）、混合整数线性规划（Mixed-Integer Linear Programming）、分支定界法（Branch-and-Cut）、Dantzig-Wolfe 分解和 Benders 分解。这些关键词涵盖了文章讨论的主要技术和方法。

文章的元数据提供了文件和预览信息，包括主要文件的下载链接，以及作者 François Clautiaux 和 Ivana Ljubić 的联系信息和 ORCID 标识符。文章的提交日期为 2024 年 11 月 12 日，最后一次修改日期为 2025 年 3 月 18 日。文章的 HAL 标识符为 hal-04776866，DOI 为 10.1016/j.ejor.2024.11.018。文章被归类在计算机科学和数学领域。

HN 热度 151 points | 评论 44 comments | 作者：teleforce | 15 hours ago #

https://news.ycombinator.com/item?id=44274567

  • 商业整数线性规划（ILP）求解器（如 Gurobi）之所以优于免费/开源求解器，是因为它们与客户紧密合作，实施针对特定问题的加速优化，包括启发式方法和定制切割策略。
  • 研究人员在运筹学领域通过编写自己的切割和启发式方法，经常能够轻松击败 Gurobi 等求解器，而求解器公司通过雇佣博士和研究人员团队持续进行这种优化。
  • 开源求解器受限于多个问题，包括进入最先进优化器开发领域的门槛高、能够贡献的研究人员/开发者少，以及开源项目不太可能获得改进求解器所需的示例、性能数据和分析。
  • 现代 SAT 求解器是 NP 难问题中不仅仅是启发式的好算法的例子，CDCL 算法就是其中之一。
  • 大型商业求解器拥有资源和客户支持，投入大量时间调整求解器以适应现实世界问题，包括识别可以反馈到完整问题的更简单的子问题或近似解。
  • 在需要优化的领域，如量化交易公司，开源求解器往往无法解决大型问题，导致内存溢出等错误。
  • 在实践中，求解器被广泛应用于调度家庭电池和电动汽车、优化成千上万家庭的组合以及交易这些组合。
  • 欧盟电力现货价格的设定就是通过一个大型求解器运行来实现的，Euphemia 项目对此有所介绍。
  • 尽管有尝试使用机器学习/人工智能方法解决这些问题的例子，但通常最好的选择仍然是购买 Gurobi 许可证并使用它。
  • 有人提到，与 20 年前相比，现在的求解器在算法和计算能力上都有了显著提升，使得求解时间大幅缩短。
  • 有人询问 Gurobi 的定价细节，但因为保密无法分享，不过提到有免费的开源/非商业用途的 MIP 求解器可供使用。
  • Gurobi 提供临时免费许可证，限制在 1000 节点问题大小以内，适合学习和试用。
  • 有人询问开源求解器与 lp_solve 的比较情况。