基于FFT的海洋波浪渲染（Godot引擎实现）

这是一个在Godot引擎中进行的开放式海洋渲染实验，它利用方向性海洋波浪谱的逆傅里叶变换来生成波浪。该方法通过一组简洁的参数暴露出来，允许通过脚本实时修改波浪属性，以模拟多种海洋波浪环境。

1. 引言：为什么使用傅里叶变换？

传统的游戏水体动画多采用Gerstner波，适合表现平静水面的低频细节，但难以准确模拟开放海洋的复杂波涛表面。而基于傅里叶变换的方法，利用海洋学家根据经验数据建模的海洋波浪谱进行模拟，能更真实地生成复杂波浪。

使用海洋波浪谱在频率空间工作的一大优势是：可以轻松修改海洋属性（如表面波涛程度）。调整Gerstner波的参数来模拟特定海洋状态往往不直观，而海洋波浪谱暴露的参数则能直接改变波浪属性。

计算傅里叶变换时采用快速傅里叶变换（FFT）算法。相比经典离散傅里叶变换算法的 O(N²) 复杂度，FFT 的复杂度为 O(N log N)，且具备可扩展的并行特性，非常适合在GPU上运行。Gerstner波要求每个线程进行N次计算（每个波浪一次），而基于FFT的波浪每个线程仅需进行 log(N) 次等效计算。在规模上，可以在相同性能开销下添加更多波浪，从而实现更精确的表面模拟。

2. 结果与渲染

2.1 波浪着色

• 光照模型：主要遵循GDC演讲《Atlas》中描述的BSDF，但使用GGX分布（而非Beckmann分布）作为微面分布，因其“更平坦”、更柔和的高光在多数测试环境中能提供更均匀的外观。
• 法线/泡沫贴图过滤：根据世界空间像素密度（取决于法线贴图纹理分辨率和纹理UV平铺大小），在双三次和双线性过滤之间进行混合采样，有效减少低分辨率下的纹理锯齿，同时在高分辨率下保持细节。

2.2 海泡沫

• 根据Tessendorf提出的方法，当波浪峰部向内卷曲（即位移的雅可比行列式为负）时生成海泡沫。
• 泡沫在纹理上线性累积、指数消散，分别由“泡沫增长速率”和“泡沫衰减速率”参数控制。

2.3 海浪飞沫

• 使用Godot的 GPUParticles3D 节点和自定义粒子着色器进行建模。
• 粒子在节点边界框内均匀分布，然后根据其位置的泡沫量进行剔除。未被剔除的粒子从一个随机偏移开始其生命周期。
• 每个粒子使用带有静态纹理的广告牌精灵。在其生命周期内，通过修改粒子的缩放和位移来模拟飞溅外观，并利用粒子网格着色器中的溶解效果模拟海浪飞沫在空气中的雾化。
• 主要缺点：由于粒子均匀分布，大量粒子会被剔除，导致仅增加粒子数量只能小幅度提升海浪飞沫密度。

3. 波浪模拟

波浪生成方法密切遵循Tessendorf的方法。将一个方向性海洋波浪谱函数与高斯分布随机数相乘，生成初始频谱海况。然后通过色散关系（关联波浪频率和传播速度）随时间传播初始状态。最后对传播后的状态应用逆傅里叶变换，生成位移和法线贴图。

该流程通过一个使用Godot RenderingDevice 抽象的计算着色器管线实现。

3.1 海洋波浪谱

方向性海洋波浪谱函数 S(ω, θ) 给定波浪的频率 (ω) 和方向 (θ) 返回其能量。它由一个非方向谱函数 S(ω) 和一个方向扩展函数 D(ω, θ) 组成，两者选择完全独立。

• 非方向谱函数：选择Horvath描述的Texel-Marsen-Arsloe (TMA) 谱。给定风速 (U)、水深 (D) 和风区长度（离岸距离）(F)，TMA谱将其前身JONSWAP谱与水深衰减函数结合。
• 方向扩展函数：选择Horvath描述的平坦和Hasselmann方向扩展的混合（由‘spread’参数 μ 控制），并引入‘swell’参数 ξ 来模拟波浪拉长。选择Hasselmann方向扩展是因为其对归一化因子 Q(σ) 有近似的解析解。
• 遵循Tessendorf的建议，最终谱函数还乘以一个小波抑制项 exp(-k²(1-δ)²)（给定波矢量大小 k 和‘detail’参数 δ）。

最终方向性海洋波浪谱函数为： S(ω, θ) = S_TMA(ω) * D_mixed(ω, θ) * exp(-k²(1-δ)²)

3.2 快速傅里叶变换

为GPU编写了一个自定义FFT实现，使用计算着色器。采用 Stockham FFT算法（而非Cooley-Tukey算法）以避免初始的比特反转排列。参考Flügge的方法，在频谱纹理分辨率改变时计算一次**“蝶形”纹理**，编码FFT的数据流。

• FFT核首先逐行应用于频谱纹理，执行2D FFT。
• 然后使用计算着色器转置纹理，使得同一行FFT核可以有效地重复用于逐列FFT。这种转置也改善了内存访问模式并实现了管线复用。

3.3 波浪级联

在足够远的距离（尤其存在海泡沫时），平铺瑕疵非常明显。波浪生成系统允许同时叠加多个波浪级联来解决此问题。每个级联有自己的平铺大小和参数集。级联可以在运行时动态添加/移除。然而，由于所有级联使用相同的计算管线，它们必须具有相同的频谱纹理分辨率。另一种替代方案是将波浪位移/法线与噪声混合以减少瑕疵（性能开销更小）。

• 每个级联的参数和大小需精心选择，以避免叠加时的波浪干扰。
• 生成系统尝试通过将每个级联的开始时间设置为不同偏移来自动实现波浪相位偏移（作者不确定是否有效）。

3.4 负载均衡

由于波浪运动的不可预测性，即使不每帧更新其位移，其运动看起来也可能很平滑。因此引入了**“更新速率”参数**来控制每秒更新波浪级联的频率。这减少了GPU用于FFT的工作时间，但在运行波浪生成管线的帧中仍会出现卡顿。

