## Base64 编码：摘要
Base64 是一种使用 64 个字符的字母表将二进制数据转换为文本格式的方法。这对于在基于文本的环境（如 HTML 或 JavaScript）中嵌入数据，或通过基于文本的协议传输二进制文件非常有用。该过程通过将二进制数据分成 6 位段，然后将每个段映射到 Base64 字母表中的一个字符来工作。当输入不是 3 字节的倍数时，使用“=”号进行填充。
现代浏览器提供内置函数（`Uint8Array.toBase64()` 和 `Uint8Array.fromBase64()`）来实现高效的编码和解码。基准测试显示不同浏览器之间存在显著的性能差异。基于 Chromium 的浏览器（Chrome、Edge、Brave）展示了更快的编码速度（高达 19 GB/s），而 Safari 在解码方面表现出色（9.4 GB/s）。Firefox 和 Servo 显示出明显较慢的性能。
这些速度通常比典型的磁盘或网络速度更快。Chromium 浏览器中的解码速度稍慢，因为存在中间缓冲区步骤。正在进行中的改进，例如 Firefox 计划的改进，旨在进一步提高 Base64 的性能。
每日HackerNews RSS
## 浏览器 Base64 处理速度 - 总结
一篇近期文章引发了 Hacker News 上关于网页浏览器中 base64 编码和解码速度的讨论。一个关键更新强调了 V8（Chrome 引擎）的变化，它去除了一个临时缓冲区，可能使解码速度*翻倍*。这一改进源于与原始文章相关的观察。
对话还涉及了新浏览器函数（`Uint8Array.toBase64()` 和 `Uint8Array.fromBase64()`）的便利性，并探讨了优化技术，包括基于 GPU 的处理（但由于开销而被认为效率低下）和 SIMD 实现。
值得注意的是，Firefox 的性能落后于 Chrome，并且正在努力解决不必要的数据复制等效率低下问题。有人推测这可能是由于遥测和优化策略的差异——Google 积极分析用户 CPU 时间，而 Mozilla 优先考虑隐私。最后，讨论揭示了一个令人惊讶的细节：base64 解码器通常会处理并忽略空白字符以实现兼容性。
## JavaScript中使用TypeScript的多线程
多线程为JavaScript带来了受Rust启发的并发性，利用Web Workers实现真正的并行性，同时简化了复杂的worker管理。它提供了一个管理的线程池，确保高效的资源利用，并优先考虑内存安全，具有Mutexes、Read-Write Locks和Condition Variables等同步原语。
主要特性包括通过`SharedArrayBuffer`和`SharedJsonBuffer`（用于JSON对象）安全地在线程之间共享状态，以及在worker任务中无缝导入模块（外部库和相对文件）。数据传输到worker通过`move()`函数处理，对兼容对象使用零拷贝传输，对其他对象使用克隆。
核心函数`spawn()`将任务提交到线程池并返回一个句柄以等待结果。同步原语可以防止在访问共享内存时发生竞争条件。建议使用异步方法来获取锁，以避免阻塞worker线程。Channels提供了一个强大、线程安全的队列，用于协调复杂的流程。
该库抽象了Web Worker的复杂性，为JavaScript中的并发编程提供了一种更直观、更强大的方法。它是CPU密集型任务的宝贵工具，可以提高应用程序的响应速度和性能。
离开英特尔
Leaving Intel
2 天前
经过3.5年，我已离开英特尔，开始新的机会。在职期间，我专注于开创用于GPU性能分析的“AI火焰图”——一个仍处于早期阶段但随着GPU代码复杂性增加而有望快速发展的领域。 我工作的重要部分集中在重振英特尔的云战略上。我与六个部门合作，制定了一份包含33条建议的全面计划，并通过一张独特的跨公司互动地图进行可视化，该地图受到英特尔老员工的赞扬。尽管在加入时正值一个充满挑战的时期，面临15个月的招聘冻结，我仍参与了110次客户会议，并为公司做出了有意义的贡献。 虽然我将无法亲身推动执行，但我的云战略和相关资源已在公司内部提供，以继续推进工作。我为所做的贡献感到自豪，并祝愿英特尔继续成功。
## 英特尔离职与大科技量化
知名性能工程师 Brendan Gregg 宣布离开英特尔，任职 3.5 年。他的帖子引发了 Hacker News 上关于大型科技公司工作量化的讨论。Gregg 强调了诸如 110 次客户会议和重夺云市场份额的 33 点策略等成就，引发了关于需要“记录得分”以证明价值的评论。
许多评论员指出，即使这些指标不能准确反映实际贡献，也存在追踪指标（会议、已关闭的工单）的压力。这引发了关于公平评估劳动的更广泛辩论，一些人指出系统性问题，例如尽管工作影响相同，但基于地理位置的薪资差异，以及管理层 KPI 与实际工程价值之间的脱节。
几位用户赞扬了 Gregg 的生产力和贡献（例如创建火焰图），认为他将备受追捧，可能被需要 GPU 优化的 AI 公司相中。其他人猜测他离职的原因，暗示他对英特尔的内部流程感到沮丧。对话还涉及大型公司的官僚主义性质以及在其中进行有影响力的工作所面临的挑战。
作者质疑当前大型语言模型（LLM）日益增长的趋势，认为巨大的规模并非总是必要的。虽然大型模型适用于需要细致理解的复杂通用任务，如聊天机器人，但许多应用——例如SQL自动补全或结构化数据提取——范围有限，并不需要数十亿参数。 核心问题是*推理成本*。运行这些大型模型成本高昂，需要大量的计算能力和基础设施，最终每次用户交互都会增加成本。 作者预测将出现转向更小、更专业化的模型，这些模型针对特定任务进行训练。现有工具已经允许构建和部署这些“小而强大”的模型，甚至可以直接在网页浏览器中进行，为LLM应用提供更高效、更经济的未来——可能仅用1500万个参数就能实现所需的结果。
## 为什么LLM如此庞大？ - Hacker News讨论总结
最近Hacker News上出现了一场关于大型语言模型（LLM）日益增长的规模以及这是否真的必要的讨论。许多评论员认为，对于许多任务，较小的模型——特别是那些使用文本补全而非聊天界面的模型——更有效且更具成本效益。他们指出，LLM本质上是自动补全工具，而聊天界面是建立在其之上的用户友好层。
几位用户强调了直接使用核心文本补全功能的优势，从而可以更好地进行提示工程并获得更好的结果。另一些人指出模型开发的快速步伐，对一个模型的微调可能很快就会因为新版本的发布而过时。
对话还涉及“人工智能军备竞赛”的更广泛影响，暗示模型尺寸的膨胀是由财务激励和对市场控制的渴望驱动的，而非真正的必要性。一种观点是，小型、专业的模型是未来，并且鉴于强大、便携设备的潜力，当前笔记本电脑的尺寸是不必要的大。
## 加密货币的赌场：永续期货解释 许多金融创新服务于实体经济，但加密货币常常创造仅存在于自身领域的系统。一个典型例子是**永续期货（perps）**——一种迷人且占据主导地位的加密货币交易形式（通常是现货交易量的6-8倍），类似于衍生品在传统市场中的作用。 本质上，加密货币交易所充当赌场，依靠吸引投注者，并且需要大量资金来保证支付。永续期货通过减少促进风险承担所需的资本来解决这个问题。它们允许交易者使用杠杆进行投机，并通过“资金费率”（赢家和输家之间的支付）频繁地结算收益和损失（每天多次）。 虽然永续期货起源于加密货币之外，但它们在加密货币领域找到了归宿，这得益于高杠杆（通常为20倍-100倍，而传统市场的限制为2倍-4倍）。这种杠杆会带来风险，通过**自动减杠杆（ADL）**来缓解——一种有争议的机制，交易所可以在极端市场波动期间减少获胜头寸以弥补损失。 这个系统并非完美无缺。它依赖于信任，并且交易所可能优先考虑自身利益（或附属公司的利益）而非个人交易者。由于现有解决方案和风险规避，它不太可能在传统金融领域被广泛采用，但理解永续期货是理解加密货币市场动态的关键。
弗兰克·盖里，1929年出生，是一位享誉全球的建筑师，以其开创性的解构主义风格而闻名。他摒弃了传统的对称性，拥抱非常规的形状和材料，创造出一种独特且不可预测的美学。 在南加州大学和哈佛大学学习后，他创立了自己的公司，并在毕尔巴鄂古根海姆博物馆的项目中获得国际赞誉。这促成了他在世界各地标志性建筑的委托，包括芝加哥的杰伊·普里茨克亭、巴黎的路易威登基金会和布拉格的“跳舞的房子”。 盖里的建筑以其雕塑般的形态而立刻被辨认出来——经常被描述为类似于折叠的玻璃或揉皱的纸袋——并且每个项目都独具原创性。1989年，他荣获普利兹克建筑奖，他的作品被赞誉为具有“高度精致……冒险的美学”，并被比作爵士乐的即兴精神。
## 弗兰克·盖里逝世
著名建筑师弗兰克·盖里，以其独特且常常具有挑战性的设计而闻名，已去世。一则黑客新闻的讨论强调了他的作品影响，从他早期非常规的圣莫尼卡住宅——被描述为永久“无人应答”和“令人困惑”——到像古根海姆博物馆毕尔巴鄂分馆和华特迪士尼音乐厅等标志性建筑。
评论员指出盖里在建筑设计中率先使用技术，以及他勇于突破界限，即使这意味着建造的建筑物将艺术表达置于实用考虑之上。许多人分享了他们与他的建筑的经历，包括麻省理工学院斯塔塔中心（因漏水和设计缺陷而闻名）和脸书门洛帕克园区（因屋顶花园受到赞扬，但因内部布局受到批评）。
虽然他因其雕塑般的形态和影响力而受到赞誉，但有些人质疑他作为设计师的实用性，质疑他对美学的关注是否有时会损害功能性。尽管如此，盖里作为一位开创性和有影响力的建筑师的遗产已被广泛认可。
## 药品定价差异：米博案例 一个鲜明的例子是米博，一种治疗干眼的药物。在欧洲可以非处方药购买，价格约为20美元（以EvoTears销售），而在美国，同样的药物作为处方药销售，价格高达800美元以上。有人成功地从欧洲药房在线购买到该药，价格为32美元，凸显了巨大的价格差异。 这并非个例；美国的处方药价格平均比其他发达国家高2.5倍。Bausch & Lomb 战略性地寻求FDA将其作为处方药批准——尽管在其他地方是OTC药物——以利用专利保护和最大化利润，米博2024年的销售额超过1.72亿美元。 批评人士认为这是价格欺诈，该公司此前在其前身Valeant时期也曾使用过这种策略。Bausch & Lomb 为其定价辩护，理由是获得FDA批准所需的广泛临床试验，但专家认为，该药物在欧洲已经确立的安全记录应该使其在美国获得OTC地位。 提出的解决方案包括要求FDA在批准药物作为处方药之前考虑国际OTC批准，并对米博等案例进行追溯审查，最终将患者的可及性置于公司利润之上。
## 潮汐的复杂科学
我们现代准确预测潮汐的能力依赖于几个世纪的科学进步。古希腊人最初确定月球的引力是潮汐的原因，后来牛顿和拉普拉斯对此进行了量化，但*计算*潮汐却非常复杂。拉普拉斯的方程虽然准确，但对于特定地点来说，手动求解过于困难。
这促使洛德·开尔文在1870年代发明了机械潮汐预测机——这些复杂的设备自动化了繁琐的计算。这些机器不仅考虑了月球的引力，还考虑了太阳的影响、地球的倾角，以及关键的海岸线形状和海洋深度。
潮汐不仅仅是跟随月球的隆起；它们是受陆地影响的波浪，创造出独特的模式，例如围绕岛屿的环形潮汐和潮汐变化最小的区域。预测潮汐需要理解众多天文组成部分的强度和时间，*以及*当地的地理因素。
这些机器一直沿用至1970年代，当时数字计算机终于超越了它们的能力。即使在今天，潮汐仍然是一种令人惊讶的复杂现象，持续的发现揭示了超出我们当前理解的更多复杂性。
## 潮汐：比你想象的更复杂
一篇[signoregalilei.com文章](https://signoregalilei.com/)引发的Hacker News讨论表明，潮汐远比通常认为的更为微妙。传统的“隆起”解释是一种误解；潮汐是由月球（以及太阳）对地球不同部位的不同引力作用驱动的，产生拖曳效应，而不是简单的提升。
讨论强调了陆地分布对潮汐强度的影响——一些海岸线经历显著变化，而另一些海岸线几乎没有变化。参与者们争论了离心力与引力的作用，共识倾向于认为不同的引力是主要驱动因素。 历史背景也被分享，包括开尔文勋爵19世纪的潮汐预测机器——现代机器学习的前身——以及查尔斯·达尔文之子乔治·达尔文的贡献。
除了核心物理学之外，评论者还注意到天气的影响以及当前预测模型的局限性，以及一些有趣但科学依据较少的理论，将潮汐与电磁现象联系起来。 这段对话强调了人们对这种自然现象的持久着迷以及不断探索以充分理解其复杂性的努力。
苏萨姆·帕尔展示了一种仅使用CSS的解决方案来解决经典的FizzBuzz问题，仅用四行CSS代码即可实现序列输出。该代码利用CSS计数器和`:nth-child()`选择器在列表(`<li>`)元素内生成序列。 具体来说，它为每个列表项递增计数器，除非该项能被5整除，否则显示计数器值，为3的倍数添加前缀“Fizz”，为5的倍数添加后缀“Buzz”。 作者承认该解决方案并非针对代码高尔夫优化，而是将其作为起点提供。提供了一个精简版的代码，去除了所有空格，长度为152个字符。帕尔邀请读者提交更短、更高效的解决方案。一个可运行的示例可在css-fizz-buzz.html找到。
## CSS FizzBuzz：代码高尔夫挑战
一则Hacker News讨论围绕着仅使用CSS实现经典的FizzBuzz问题。挑战的重点是最小化代码尺寸（“代码高尔夫”）。 多个解决方案被提出，利用CSS特性如`:nth-child()`、`::before`、`::after`和CSS计数器。
最初使用有序列表(`<ol>`)的尝试实现了较小的字符数（129），但存在视觉错位问题。为了改善外观所做的修正增加了代码尺寸。 其他方法使用了`<p>`标签和CSS变量，旨在进一步优化。
参与者争论了在字符计数中包含HTML大小的“公平性”，认为真正最小的解决方案需要JavaScript来生成必要的列表元素。 该讨论突出了使用CSS解决问题的创造性（尽管非常规）方法，以及代码简洁性和可读性/正确性之间的固有权衡。 解决方案的字符数从68到152不等，并且仍在不断尝试实现尽可能小的实现。
## REPL 的调试适配器协议：nluarepl & hprofdap 调试适配器协议 (DAP) 传统上用于调试，但令人惊讶的是，它非常适合构建 REPL（读取-求值-打印循环）。这种方法被用于创建诸如 **nluarepl**（Neovim 的 Lua REPL）和 **hprofdap**（用于检查 Java 堆转储）之类的工具。 DAP 的 `evaluate` 命令允许客户端发送表达式进行求值，并返回 `result` 以及可选的 `type`。重要的是，它包含一个 `variablesReference`，可以以 UI 中可导航的树的形式表示结构化数据。可以使用 `variables` 命令检索更多详细信息，从而可以深入检查数据结构，即使是嵌套或循环引用。DAP 还支持代码补全等功能。 虽然 DAP 包含断点处理等调试特定功能，但这些功能可以被绕过或为 REPL 使用而最小化实现——例如，nluarepl 使用日志点代替断点。使用 DAP 的主要动机是 **重用现有的调试 UI 元素**（例如 `nvim-dap` 中的元素），并避免重新发明 REPL 界面，从而将开发精力集中在核心求值逻辑上。这种方法提供了一种熟悉的用户体验，具有一致的键映射和行为。