Nofl: A Precise Immixa year agohttps://arxiv.org/abs/2503.16971Nofl是基于Immix设计的精确内存管理器，允许回收对象之间的所有空闲空间，直至分配器的最小对齐要求。该论文提出了Nofl布局，围绕其构建了收集器库，并开发了新的Scheme到C编译器用于评估。初步评估显示，在微基准测试中，对于紧凑到充足的堆大小，Nofl性能优于标准复制和标记-清除收集器。这项工作包括与其他收集器的比较，并运行有限的微基准测试以评估性能。
Unlocking Ractors: Object_ida year agohttps://byroot.github.io/ruby/performance/2025/04/26/unlocking-ractors-object-id...Ruby中的Ractor正在通过修复bug和减少竞争点来不断改进，从而提升性能。最近的改动包括用无锁的Hash-Set替代fstring_table，使Ractor的JSON基准测试速度提升了一倍。由于Ruby 2.7中为保持GC压缩稳定性而引入的内部哈希表实现变更，#object_id方法现已成为一个竞争点。针对#object_id的优化提案包括延迟初始化ID到对象的映射表，以及将对象ID内联存储在对象中以减少同步需求。对于无法内联存储实例变量的对象（如T_STRING、T_ARRAY），仍需寻找替代方案来避免全局同步问题。该补丁旨在让#object_id访问在多数情况下实现无锁化，但通用对象和无锁形状创建仍需进一步研究。
Packed Data Support in Haskella year agohttps://arthi-chaud.github.io/posts/packed/打包数据允许直接使用数据而无需反序列化，通过利用L1缓存提高性能packed-data Haskell库借助Template Haskell实现数据的打包/解包及遍历，无需编组步骤核心特性包括Packable/Unpackable类型类、NeedsBuilder缓冲区管理机制及类型安全的PackedReader读取操作基准测试显示混合结果：相较原生Haskell，部分操作更快（如AST求值），部分更慢（如最右节点检索）未来工作包括通过AST生成C代码优化PackedReader以减少开销，并探索强类型语言的类似实现方案
Building Small Go Containers?a year agohttps://github.com/randomizedcoder/go_nix_simple该代码库展示了构建容器的不同方法并测量其性能表现尝试使用Nix加速构建，但发现虽然可重复构建却速度缓慢示例程序包含一个打印计数器和Prometheus计数器的循环添加了额外库(database/sql/clickhouse-go/pyroscope-go/go-redis/v9)进行性能测试发现scratch容器比distroless更小，质疑后者的推荐价值UPX压缩工具在amd64架构测试正常，但提示苹果电脑可能存在兼容问题构建摘要显示各容器构建的时间、大小和分层情况提升Golang容器构建速度的技巧包括避免复制.git目录和利用Docker缓存建议在CI/CD环境中使用Athens代理缓存模块使用验证工具通过检查打印循环和Prometheus计数器确保容器正常运行部署Squid代理测试HTTP缓存，但由于HTTPS限制其效果有限Nix构建与Docker构建对比显示Nix的缓存优势
Strings Just Got Fastera year agohttps://inside.java/2025/05/01/strings-just-got-faster/JDK 25通过使String::hashCode基本可常量折叠来提升字符串性能使用字符串键的不可变映射性能显著提升，最高可达8倍加速该优化利用@Stable注解标记String.hash以实现常量折叠常量折叠允许直接调用malloc()等原生方法而无需中间步骤存在一个边界情况：哈希码为零的字符串（如空字符串）无法受益于此优化未来的JEP 502：稳定值（预览）可能将类似优化扩展到用户代码
Making PyPI's test suite 81% fastera year agohttps://blog.trailofbits.com/2025/05/01/making-pypis-test-suite-81-faster/Trail of Bits与PyPI合作改进测试套件性能，将执行时间从163秒缩短至30秒关键优化包括：使用pytest-xdist并行执行测试（减少67%）、采用Python 3.12的sys.monitoring统计覆盖率（减少53%）、优化测试发现机制及移除不必要的导入测试用例从3,900条增至4,700条的同时实现了81%的性能提升并行化需要解决数据库夹具、覆盖率报告和测试输出可读性等问题利用Python 3.12的sys.monitoring优化覆盖率统计使测试时间再降53%通过testpaths配置策略性优化，测试发现时间减少66%移除ddtrace等非必要导入带来3.4%的适度改进数据库迁移压缩的概念验证虽显示潜力，但因复杂性未被合并更快的测试能通过鼓励频繁全面测试来提升安全性其他项目的快速优化建议：测试并行化、覆盖率优化、加速测试发现、清理无用导入
Fast(er) regular expression engines in Rubya year agohttps://serpapi.com/blog/faster-regular-expression-engines-in-ruby/SerpApi在从现代网站提取数据时面临挑战，有时不得不使用正则表达式，尽管可能存在延迟问题。Ruby的默认正则引擎Onigmo在扫描时间上存在弱点，促使人们探索替代方案，如re2、rust/regex和pcre2。re2由谷歌开发，能抵抗ReDoS攻击且有维护良好的Ruby绑定，但在处理Unicode文本时表现不佳。rust/regex整体速度最快，尤其擅长Unicode文本，但缺乏即用型Ruby绑定，且在正则集功能上存在局限。pcre2被众多产品广泛采用，但其Ruby绑定过时且缺乏JIT支持，导致在对比中可行性较低。基准测试显示rust/regex在多数场景下优于re2和Ruby，特别是处理Unicode文本和复杂模式时。re2在ASCII文本和有界重复模式中表现良好，但在Unicode感知匹配器和高最大边界条件下表现欠佳。rust/regex的集合功能可能比顺序正则表达式慢，除非精心优化，这凸显了全面测试的必要性。re2和rust/regex都能处理无效的UTF-8字节序列，而Ruby遇到此类输入时会失败。最终结论倾向于rust/regex的整体性能和Unicode支持，而re2更适合ASCII文本和抗ReDoS攻击场景。
Runtime: Green tea garbage collector (Go)a year agohttps://github.com/golang/go/issues/73581Green Tea是一种新型并行标记算法，旨在提升内存局部性并降低垃圾回收的CPU开销该算法通过处理更大尺寸的连续内存块(span)而非单个对象，显著改善空间和时间局部性重点优化512字节以内的小对象span，因其每次扫描能获得更高的边际收益采用分布式工作窃取队列优化任务分配，有效降低众核系统上的资源争用单对象扫描优化技术确保稀疏span场景下与现有算法保持性能相当基准测试显示，在GC密集型工作负载中CPU开销降低10-50%，在多核系统上展现更优的扩展性未来计划包括开发SIMD加速扫描内核，以及探索高指针密度场景的集中器网络方案该原型已开放测试，计划作为可选特性纳入Go 1.25版本
Load-Store Conflictsa year agohttps://zeux.io/2025/05/03/load-store-conflicts/meshoptimizer实现了高效的网格数据解压缩几何压缩算法。索引解码器在不同编译器中的性能差异与微架构细节相关。边FIFO结构用于编码/解码三角形索引时的冗余处理。存储到加载的转发对性能至关重要；加载/存储大小不匹配会导致问题。GCC-14通过使用向量操作更新FIFO，性能优于Clang-20。GCC-15因存储-加载冲突导致显著的性能倒退。Apple M4在Clang-17下展现出卓越性能，得益于高效的加载/存储对。存储-加载转发问题可能导致高性能代码中出现意外的性能骤降。
The State of SSL Stacksa year agohttps://www.haproxy.com/blog/state-of-ssl-stacksHAProxy分享关于SSL库性能挑战及替代方案的见解OpenSSL 3.0引入显著的性能退步与兼容性问题性能测试显示OpenSSL 3.0表现逊于BoringSSL、LibreSSL、WolfSSL和AWS-LC等替代方案SSL库的功能性需求包括支持TLS版本、QUIC协议、证书管理及加密套件性能考量凸显了SSL/TLS操作的计算强度及其对能效的影响维护挑战涉及安全漏洞、向后兼容性及需要专业知识OpenSSL转向3.0作为长期支持版本迫使多数Linux发行版被迫采用，尽管存在局限BoringSSL、LibreSSL、WolfSSL和AWS-LC等替代方案在性能、兼容性和功能上各有取舍QUIC协议的实现挑战及OpenSSL缺乏标准API阻碍了其采用性能测试揭示OpenSSL 3.0因过度锁操作和原子操作导致扩展性差且CPU占用率高AWS-LC和WolfSSL展现出优异的性能与扩展性，其中AWS-LC受益于原子操作而非锁机制对HAProxy用户的建议包括采用AWS-LC或WolfSSL以获得更好性能，并考虑QuicTLS实现QUIC支持SSL库的未来尚不明朗，OpenSSL性能问题未解而替代方案正崭露头角改进希望包括OpenSSL发布性能更优的新LTS版本，以及高效替代方案的更广泛采用
Performance Improvements in JDK 24a year agohttps://inside.java/2025/03/19/performance-improvements-in-jdk24/JDK 24相比JDK 23的性能改进核心库：增强外部函数与内存API(FFM)批量操作以提升性能通过利用隐藏类优化字符串拼接策略，降低运行时开销通过减少数据类型转换，SHA3算法性能提升最高达27%JDK 24中最终确定的ClassFile API，改进了字节码生成并减少启动开销运行时：JEP 491通过减少同步期间的固定操作来提升虚拟线程可扩展性二级超级缓存(SSC)优化，提升多线程应用中的类型查询性能在x64平台上使用AVX2 SIMD指令使String::indexOf性能提升1.3倍通过延迟扩展简化G1垃圾收集器屏障，降低C2编译开销JEP 483引入提前(AOT)类加载和链接机制以改善启动速度和内存占用实验性JEP 450将对象头大小缩减至64位，预计可降低10-20%内存使用RISC-V平台改进包括字符串比较和内部函数实现优化鼓励社区参与进一步性能优化并提供反馈
Time Between The Lines: how memory access affects performance (2015)a year agohttps://bitbashing.io/memory-performance.html现代硬件内存层次结构使得内存访问模式显著影响程序性能传统复杂度分析假设内存访问均匀，这与具有多级缓存的现代硬件实际情况不符缓存和预取等硬件优化技术利用空间局部性加速顺序内存访问实验表明由于缓存效率，顺序内存访问速度远快于随机或间接访问通过优化数据布局（如将相关数据分组）可减少缓存未命中，从而显著提升性能缓存未命中较少的算法可能优于理论更快但内存访问模式不佳的算法
Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/Oa year agohttps://pganalyze.com/blog/postgres-18-async-ioPostgres 18 引入了针对读取操作的异步I/O（AIO），这一重大架构变革旨在提升性能，尤其在云环境中效果显著。异步I/O允许Postgres并发发起多个读取请求，通过无需等待每次读取完成即可继续执行来降低延迟。Postgres 18 新增了`io_method`配置参数，提供三种模式：`sync`（传统同步I/O）、`worker`（使用专用I/O工作线程）和`io_uring`（Linux专属的高性能I/O接口）。AWS基准测试表明异步I/O可使读取性能翻倍，其中`io_uring`通过减少系统调用开销表现最佳。在Postgres 18中，`effective_io_concurrency`参数影响力增强，可直接控制使用异步I/O方法时的预读请求数量。新增的监控工具如`pg_aios`视图可追踪进行中的I/O操作，这对传统监控可能遗漏部分活动的异步I/O场景尤为重要。异步I/O改变了`EXPLAIN ANALYZE`中的I/O耗时报告方式，可能导致I/O工作量统计偏低，需要调整性能分析策略。未来Postgres版本可能将异步I/O扩展至写入操作，进一步优化现代工作负载的性能表现。
Medium Is the New Largea year agohttps://mistral.ai/news/mistral-medium-3Mistral Medium 3以低于8倍的成本提供最先进的性能支持混合部署或本地/VPC选项，简化企业部署流程在编程、STEM任务和多模态理解方面表现卓越性能超越Claude Sonnet 3.7、Llama 4 Maverick和Cohere Command A等竞争对手支持定制化训练后优化及企业系统集成已在Mistral La Plateforme和Amazon Sagemaker上线，即将登陆IBM WatsonX、NVIDIA NIM、Azure AI Foundry和Google Cloud Vertex金融、能源和医疗领域的测试客户正将其用于客服、业务流程和数据分析预告未来将发布更强大的'large'版本模型
A sub-millisecond GC for .NET?a year agohttps://blog.applied-algorithms.tech/a-sub-millisecond-gc-for-net介绍Satori——一款实验性的.NET垃圾回收器(GC)，其性能表现显著提升关键改进包括：中位暂停时间提升50倍，99%百分位暂停时间优化超100倍，堆内存大小改善3倍垃圾回收在C#/.NET、Java和Go等高级语言的内存管理中至关重要，但在Rust和C/C++等底层语言中并非必需GC可能导致破坏性的'全局暂停'现象，影响应用程序性能，在高吞吐量场景下尤为明显.NET垃圾回收器的历史演进：从工作站GC到服务器GC，相继推出并发GC和后台GC等创新与其他生态系统的对比：特别是Go语言的GC，其极低暂停时间令.NET开发者艳羡由Vladimir Sadov开发的Satori GC承诺亚毫秒级暂停时间，达到行业顶尖水平性能基准测试显示：Satori大幅降低GC时间占比，并在各百分位提升分配速率和缩短暂停时间试用Satori的具体步骤：构建面向.NET 8.0的应用程序，以自包含模式发布，并替换特定DLL文件鼓励开发者在实际工作负载中测试Satori并提供反馈，以影响其开发优先级和方向
Bold linker v0.2.0 release – bold just got fastera year agohttps://github.com/kubkon/bold/releases/tag/v0.2.0Bold在链接Zig stage3编译器时，相比v0.1.0版本实现了1.19倍的加速当前Bold在基准测试中已超越LLD，但仍比苹果重构的ld64链接器慢测试数据显示ld.sh比bold.sh快2.18倍，比lld.sh快2.39倍，比bold-0.1.0.sh快2.58倍主要变更包括升级至Zig 0.14、确保Atom.Index类型安全以及迁移至安全的File.Index
Fastgron: Make JSON greppable, super fasta year agohttps://github.com/adamritter/fastgronfastgron 是一款基于C++20开发的高性能JSON转GRON转换器，使用了simdjson库。在处理大文件时，它比gron快50倍，使大型JSON文件更易于检索。fastgron 可以将JSON转换为离散的赋值语句，便于数据探索和过滤。支持反向操作，将过滤后的GRON输出重新转换回JSON格式。可通过Arch (yay)、Homebrew、Nix、Ubuntu和Windows等多种渠道安装。提供丰富的命令行选项，支持过滤、排序和输出自定义功能。基准测试显示，相比gron、jq和jj，fastgron具有显著的速度优势。构建需要C++20编译器、CMake，可选依赖libcurl库。未来计划增强复杂路径查询、CSV支持及多线程处理等功能。
Comparison of C/POSIX standard library implementations for Linuxa year agohttps://www.etalabs.net/compare_libcs.html针对Linux标准库实现的比较，重点关注功能丰富性与膨胀度的权衡。涵盖musl、uClibc、dietlibc和glibc，详细分析膨胀度、性能及功能指标。膨胀度指标包括静态/动态库体积、开销及最小程序体积。性能对比涉及内存分配、字符串操作、线程及正则表达式等场景。功能对比包含POSIX兼容性、C标准支持及安全特性。详细说明ABI/版本稳定性、算法选择及目标架构支持。标注MIT、LGPL和GPL等许可证差异对可用性的影响。未来计划包括性能基准测试及纳入更多库实现。
Show HN: LoopMix128 – Fast C PRNG (.46ns), 2^128 Period, BigCrush/PractRand Passa year agohttps://github.com/danielcota/LoopMix128LoopMix128是一种极快速的伪随机数生成器(PRNG)，保证周期为2^128经数学证明具有单射性，并通过BigCrush和PractRand(32TB)测试且零异常高性能：比Java Random快8.75倍，比Java xoroshiro128++快21%，比C语言版xoroshiro128++快75%优良统计质量：通过TestU01的BigCrush测试套件及32TB量级的PractRand测试采用128位高低计数器循环技术实现2^128的超长周期192位状态空间具备数学证明的单射性，经Z3定理证明器验证支持并行流处理，得益于其192位状态空间的单射特性性能基准测试显示其优于wyrand、xoroshiro128++等现代PRNG算法使用不同初始种子进行多次PractRand测试均零失败，可疑结果极少由Daniel Cota通过对PRNG技术的深度探索而创造
FastTwoSum Is Faster Than TwoSuma year agohttps://pavpanchekha.com/blog/fast-two-sum.html浮点运算存在精度问题，但TwoSum和FastTwoSum这类算法能通过同时计算总和与舍入误差来量化不精确性。TwoSum需6次浮点运算（延迟15-20周期），而FastTwoSum仅需3次运算（延迟9-12周期）但要求输入值按绝对值排序。若输入未排序，分支预测错误惩罚会使FastTwoSum慢于TwoSum，但无分支条件操作可缓解此问题。苹果M1处理器测试显示TwoSum耗时15周期，FastTwoSum为9周期，排序版介于两者之间。在Intel Coffee Lake架构上，GCC编译的FastTwoSum基础排序版表现优异，但Clang因分支生成差异导致性能波动。SIMD实现相比无分支条件移动操作未能显著提升性能。最优FastTwoSum变体在ARM和Intel平台均比TwoSum快20%以上，但需精心优化编译器以避免分支。若硬件直接实现TwoSum或等效功能，可大幅降低双精度浮点加法的运算开销。