• 尝试使用Godot的本地 RenderingDevices 异步计算级联更新，但由于在CPU和GPU之间传输纹理而导致显著的性能开销。
• 因此，波浪生成系统尝试负载均衡。当帧时间短于更新速率时，每帧只更新一个级联。这在保持较低GPU工作负载（因跳帧）的同时，减少了卡顿。

4. 总结

通过对方向性海洋波浪谱函数（及其相关参数）应用FFT后生成的位移、法线和泡沫贴图，能够在广泛的海洋波浪环境中产生逼真的表面运动。

5. 主要参考文献

• Flügge, F. (2017). 实时GPGPU FFT海洋水体模拟。
• Horvath, C. J. (2015). 用于计算机图形的经验方向性波浪谱。
• Tessendorf, J. (2004). 模拟海水。
• Mihelich, M. (2019). 《Atlas》中的交互式水体模拟（GDC演讲）。

本文核心内容是对尼尔·波兹曼《娱乐至死》一书序言的解读与提炼，重点对比了乔治·奥威尔《一九八四》与奥尔德斯·赫胥黎《美丽新世界》对社会未来的两种预言。波兹曼指出，奥威尔警告的是外部强加的压迫（如审查、信息剥夺、真理隐藏），人们会因憎恨之物而毁灭；赫胥黎则预见人们可能因沉迷娱乐和技术而自愿放弃自主与深度思考，因热爱之物（如信息过载、琐碎娱乐）而丧失严肃性。波兹曼认为，赫胥黎所描绘的“娱乐至死”社会更贴近现实。文章附图进一步视觉化呈现了这两种预言的差异。作者最后隐含呼吁读者警惕赫胥黎式预言，并反思自身是否已陷入无意识的被动状态。

Python 3.13 核心变革：可选的GIL与实验性JIT

2024年10月发布的CPython 3.13.0是一个重大版本，引入了两项可能从根本上改变Python未来性能的重大底层变化：可禁用的全局解释器锁（GIL） 和 实验性的即时编译器（JIT）。

1. 全局解释器锁（GIL）的可选化

• 什么是GIL？ GIL是CPython中的一个互斥锁，确保在任何时刻只有一个线程可以执行Python字节码。这简化了CPython的实现（特别是内存管理和C扩展开发），并保证了单线程程序的性能，但牺牲了多线程在CPU密集型任务上的并行能力。
• 为何现在要改变GIL？ 随着多核CPU成为主流，Python无法利用多线程进行CPU密集型计算的缺点日益凸显。同时，“Faster CPython”项目提升了单线程性能，社区推动去除GIL的呼声也得到响应。
• 新的“free-threading”模式 Python 3.13引入了实验性的构建选项，允许创建禁用GIL的CPython版本。这是实施PEP 703（使GIL成为可选）三阶段计划的第一步：目前只是可选的实验功能，未来可能成为默认设置，最终可能完全移除GIL。
• 性能影响 基准测试显示：
  • 启用free-threading构建的Python，其单线程性能会下降约20%（无论运行时是否通过-X gil=1重新启用GIL）。
  • 在禁用GIL（-X gil=0）的情况下，多线程性能显著提升，接近于使用多进程（multiprocessing）的性能，尤其是在CPU密集型任务（如曼德勃罗集计算）中。
  • 需注意：默认情况下，导入不支持GIL-free的库（如matplotlib）会重新启用GIL，需手动指定-X gil=0以强制保持禁用状态。

2. 实验性即时编译（JIT）编译器

• 什么是JIT？ JIT是一种在程序运行时将字节码编译为本地机器码的技术，旨在提高性能。传统的CPython解释器每次都解释执行字节码，而JIT可以缓存编译结果。
• Python 3.13的JIT特点 本次引入的是**“copy-and-patch”JIT**，这是一种新型的轻量级JIT方法。它使用预先生成的机器码模板，通过模式匹配将字节码“粘贴”并修补为机器码，相较于传统的JIT（如Java中的），它更简单且内存占用更低。
• 当前状态与展望 JIT在3.13中仍是实验性的，需要在编译时通过PYTHON_CONFIGURE_OPTS="--enable-experimental-jit"启用。目前它不太可能带来立竿见影的性能提升，但为未来通过更复杂的优化逐步提升Python性能奠定了基础。

总结与尝试

• 总结：Python 3.13通过引入可选的free-threading模式和实验性JIT编译器，为解决Python在并行计算和执行速度方面的长期瓶颈迈出了重要一步。这些变化短期内不会改变大多数用户的编码方式，但为未来的性能提升开辟了道路。
• 如何尝试：
  • Free-threading版本：可使用pyenv install 3.13.0rc2t安装，并通过-X gil=0运行以确保GIL禁用。
  • JIT版本：需在编译Python时使用--enable-experimental-jit选项，并可通过PYTHON_JIT=0环境变量控制其启用状态。

注意：文章中的基准测试（对比3.12、3.13默认版、free-threading版在不同线程/进程下的性能）揭示了禁用GIL带来的多线程增益以及单线程的性能代价。Apple Silicon芯片在单线程性能上表现突出。所有测试均基于非正式的简单算法，并非全面的性能评估。

AMD社区扩展计划概述

AMD宣布其社区正进入一个激动人心的新阶段——发展成为一个更广泛的生态系统，旨在更好地支持和连接用户。

核心资源与支持

AMD提供了一系列资源，旨在让用户保持信息畅通和紧密连接，主要包括：

• 支持渠道
• 知识库
• 反馈、工具和新闻中心

主要平台与社区

AMD建立了多个专门的平台和社区，以服务不同的用户群体：

• 开发者中心：提供工具、文档和支持，帮助在人工智能、游戏、高性能计算和图形等领域构建高性能应用程序。
• 技术博客：提供关于人工智能、优化和计算领域的见解、教程和最佳实践。
• AMD校友社区：为前AMD员工提供一个与旧同事重新联系、重温回忆和共同庆祝所建立遗产的新家园。
• 游戏社区：一个面向游戏玩家、PC组装者和创作者的社区网站，旨在利用AMD技术进行游戏、创造和引领。
• 开发者社区：为与各种开发者相关的兴趣和话题提供点对点支持。（即将推出）

Discord社区服务器

AMD已建立Discord服务器，以连接全球的开发者和用户：

• AMD开发者社区Discord服务器：连接开发者与AMD工作人员，围绕硬件、软件工具、技术、开源开发等进行交流。
• AMD游戏Discord服务器：连接游戏玩家、PC组装者和创作者，共同游戏、组装并分享所有与AMD相关的事物。

文本编辑器由开发者编写并为开发者使用，其在布局、排版、着色和交互方面包含大量默认和隐含选择，这些选择在各类编辑器间几乎保持不变。目前尚不清楚这些隐含选择是源于对替代方案的缺乏了解，还是源于开发者习惯的延续。本文旨在详细描述这些隐含选择，并展示一些可能的替代方案，而不对任何特定方案进行推荐或规定。

《刻意练习在创造力发展中的作用》(2014) 文章概要

文章基本信息

• 标题：Role of Deliberate Practice in the Development of Creativity (2014)
• 作者：William R. Reeves
• 创建日期：2014年8月26日
• 格式：PDF 1.5
• 生成工具：Microsoft® Word 2013

内容结构

文章共包含129页，从第1页至第129页。

核心主题

本文探讨刻意练习在创造力发展过程中的作用与影响。文章应系统阐述了刻意练习的理论框架及其与创造力培养之间的关联性。

可能包含的关键内容

基于标题和常见的学术论文结构，本文可能涵盖以下方面：

1. 刻意练习的定义与理论基础
2. 创造力的心理学与认知科学视角
3. 刻意练习如何促进创造力技能的发展
4. 相关领域的研究综述与实证分析
5. 实践应用与教育启示

文章特征

• 学术论文形式，结构完整
• 篇幅较长（129页），内容详尽
• 无版权限制（Keywords: No Restrictions）

注：由于提供的元数据中未包含文章正文的具体文字内容，以上摘要主要基于标题、作者信息及常见学术论文结构进行推断。如需更准确的内容概括，需要获取文章正文的详细文字信息。

SunVox 摘要

基本介绍

SunVox 是一个小型、快速且功能强大的模块化合成器与音乐工作站，它采用基于模式的音序器（追踪器）。该软件非常适合各种电子音乐实验、探索新的声音与风格。它以其高度优化的合成算法和灵活的架构著称，能够在众多不同CPU和设备上运行，包括非常老旧和速度较慢的设备，使用户可以在任何地方、任何设备上创作音乐。对于大多数平台是免费的，但Android和iOS平台除外。

主要特性

• 广泛的系统支持：可在 Windows、macOS、Linux（包括 x86、x86_64、ARM、ARM64）、iOS、Android 以及 Windows CE 等系统上运行。
• 丰富的音频支持：支持 ASIO、DirectSound、ALSA、JACK 等多种声音系统。可作为 iOS 上的 AU 插件使用。
• 全面的格式兼容：支持 16/24/32 位 WAV、AIFF、OGG、MP3、FLAC、XI 等样本格式，支持多轨 WAV 导出，并支持 MIDI 输入/输出/导入/导出。
• 强大的创作功能：
  • 支持导入 XM（FastTracker）和 MOD（ProTracker, OctaMED）格式文件。
  • 提供实时样本录制及各类声音事件（音符、触摸泰勒明、控制器）的实时录制。
  • 拥有强大的微调（超色）音序器。
  • 具备生成功能特性，如音符随机选择、控制器随机值、概率效果等。
  • 内置大量合成器和效果器模块，并支持在它们之间进行非常复杂的连接。
• 开发者友好：提供免费的跨平台库，开发者可在自己的应用中使用 SunVox 引擎。

资源与支持

• 官方资源：提供用户手册、教程、视频、截图、徽标等详细资料。
• 社区与交流：设有论坛、Facebook 及 Telegram 聊天/新闻频道。
• 创作展示：文章展示了通过 SunVox 创作的音乐，并链接了历年举办的“SunVox Compo”比赛作品及 SoundCloud 社区精选集（2015-2022年）。
• 版本历史：最新版本为 2.1.4d，并保留有旧版本（如适用于 PalmOS 和 MeeGo 的 1.8.1 版本）的存档。

核心冲突概述

本文详细记述了WordPress创始人兼Automattic公司CEO 马特·穆伦沃格与主要竞争对手WP Engine之间的公开冲突，并指控马特滥用其对WordPress生态系统多重实体的控制权，严重损害了WordPress社区的健康与信任。

冲突始末与关键指控

1. 许可费索求与威胁：

   • 2024年7月左右，Automattic向WP Engine索要其总营收8%的许可费，以换取使用“WordPress”等相关术语的权利。WP Engine认为此要求缺乏法律依据并拒绝。
   • 马特随即采取一系列行动，包括向WordPress基金会申请“托管WordPress”等通用术语的商标，并在WordCamp US大会前以“毁掉”WP Engine相威胁，要求其付款。

2. 滥用权力打压对手：

   • 封锁插件库访问：在WP Engine拒绝后，马特利用对WordPress.org的控制权，禁止WP Engine的网站访问插件库，影响其用户更新插件，带来安全风险。
   • 劫持热门插件：马特以“社区接管”名义，强行接管了WP Engine维护的、拥有数百万安装量的流行插件“Advanced Custom Fields”，并将其重命名。此举被广泛视为对竞争对手的财产掠夺。
   • 利用官方渠道攻击：在WordPress.org官方博客发布文章抨击WP Engine，并利用WordPress后台新闻源向所有网站管理员推送该文章。
   • 修改规则与限制言论：追溯性地修改商标政策，针对含有“WP”名称的产品；在WordPress.org登录页面添加针对WP Engine的复选框；甚至屏蔽反对者访问其网站的DNS记录。

3. 行为动机与辩护：

   • 马特声称其行动是针对WP Engine“回馈不足”、误导用户以及修改WordPress核心功能（如禁用修订版本）等问题。
   • 但作者指出，马特的指控大多缺乏依据或被夸大，其真实动机被视为利用权力为Automattic谋取商业利益和消灭竞争对手。

4. 对社区的严重影响：

   • 开发者与贡献者流失：大量核心开发者和社区贡献者因对马特行为感到失望而离开。
   • 公司内部动荡：Automattic内部出现严重分歧，马特提供高额遣散费要求不认同其做法的员工离职，并监控员工内部通讯。
   • 信任与安全危机：社区对WordPress治理结构的公正性、稳定性和安全性产生根本性质疑。文章认为，马特对WordPress.org拥有绝对个人控制权，违背了社区对基金会非营利性和中立性的长期认知。

5. 法律诉讼进展：

   • WP Engine对Automattic和马特提起诉讼，指控其敲诈、反竞争行为等。
   • 2024年12月，法院支持了WP Engine的初步禁令申请，要求Automattic恢复WP Engine对WordPress.org的访问、归还ACF插件并删除相关限制性措施。马特对此反应激烈，称自己被迫“提供免费劳动”。

作者立场与结论

作者虽自称多年未活跃于WordPress开发，但基于对社区的深厚感情，强烈批评马特的行为。核心观点包括：

• 马特的行为已远超正常商业争议范畴，构成对权力的滥用和对社区生态的破坏。
• WordPress基金会、.org域名和Automattic之间权力高度集中于马特一人，形成严重利益冲突和垄断风险。
• 无论WP Engine是否存在问题，马特的反应方式（恐吓、封锁、劫持）都是不正当且极具破坏性的。
• 根本解决方案在于解除马特对WordPress官方机构的个人控制，建立真正的社区治理模式，防止类似事件重演。

文章最终认为，如果WordPress想要生存和繁荣，马特·穆伦沃格必须被移除出所有官方的WordPress领导职位。

事件概述

爱尔兰数据保护委员会（DPC）因 Meta 在2019年的安全漏洞中以明文形式存储用户密码，对其处以 1.015 亿美元（9100万欧元）的罚款。

事件细节

• 影响范围：该漏洞涉及高达 6 亿个密码，部分密码自2012年起便以明文形式存储在服务器中。受影响平台包括 Facebook 以及数百万个 Instagram 账户。
• 内部访问：超过 2 万名 Facebook 员工可以搜索这些明文密码，但 DPC 确认这些数据并未泄露给外部人员。

违规原因

DPC 认定 Meta 违反了多项《通用数据保护条例》（GDPR）规定：

1. 未及时上报：未能及时向 DPC 通知明文存储用户密码的个人数据泄露事件。
2. 未作记录：未能记录该起个人数据泄露事件。
3. 安全措施不足：未采取适当的技术措施来确保用户密码的安全，防止其被未经授权的处理。

官方回应与附加处罚

• 官方声明：DPC 副专员 Graham Doyle 指出，业界普遍认为不应明文存储密码，且社交媒体账户密码尤为敏感，明文存储会带来极高的滥用风险。
• 附加处罚：除了巨额罚款外，DPC 还对 Meta 进行了正式谴责（reprimand）。完整的最终决定及相关细节将在未来公布。

文档概述

本文是一份关于 SAML (Security Assertion Markup Language) 的技术入门指南，旨在为开发者提供从概念理解到集成实践的全面内容。文档结构清晰，涵盖了SAML的核心概念、各种技术栈的快速集成方法、相关工具以及围绕SSOReady平台构建的生态系统。

核心内容

1. SAML 基础与集成

• 概念与快速入门：介绍SAML作为企业单点登录 (SSO) 标准的基本原理，并提供快速开始指南。
• 与登录界面集成：详细说明如何将SAML身份验证集成到自有的用户登录界面中。
• 处理登录与即时供应 (JIT)：阐述如何处理SAML登录流程，并实现用户账户的即时供应。

2. SDK 与开发支持

文档提供了多种主流编程语言的软件开发工具包 (SDK)，以简化集成过程，包括：

• TypeScript SDK
• Python SDK
• Go SDK
• Java SDK
• C# SDK
• Ruby SDK
• PHP SDK

3. SAML-over-OAuth 与特殊环境集成

• SAML over OAuth：探讨了一种结合SAML和OAuth的方案，提供了与NextAuth.js等流行框架的集成示例。
• Firebase 雛成：专门说明了在Firebase环境中实施SAML身份验证的方法。

4. IDP 配置与客户自助服务

• IDP配置：指导如何配置身份提供商 (Identity Provider, IDP)。
• 自助服务：介绍了如何为您的客户启用自助配置SSO连接的功能。

5. SSOReady 核心概念

文档围绕 SSOReady 这个平台，定义了其核心概念，包括：

• 环境 (Environments) 与 组织 (Organizations)：系统的顶层结构。
• SAML连接 (SAML Connections)：具体的SAML身份验证关系。
• SAML登录流程 (SAML Login Flows)：身份验证的具体流程。
• SCIM 目录 (Directories)、用户 (Users)、组 (Groups)：用于用户和组同步的SCIM (System for Cross-domain Identity Management) 相关实体。
• SCIM请求日志 (Request Logs)：记录SCIM操作。

6. 管理、测试与部署工具

• 管理 API：提供通过编程方式管理SSOReady资源的API。
• DummyIDP：一个用于在没有真实身份提供商的情况下，测试SAML和SCIM功能的模拟工具。
• 自托管 (Self-Hosting)：提供了自行托管部署SSOReady解决方案的指南。
• API 参考：完整的API接口文档。

mtCellEdit 是一款从头开始创建的轻量级电子表格程序，专注于处理日常简单任务。其设计旨在提供核心功能，避免大型程序常见的运行缓慢和界面复杂问题，图形界面基于Qt5开发。

程序的核心是一个共享的C/C++库，可用于读写和操作电子表格数据。源码套件中还包含使用该库的示例程序，例如支持通过脚本访问API的命令行工具。

该程序的默认文件格式为便携且透明的ZIP文件，内含TSV文本文件。这种设计确保数据可被任何操作系统上的现代电子表格程序直接读取，无需依赖mtCellEdit，从而避免了数据被锁定在特定二进制或XML格式中的问题。

mtCellEdit主要面向GNU/Linux操作系统，并已在x86_32、x86_64和ARM_32平台上测试。其源代码遵循GNU通用公共许可证第三版或更新版本进行分发。

Cuttle：用于原型设计、制作与创意探索的参数化CAD工具

工具简介

Cuttle 是一款基于 Web 的 2D 参数化计算机辅助设计（CAD）工具。其核心优势在于学习曲线平缓、界面简洁且提供免费完整版。除了丰富的内置组件，Cuttle 还支持自定义 JavaScript 代码，兼顾了非程序员的易用性与开发者的高级定制需求。此外，它提供高质量的教程、项目模板以及活跃的社区支持。

核心应用场景

1. 物理对象制作：设计激光切割形状，导出 SVG 文件用于物理加工。
2. 图案与概念探索：将形状的尺寸、边数、角度等属性参数化，通过调整变量探索未知的视觉图案。
3. 非 CAD 原型设计：利用其即时视觉反馈优势，将 Cuttle 作为过渡原型工具，解决非传统 CAD 领域的开发问题。

代表性项目实践

• 装饰书挡：设计了可磁吸的书本图标，将页数、厚度和打开角度等属性完全参数化。
• 门铃盖：基于盒子模板，构建雪花图案单元并参数化其缩放与重复，完成复杂的装饰性镂空。
• 八音盒打孔卡：将外部脚本生成的 MIDI 坐标导入 Cuttle 模板，快速调整孔距等参数，高效完成端到端系统的原型验证。
• 图案研究：重现莫尔条纹和组子（Kumiko）等图案，通过调整比例参数生成丰富的视觉变体。
• 互动诗歌：利用自定义修改器将文本转化为互动视觉作品，拓展了工具在创意编程中的应用边界。
• 其他应用：包括参数化卡片展示架、激光切割校准工具、编织草图及视差动画测试。

整体评价

项目耗时取决于设计复杂度与工具熟练度。虽然在处理海量对象时偶尔会引起浏览器卡顿，但软件处于积极开发中，且性能问题通常可通过优化设计逻辑来规避。作者总结认为，Cuttle 是一款强大的设计系统，其最大的“问题”在于极高的趣味性，极易让人沉浸其中而忽略时间。

PyTorch原生架构优化库：torchao

概述

torchao 是一个 PyTorch 原生库，旨在通过低比特数据类型、量化和稀疏性技术，使模型更快、更小巧。该库提供了一套易用的优化工具集，主要用可读的 PyTorch 代码编写，涵盖推理和训练场景。

主要技术与应用

推理优化

• 量化 API：提供顶层 quantize_ 接口，支持对包含 nn.Linear 层的任意 PyTorch 模型进行权重量化和动态激活量化。可根据模型特性（计算受限或内存受限）选择不同方案，如 int4_weight_only、int8_weight_only、float8_weight_only 等。
• 自动量化：通过 torchao.autoquant 自动选择每个层的最佳量化策略，避免手动调优。
• 组合技术：可组合稀疏性与量化，例如为 ViT-H 推理带来5%加速；也可同时量化权重（如int4）和KV缓存（如int8），支持Llama 3.1 8B在128K上下文长度下以低于18.9GB显存运行。
• QAT（量化感知训练）：用于缓解训练后量化（尤其是低于4比特时）的精度损失，可恢复高达96%的精度。

训练优化

• 低精度计算与通信：支持将训练中的计算和分布式通信精度降低，例如使用 float8 替代 bf16 进行 torch.nn.Linear 层的计算。
• 低比特优化器：提供8比特和4比特优化器（如 AdamW8bit、AdamW4bit）作为 AdamW 的即插即用替代方案，减少显存占用。
• 未来扩展：正在扩展对更多数据类型和布局的支持，包括 NF4 QLoRA、int8训练、2:4稀疏训练等。

性能基准

在多个流行生成式AI模型上验证，精度损失极小（基准为A100 80GB GPU上的bf16）：

• Llama 3：
  • 推理速度提升97%（int4权重量化 + HQQ）。
  • 推理峰值显存减少73%（量化KV缓存，128K上下文）。
  • 预训练速度提升50%（float8训练，H100）。
  • 峰值显存减少30%（4比特优化器）。
• 扩散模型推理：
  • Flux.1-Dev推理速度提升53%（float8动态量化，H100）。
  • CogVideoX模型显存减少50%（int8动态量化）。
• 其他：组合稀疏与量化为ViT-H推理带来5%加速。

集成与生态

torchao 已与多个开源项目集成，作为优化后端或参考实现：

• Hugging Face Transformers（推理后端）
• Diffusers-torchao（扩散模型加速）
• HQQ（快速4比特推理）
• torchtune（原生QLoRA和QAT方案）
• torchchat（训练后量化）
• SGLang（int4/int8训练后量化）

结论与未来

torchao 通过 pip install torchao 安装，易于集成，旨在简化模型加速与压缩。未来方向包括：支持低于4比特的量化、高吞吐推理内核、扩展至更多层与硬件后端（如MX硬件）、以及提升可扩展性。社区可通过 GitHub 跟踪进展并参与贡献。

致谢：感谢 Bits and Bytes、Answer.ai、Mobius Labs、Hugging Face Transformers/Diffusers 以及 GPU MODE 社区等合作伙伴的贡献。

文章“The Little Typer (2018)”主要介绍了基于Racket的Pie实现的安装和使用方法。首先，通过Racket包系统安装Pie：需先安装最新版Racket，然后在DrRacket中选择“File”菜单的“Install Package”，输入“pie”并点击安装按钮。使用时，在DrRacket中以#lang pie开始文件。此外，文章指出存在已知的勘误。

《伦敦酒吧的建筑风貌》（1966）是建筑师兼作家斯蒂芬·加德纳在《伦敦杂志》上发表的一篇社会文化建筑分析文章。文章聚焦于1960年代中期伦敦酒吧传统风格与现代化改造之间的冲突，并对后者提出尖锐批评。

文章开篇描绘了传统英式酒吧的典型特征：需要站着喝酒、设有磨光的橡木长凳、用隔板保护隐私、常见戴帽子抽着烟斗的顾客，木地板上铺着锯末和洒落的啤酒。厚重的木质吧台、玻璃翻板、摆满酒瓶的架子、复杂精致的雕花玻璃器皿，以及从湿漉漉的街道望进去时内部昏黄灯光勾勒出的模糊轮廓——这些都是传统酒吧不可或缺的元素。然而，作者指出，这些传统特征正在消失。大型酿酒商（如沃特尼、惠特布雷德等）正以“现代时代”为由，大量淘汰这些“陈旧”的装饰，代之以镀铬、塑料贴面、持久不变的人造花卉，甚至还有专利人造香水。

作者认为，酒吧的改造只是更广泛文化破坏的一部分，与乡间风貌、十八世纪城镇景观的遭遇相似。唯一的例外似乎是教堂，但那或许也只是出于某种虚假的敬畏。他认为这种现代化改造公式实质上是中产阶级对二十世纪的肤浅理解，是二手当代设计的翻版，其建筑上的平行对应物便是那些粗制滥造、内装廉价铝制水槽和厨具的仿乔治亚风格联排别墅。这些改造项目的组织者似乎刻意要消除任何独特、非常规或古怪的事物，因为他们觉得这些不符合他们那种整齐划一、令其感到安全的生活模式。

文章详细分析了改造带来的破坏。首先被清除的是酒吧内部分隔空间的隔板和隔间，这使得不同功能的酒吧区（公共酒吧、沙龙酒吧、私人酒吧等）的多样性被一举消除。作者以切尔西的两家优秀酒吧——国王头酒吧和费尼酒吧——为例，描述它们经过改造后变得空荡、孤寂、异常洁净，原有的老式吧台、高背木椅、铸铁腿的桃花心木桌、精巧的架子和黄铜配件、深色镶板乃至戴帽抽烟斗的老顾客全都消失了。作者质疑这种毁灭性的改造如何可能发生，而它确实正在各地上演。

作者预言，英式酒吧很快将成为历史遗迹。问题的根源在于，酿酒商仓促地寻找传统内饰的现代替代品时，既不思考，也不聘请合格的建筑师和设计师。他们将酒吧交给其“室内设计部”的庸手处理，没有意识到这些老地方的陈设本身具有价值。与其盲目铺设地毯、贴上壁纸、安装塑料台面，他们更应该研究过去的设计经验，了解为何传统的布局方案如此优秀，并且在与当下糟糕的“设计方案”对比时显得尤为突出。

作者强调，建筑属于每个人，应由懂得它的人来保护。在改造一栋优质建筑时期（如乔治亚式或早期维多利亚式）的内部时，正确的方法是让新设计与建筑外部的规模、特征、比例及细部相呼应，捕捉其设计氛围与时代感。如果孤立地看待内部设计，必然会导致建筑灾难。他举例说，如果波特贝罗路的亨尼基酒吧能用几个架子、酒桶和玻璃镶板隔断打造出成功的室内设计，那么当今的建筑师只要具备洞察力、感受力和想象力，而非过于拘泥于建筑师身份，也同样能做到。

在讨论理想的酒吧布局时，作者指出所有优秀酒吧的共同点是吧台的位置。它总是像教堂的圣坛一样，成为整个空间的焦点。它要么位于中心，要么围绕它形成清晰界定的区域，并且其形状使其仿佛能亲自掌控这些区域。布局设计应围绕此中心展开，以增强各区域的私密性并简化对它们的管理。私密感是酒吧的重要因素，它让人联想到乡村小酒馆或海滨旅馆，那种用高背黑木座椅围出的专属服务空间，带有一种舒适、神秘且略带怀旧的氛围。

作者认为理想的酒吧布局应是：吧台位于中心（或接近中心），若干隔间以带有些许临时感的隔板与吧台辐射状分隔开。理想的酒吧还应具备低矮的天花板，这符合隔间的尺度并能增加空间的悬疑感——你的视线刚好越过隔板顶部，会好奇另一边在发生什么。在隔间与吧台区之间，常设有玻璃翻板（如亨尼基酒吧）或制作精美但毫不做作的架子（如萨塞克斯广场的维多利亚酒吧等处）。这些架子上总是摆满了酒瓶（瓶中液体的颜色在光线下熠熠生辉）和各式玻璃器皿。

关于展示，作者指出理想酒吧的核心展示区就在吧台中央，所有待售商品都在此陈列，犹如商店的橱窗。标签和手写字体在此变得重要，成为装饰的一部分，与门外的招牌和文字相得益彰。理想的酒吧天生具备绝佳的展示才能。

总结来说，酒吧设计归结于几个已知要素：天花板高度、隔板、简单的乡村风磨光家具或豪华的皮质家具、架子与玻璃器皿、收藏家般精心的展示，以及居于主导地位的“父亲形象”——吧台。当然，规则并非一成不变。有些酒吧（如汉索姆出租马车酒吧）即使没有隔板，通过不规则的布局也能很好地营造出悬疑感和私密感；天花板也可以很高，只要整体空间（如索尔兹伯里酒吧）需要并能够承载这种高度。

最后，作者向酿酒商提出两条必须遵守的规则以保护英式酒吧传统：如果一家优秀酒吧需要重新装饰和改造，必须保留其最好的部分和真实的细节；如果是一家糟糕的酒吧（这类酒吧数量惊人），则应该推倒重来，但必须聘请合适的建筑师。文章以呼吁请勿使用人造花卉、不要用电视取代飞镖和台球桌作为结束。

斯蒂芬·加德纳是英国建筑师、教师和作家，在切尔西出生和成长，定期为《伦敦杂志》和《观察家报》撰稿。

文章总结

作者发现垃圾分类回收（塑料、金属、纸张、玻璃、堆肥及其他垃圾）的收集日安排复杂，虽已有高科技解决方案（如“bindicator”），但他认为高科技并非总是最佳选择。他决定制作一个实体时钟来解决问题。

核心理念：垃圾分类日程变化不频繁，无需调用API（多数市政部门也未提供此类API），且作者希望避免增加需要电源适配器、配置WiFi或调试代码的设备。他认为并非所有事物都需要图灵完备。

实现方式：

1. 购买机芯：使用可在七天内完成一圈转动的廉价时钟机芯。
2. 生成表盘：编写代码生成时钟表盘的SVG（及PDF、PNG）文件。表盘分为七天，每天可标识最多两种垃圾类型。
3. 代码结构：
   • 通过bins变量定义垃圾类型（颜色和标签），支持自定义以适应本地分类（示例中使用葡萄牙语标签）。
   • 通过schd变量安排一周每天对应的垃圾类型。
   • 核心函数path和getXY用于生成SVG路径：计算七天分段的弧线起始点坐标，并绘制弧形曲线。SVG的视图框设置为以(0,0)为中心的坐标系。
4. 组装成品：将打印好的表盘与方形相框、木片间隔物组装，形成实用的“垃圾时钟”。

该方案简单、低成本且易于定制，避免了技术过度复杂化。

GitHub 平台概述

GitHub 是一个面向开发者的技术平台，提供代码托管、协作工具和一系列服务，以支持软件开发生命周期。其核心功能围绕提升开发效率、安全性和协作体验展开。

主要功能分类

• AI 代码创建：通过 GitHub Copilot 等工具，利用人工智能辅助代码编写，提升编码质量和效率。
• 开发者工作流：
  • Actions：自动化工作流，实现持续集成和部署。
  • Codespaces：提供即时开发环境，简化项目设置。
  • Issues：用于规划和跟踪工作，管理任务和问题。
  • Code Review：管理代码变更，促进团队协作和代码质量。
• 应用安全：
  • GitHub Advanced Security：查找和修复漏洞，增强代码安全性。
  • Code security：在构建过程中确保代码安全。
  • Secret protection：防止敏感信息泄露。

探索与分类选项

• 按公司规模：支持企业、中小型团队、初创公司和非营利组织。
• 按用例：涵盖应用现代化、DevSecOps、DevOps、CI/CD 等场景。
• 按行业：包括医疗保健、金融服务、制造业、政府等领域。
• 按主题：涉及人工智能、软件开发、DevOps、安全等话题。
• 按类型：提供客户故事、网络研讨会、电子书、报告等资源。

支持与社区资源

• 支持与服务：包括文档、客户支持、社区论坛、信任中心等。
• 社区计划：如 GitHub Sponsors（资助开源开发者）、Security Lab、Maintainer Community 等。
• 仓库功能：支持主题浏览、趋势仓库和集合管理。

企业解决方案

• 提供企业级平台，集成人工智能功能，附带高级安全特性（如 GitHub Advanced Security）、企业级 AI 工具（如 Copilot for Business）和 24/7 高级支持。

平台旨在通过自动化、安全增强和协作工具，帮助开发者和企业优化软件开发流程。内容还涉及用户反馈收集和账户管理选项，如登录和注册。

2D平台游戏实现指南摘要

本文对2D平台游戏的实现方式进行了系统分类，探讨了四种主要架构的优缺点及关键技术细节，并总结了提升游戏手感的通用机制。

四种核心实现方式

1. 纯瓦片基础 (Tile-based pure)

• 特点：角色移动严格限制在网格瓦片上，逻辑上不存在跨瓦片的平滑移动。
• 适用场景：解谜或“电影化”平台游戏（如《波斯王子》、《Flashback》）。
• 优缺点：实现简单、逻辑精确且不易出现Bug；但角色控制受限，不适合传统动作游戏，且难以实现抛物线跳跃。

2. 平滑瓦片基础 (Tile-based smooth)

• 特点：碰撞检测基于瓦片地图，但角色可在世界中以像素级（通常为1px）自由移动。
• 适用场景：绝大多数经典8位/16位动作平台游戏（如《超级马里奥》、《洛克人》）。
• 关键技术：
  • 斜坡：通过记录瓦片两侧的“地板Y坐标”来实现，需特别注意水平与垂直移动的先后顺序及重力适配。
  • 单向平台：仅当角色从上方落下且移动前底部高于平台顶部时触发碰撞。
  • 梯子与移动平台：梯子通过切换独立的状态和碰撞盒实现；移动平台需在角色移动前计算平台位移，并同步给站在其上的角色。

3. 位掩码 (Bitmask)

• 特点：使用图像像素级别的数据来确定碰撞，而非大块瓦片。
• 适用场景：需要精细地形或动态可破坏环境的游戏（如《百战天虫》）。
• 优缺点：地形细节丰富；但内存占用大、关卡编辑复杂，且斜坡等碰撞算法极为复杂且稳定性较差。

4. 矢量多边形 (Vectorial)

• 特点：使用线段或多边形等矢量数据定义碰撞边界，常结合Box2D等物理引擎使用。
• 适用场景：现代物理平台游戏（如《时空幻境》、《地狱边境》）。
• 关键技术：为避免物理引擎导致手感失控，通常将角色拆分为多个具有不同物理属性（如脚部高摩擦、侧面低摩擦）的复合多边形，并使用传感器（Sensors）检测特定状态。

通用机制与手感优化

• 加速度控制：直接影响操作手感。低加速度带来惯性滑行感，高加速度提供极速响应。实现方式包括加权平均法和累加法，必须在移动前将加速度积分到速度中，以避免产生一帧的输入延迟。
• 跳跃控制：包含四种常见维度：保留起跳前水平动量的冲量、允许空中改变方向的空中加速、按住按键跳得更高的上升控制，以及通过计数器限制次数的多重跳跃。
• 动画与前摇：在强调反应的动作游戏中，应避免使用影响操作响应的长前摇动画，动作触发必须与视觉动画解耦。
• 平滑移动处理：为兼顾整数坐标的稳定性与移动的平滑度，推荐采用“整数位置+浮点余数”方案。将浮点计算产生的小数部分存入余数并在下一帧累加，从而避免全局使用浮点数带来的精度丢失和性能损耗。

Intel Lion Cove P-Core 架构总结

核心背景与设计目标

Lion Cove 是 Intel 最新的 P-Core（性能核）架构，首发应用于 Lunar Lake 移动端处理器。为应对市场竞争，Lunar Lake 采用全新 chiplet 设计，将计算模块集中于单一 tile。Lion Cove 旨在提供极致的单线程性能，并在性能和能效上进行了全面重构，是自 Golden Cove 以来 Intel P-Core 最大规模的架构升级。

缓存与内存子系统

• L3与内存：Lunar Lake 的环形总线仅保留 P-Core 及 L3 切片。L3 总容量减半至 12MB，但延迟大幅降低。内存控制器与 CPU 同处一个 tile，显著改善了 DRAM 延迟，并引入 8MB 内存侧缓存以降低整体功耗。
• 多级缓存重构：引入 192KB 的“L1.5”中间级缓存（Intel 官方称为 L1，原 L1 改称 L0）和 48KB 的 L1 缓存，旨在降低 L1D 未命中的平均延迟。L2 缓存容量提升至 2.5MB（最高支持 3MB），通过增大核心私有缓存来弥补 L3 带宽的不足。

后端：调度与执行引擎

• 调度器拆分：放弃了长期的统一数学调度器设计，将其拆分为独立的整数和浮点/向量调度器，并分离了寄存器重命名。结合非调度队列，整体调度容量超过 200 条目。
• 执行与乱序结构：执行端口增至 18 个，浮点/向量执行采用 4 管道设计。乱序执行资源显著扩大，ROB（重排序缓冲区）容量增加 12.5%，分支和浮点寄存器文件大幅增长，提升了核心应对缓存未命中等长延迟事件的韧性。

前端：解码与分支预测

• 前端加宽：重命名阶段和解码器均加宽至 8 微操作/指令每周期，使 Lion Cove 成为 8-wide 核心。微操作缓存容量增至 5250 条目，带宽提升至 12 微操作/周期。
• 分支预测：分支预测准确率有小幅优化，返回栈增至 24 条目，且返回预测速度极快，每周期可处理一对 call/return 操作。

性能表现与总结

在 SPEC CPU2017 测试中，Lion Cove 相比上一代 Redwood Cove 在整数和浮点性能上分别提升了 23.2% 和 15.8%。尽管 Lunar Lake 的 L3 缓存容量较小，其单线程性能仍与 AMD Strix Point (Zen 5) 旗鼓相当。Lion Cove 展现了 Intel 强大的工程设计能力，不仅提升了移动端表现，也为未来 Arrow Lake 桌面端处理器的性能释放奠定了坚实基础。

地球健康评估：第六个行星边界即将失守

根据波茨坦气候影响研究所（PIK）发布的首份《行星健康检查》报告，地球的生命支持系统状况堪忧。报告评估了维持地球韧性和稳定性的九个“行星边界”，发现其中六个边界已被超越，且情况正在进一步恶化。

• 已越界的六个边界：气候变化、淡水可用性、生物多样性完整性、土地系统变化、生物地球化学流动（如磷和氮等营养物质污染），以及新型实体（如合成化学品和塑料进入环境）。
• 濒临越界的第七个边界：海洋酸化。报告指出，海洋酸化目前尚处于“安全区”，但正在朝高风险方向发展，可能在未来几年内突破临界点。海洋吸收大气中的二氧化碳会导致酸度上升，破坏珊瑚和贝类生物的钙化过程，影响鱼类生命周期，并对北极和南大洋等关键区域构成严重威胁。研究人员认为，考虑到区域性差异，某些地区可能已经突破了安全边界。
• 剩余两个边界：大气臭氧层损耗和平流层气溶胶加载仍处于安全区内。

报告将地球比作“病情危重的患者”，强调九个行星边界高度相互关联。该《行星健康检查》将成为年度系列报告，旨在利用卫星数据、人工智能和多学科方法，为改善地球健康、减轻人类影响提供决策支持。应对危机需要整体性方法，综合考虑所有边界以制定最有效的行动方案。

Prep: Golang 编译时评估工具

Prep 是一个小型的 Go 工具，用于实现编译时函数评估。通过使用 prep.Comptime，可以在构建时评估函数，并用其计算结果替换函数调用，类似于 Zig 语言中的 comptime 功能。

主要特点

• 编译时评估：在构建时将函数调用替换为其计算结果。
• 简单集成：既可以作为 Go 库使用，也可以作为独立的可执行文件运行。
• 工具链支持：能够轻松地通过 -toolexec 将 prep 集成到 Go 的构建流程中。

安装方法

1. 安装 prep 可执行文件：要在构建流程中使用 prep，需要将其作为二进制可执行文件安装。

   go install github.com/pijng/prep/cmd/prep@latest
   

2. 添加 prep 作为依赖：要在 Go 项目中使用 prep 库，通过 Go modules 添加：

   go get github.com/pijng/prep
   go mod tidy
   

使用方法

使用 prep.Comptime 包装函数

要将一个函数标记为进行编译时评估，使用 prep.Comptime 进行包装。例如：

package main

import (
  "fmt"
  "github.com/pijng/prep"
)

func main() {
  // 该函数调用将在编译时被评估
  result := prep.Comptime(fibonacci(300))
  fmt.Println("Result:", result)
}

func fibonacci(n int) int {
  fmt.Printf("calculating fibonacci for %d\n", n)
  if n <= 1 {
    return n
  }
  a, b := 0, 1
  for i := 2; i <= n; i++ {
    a, b = b, a+b
  }
  return b
}

使用 prep 进行构建

包装函数后，需要在构建过程中使用 prep。这通过 -toolexec 标志实现：

go build -toolexec="prep" main.go

此命令会评估所有用 prep.Comptime 包装的函数，并在构建过程中用其计算结果替换它们。

运行生成的二进制文件时，程序会快速输出结果，并且不会出现 calculating fibonacci for %d 的消息，因为 fibonacci 函数已在编译时被计算并替换。

限制

基本字面量参数

在核心功能上，prep.Comptime 允许提供基本字面量（如字符串、整数、浮点数）作为参数。这意味着：

1. 可以直接传递基本字面量。
2. 可以使用与包装函数在同一作用域内、值为基本字面量的变量。 这些字面量会在编译时直接求值。

编译时评估（实验性功能）

此外，prep.Comptime 也支持在编译期间进行评估，此时可以使用来自 IO 操作的值。例如：

func main() {
  config := prep.Comptime(readFile("./test.txt"))
  fmt.Println(config)
}

func readFile(path string) string {
  content, _ := os.ReadFile(path)
  return string(content)
}

这种方式下，prep 会在编译步骤中调用 readFile 函数，并将其结果包含在最终的二进制文件中。这意味着可以在编译后删除 test.txt 文件，程序仍然能够正常执行，就像文件存在一样。 注意：此功能仍属实验性质，可能存在问题。

动机

该工具的创建出于一些原因。