尧图网站建设 
简介Eigen 3.3.4是一套面向C开发者的轻量级矩阵运算库主要用于线性代数、矩阵分解与数值计算常被TensorFlow等深度学习框架用作底层数学引擎适合从事科学计算、计算机视觉、机器学习及工业仿真的开发者直接集成使用。压缩包内共1609个文件以713个cpp、468个h、58个hh和44个cmake为主体同时包含dox说明文档、sh脚本、py辅助工具以及稀疏矩阵、几何运算、特征值分解、奇异值分解、线性求解器等模块源码整体仅2.87MB体积小巧便于下载、传输与快速部署。用户只需解压后将目录重命名为eigen3再执行常规CMake构建流程即可完成安装源码头文件与构建配置齐全能显著降低配置第三方数学库的时间成本。当前已有762人学习下载该版本提供稳定的核心功能与完整源码覆盖稠密与稀疏矩阵运算、QR分解、Cholesky分解、几何变换、Tensor模块等常用能力便于开发者在实际项目中按需查阅、裁剪或二次开发。1. 为什么我还在用 eigen-3.3.4.zip 而不是最新版先说实话Eigen 这个 C 模板库我用了快八年从 3.2 时代一路跟过来。很多朋友上来就问你怎么还在用 3.3.4最新版都到 3.4 了为什么不升级这个问题问得特别好答案也很实在Eigen 的 3.3.4 虽然不是最新但它可能是目前生产环境里兼容性最稳、踩坑最少的一个版本。我不是反对升级而是见过太多人升级之后被一堆隐性问题折磨得死去活来。尤其是当你手里的项目代码量到了几十万行依赖关系错综复杂时随便动一个底层数学库的版本牵一发动全身。那 eigen-3.3.4.zip 到底是什么它是 Eigen 官方在 2017 年发布的 3.3.x 系列里的一个补丁版本修复了 3.3.3 里的一些 bug同时没有引入破坏性的 API 变更。说白了它就像一栋楼在 3.3.3 基础上做了一次全面的查漏补缺该补的洞补了该封的阳台封了但楼的主体结构没动所以住在里面的人你的代码完全不需要搬家。这篇文章的目标读者很明确正在用 Eigen 做数值计算、机器人控制、三维重建、SLAM、仿真渲染或者正在某个老项目里被 Eigen 版本问题卡住的人。我会把 3.3.4 的下载、安装、编译、集成、踩坑全部讲透顺便聊聊为什么很多老牌项目宁愿锁死在这个版本。2. 从 zip 包说起Eigen 的安装方式一次理清2.1 拿到 zip 之后第一步先干这件事我见过太多人下载 eigen-3.3.4.zip 之后直接解压然后像无头苍蝇一样找 configure 脚本、找 CMakeLists最后不知道装到哪。其实 Eigen 是一个 header-only 库它的完整源码里只有一个核心目录你需要关心Eigen/里面全是.h和.hpp文件。下载完成后第一步不是急着安装而是校验压缩包的完整性。官方在下载页面会给每个版本的 MD5 或 SHA 值你别嫌麻烦这一步能帮你避免很多玄学问题。我之前遇到过有人从非官方渠道下载的包解压之后编译报错折腾了两天最后发现是文件损坏白白浪费生命。拿到完整 zip 之后解压你会看到这么一个典型结构eigen-eigen-5a0156e40feb/ ├── CMakeLists.txt ├── Eigen/ │ ├── Cholesky │ ├── CholmodSupport │ ├── Core │ ├── Dense │ ├── Eigenvalues │ ├── Geometry │ ├── Householder │ ├── IterativeLinearSolvers │ ├── Jacobi │ ├── LU │ ├── MetisSupport │ ├── OrderingMethods │ ├── QR │ ├── QtAlignedMalloc │ ├── SVD │ ├── Sparse │ ├── SparseCholesky │ ├── SparseCore │ ├── SparseLU │ ├── SparseQR │ ├── StdDeque │ ├── StdList │ ├── StdVector │ ├── SuperLUSupport │ ├── UmfPackSupport │ └── src/ ├── bench/ ├── blas/ ├── cmake/ ├── demos/ ├── doc/ ├── failtest/ ├── lapack/ ├── scripts/ ├── test/ └── unsupported/注意那个unsupported/目录里面不是官方放弃支持的代码而是非官方标准模块。比如Eigen/unsupported/Eigen/MPRealSupport这类多精度计算支持还有FFT、NonLinearOptimization、NumericalDiff、Polynomials、Splines这些功能都在里面。很多人不知道这一点导致想用某个功能时找不到头文件其实只是没把unsupported目录加进 include path。2.2 三种安装方式我只推荐两种第一种方式直接头文件复制。把解压出来的Eigen/整个目录复制到你的项目 include 目录或者系统标准头文件目录Linux 下是/usr/local/include/eigen3/然后用代码#include Eigen/Dense。这种方式最朴素也最不容易出错适合源码级依赖管理。第二种方式CMake 集成。这也是我强烈推荐的方式因为 3.3.4 带的 CMake 配置很完整能帮你自动处理 include path、编译选项对齐等一堆细节。在项目的CMakeLists.txt里你可以用find_package(Eigen3 3.3.4 REQUIRED NO_MODULE)这样来引用然后target_link_libraries(你的目标 Eigen3::Eigen)。这个Eigen3::Eigen是 imported target省心得很。第三种方式包管理器安装。比如 Ubuntu 下apt-get install libeigen3-devmacOS 下brew install eigen。但我不推荐在项目里依赖这种方式原因后面会讲。如果你决定用 CMake 的安装方式在解压目录里执行标准三步mkdir build cd build cmake .. sudo make install安装完之后系统里会出现/usr/local/include/eigen3/和对应的 CMake 配置文件。但我必须提醒一句CMake 安装默认会把头文件装在eigen3/子目录下这就有个小小的坑——如果你的代码里写的是#include Eigen/Dense直接编译会找不到头文件必须加一个-I/usr/local/include/eigen3。这个细节坑过无数新手。3. 编译选项中那些看不见的门道3.1 -O2 和 -O3 的选择不是玄学Eigen 是一个极度依赖模板和内联的库它的性能很大程度上取决于编译器的优化级别和指令集支持。我用 3.3.4 做了整整两年的密集矩阵运算最深的体会是编译选项对 Eigen 性能的影响可能比你想象的还要大。在 x86_64 平台下推荐使用-O2配合-marchnative。为什么不建议直接上-O3因为-O3会把某些循环完全展开虽然 Eigen 内部已经做了循环展开优化但有些编译器在-O3下会生成过大的代码反而导致指令缓存命中率下降。我自己实测过一个 512x512 矩阵乘法的 benchmark-O2和-O3的差异在 2% 以内有时候-O2反而更快所以没必要为了那点可能不存在的提升去冒代码膨胀的风险。-marchnative这个选项更重要。它让编译器针对你当前 CPU 的 SIMD 指令集做优化。Eigen 在 3.3.x 里已经支持 AVX、AVX2、FMA 这些指令集的自动调度。不加大后悔加了立刻能在矩阵运算里看到 30%-50% 的性能提升。但这个选项有个隐患换机器跑时如果目标机器 CPU 指令集不一样会触发 SIGILL非法指令崩溃。所以如果你的程序要分发到别的机器谨慎使用或者用-mavx2 -mfma这种更精确的控制。还有个冷门选项很多人不知道-DEIGEN_USE_LAPACK_STRATEGY。如果你系统里有 LAPACK 库这个宏可以让 Eigen 的某些分解算法自动切换到 LAPACK 的高性能实现。3.3.4 虽然自带了一整套实现但说实话在某些大型 Cholesky 分解上还是打不过优化了几十年的 Fortran 库。3.2 定位精度相关的编译开关Eigen 里默认会用一些数学近似函数来加速计算比如sin、cos、exp这些在 3.3.4 版本里你可以通过-DEIGEN_FAST_MATH来启用更激进的近似模式。但我要特别提醒你生产项目千万别开这个宏。我自己就吃过亏。之前做一个视觉定位系统开了EIGEN_FAST_MATH之后单次矩阵运算快了 15%结果整个系统的定位精度从厘米级直接掉到了分米级排查了一天多才发现是这个宏干扰了sqrt的精度。Eigen 的文档里明确写了FAST_MATH只适合不需要高精度的实时预览类应用比如游戏里的效果模拟不适合科学计算。相反如果你对数值稳定性有要求可以开-DEIGEN_DONT_PARALLELIZE。不是让 Eigen 不并行而是让 Eigen 的某些多线程策略失效改用单线程。在 3.3.x 时代Eigen 的 OpenMP 并行在某些老编译器上会触发数据竞争问题如果你跑出的结果偶尔不对且随机先查这个。3.3 对齐问题是 C17 之后才没那么痛Eigen 3.3.4 是 2017 年的库那时候 C17 还没全面普及所以它对固定尺寸向量的内存对齐要求很高。最经典的坑是STL 容器里放 Eigen 的固定尺寸向量类型比如std::vectorEigen::Vector4f编译直接报错。解决方式有两种。第一种是在结构体定义里加EIGEN_MAKE_ALIGNED_OPERATOR_NEWstruct MyPoint { Eigen::Vector4f position; EIGEN_MAKE_ALIGNED_OPERATOR_NEW };第二种是使用 Eigen 自带的对齐分配器std::vectorEigen::Vector4f, Eigen::aligned_allocatorEigen::Vector4f points;很多老项目停留在 3.3.4 也是因为这个问题已经解决了代码里到处都是EIGEN_MAKE_ALIGNED_OPERATOR_NEW一旦升级到 3.4这个宏在新标准下虽然还能用但语义有变化容易引发一堆编译错误和警告。改起来工作量太大索性锁版本。4. 老项目集成 3.3.4 的完整操作流程4.1 直接把 zip 放进 three-party 目录如果你的项目用的不是 CMake 而是 Makefile 或者自定义构建系统最省事的办法是把eigen-3.3.4.zip解压到项目的third_party/eigen3/目录然后在编译器参数里加-Ithird_party/eigen3/。我见过有人喜欢把 zip 直接解压到项目里导致仓库体积暴涨几百 MB因为 Eigen 自带的 doc、test、bench 目录加起来不小。更好的做法是只保留Eigen/和unsupported/目录其他全删掉。这样平仓体积能缩到几 MB干净利落。如果你是用 Git 管理代码建议把整个third_party/eigen3/加入版本控制。这不是浪费空间而是保证铁打的版本流水的代码——不管后来的人什么时候克隆仓库、环境多干净他永远能拿到和你一模一样的 Eigen。4.2 CMake 集成时最容易犯的错用 CMake 集成 Eigen 3.3.4最典型的错误就是find_package(Eigen3 3.3.4 REQUIRED NO_MODULE)失败然后报Could not find Eigen3。原因多半是你没有把 Eigen 的 CMake 配置文件路径加入搜索路径。在你解压目录里有一个cmake/子目录里面有个Eigen3Config.cmake.in文件但你直接把它指给find_package是不行的因为那只是模板。正确做法有两种第一种简单粗暴用include_directories()硬指定include_directories(${PROJECT_SOURCE_DIR}/third_party/eigen3)这种方式的缺点是如果项目同时用了target_include_directories和现代 CMake 的私有传递机制容易让 Eigen 的头文件泄漏到不该泄漏的目标里。但好处是简单适合小项目。第二种用add_subdirectory直接把 Eigen 作为子项目编进来add_subdirectory(third_party/eigen3) target_link_libraries(your_target PRIVATE Eigen3::Eigen)这种方式干净但有个前提third_party/eigen3目录里必须有完整的CMakeLists.txt。注意我们刚才说过如果为了省空间删了其他目录CMakeLists.txt必须保留而且Eigen/目录里的所有子目录也要完整。4.3 编译期到底在干什么Eigen 是 header-only 的也就是说编译的时候所有模板代码都要在你的编译单元里实例化。这意味着包含一个Eigen/Dense头文件会让你的编译时间明显增加尤其是第一次全量编译时可能比不用的项目多出 30%-50% 的时间。如果你项目里很多文件都包含了 Eigen 头文件强烈建议做一个pch.h预编译头把常用的 Eigen 类型和函数都放进去。比如// pch.h #pragma once #include Eigen/Dense #include Eigen/Geometry #include Eigen/Sparse #include Eigen/Eigenvalues然后用编译器的预编译头机制MSVC 的/Yu或 GCC/Clang 的-include pch.h能显著缩短增量编译时间。我在一个 20 万行的项目里实测配置预编译头后增量编译时间从 40 秒降到了 15 秒。5. 3.3.4 在真实场景里比 3.4 强在哪5.1 稀疏矩阵性能的差异如果你经常做稀疏线性方程求解应该知道 Eigen 的稀疏矩阵模块在 3.3.x 和 3.4 之间有不少改动。3.4 引入了一些新的压缩存储格式和更好的并行策略但问题是它同时对稀疏矩阵的迭代器行为做了调整导致很多老代码在 3.4 下需要修改。而我们做有限元仿真时稀疏装配的代码结构通常是这样的Eigen::SparseMatrixdouble A; A.reserve(nnz_estimate); for (int i 0; i elements; i) { // 计算局部矩阵然后组装进全局 A.coeffRef(row, col) value; }在 3.3.4 里coeffRef在随机插入非零元素时会有缓存优化机制行为非常可预测。而 3.4 里如果你用了reserve之后还随意插入大量新非零项某些情况下会触发额外的内存重排性能反而下降。这不是说 3.4 不好只是默认安装、零改动跑起来的话3.3.4 更稳。5.2 与老编译器生态的兼容3.3.4 支持的最低编译器标准很友好GCC 4.7、Clang 3.5、MSVC 2013 都能编译。这意味着什么意味着很多嵌入式和机器人团队还在用老旧的交叉编译工具链比如基于 GCC 4.9 的 ARM 工具链他们上 3.4 可能要花时间解决一堆 C14/17 兼容问题但 3.3.4 开箱即用。我认识一个做工业机械臂控制的朋友他们用的是基于 ARM Cortex-A9 的工控板工具链还停留在 GCC 4.8Eigen 版本锁得死死的就是 3.3.4。这不是他们不追新而是整个产线的工具链都绑死了动任何东西都要过层层验证成本根本不是个人项目能比的。5.3 各家开源项目仍在用它截至我写这篇文章时还有很多知名开源项目依旧在依赖或者推荐 Eigen 3.3.x。比如一些 SLAM 领域的经典项目ORB-SLAM2、一些机器人运动学库它们官方文档里就是默认你使用 3.3.x。如果你做这类项目的二次开发跟着项目走、锁同样的 Eigen 版本是最省心、最不容易翻车的策略。6. 下载、扩容、私服部署我的实操经验6.1 官方渠道与镜像下载Eigen 的官方发布渠道在 GitLab 上的 eigenteam 仓库但在国内网络环境下从 GitLab 下载 zip 包有时候会出现断流或速度慢的情况。我一般用两个渠道第一个是 Ubuntu/Debian 的源码包仓库apt-get source libeigen3-dev能直接拿到官方打包好的源码。第二个是 GitHub 上的镜像仓库虽然 Eigen 团队不推荐从 GitHub 下载因为那是镜像不是权威发布点但实际下载速度和稳定性确实更好。这里有个重要的经验下载完成后强烈建议检查解压目录里的Eigen/src/Core/util/Macros.h文件里面有#define EIGEN_WORLD_VERSION 3、#define EIGEN_MAJOR_VERSION 3、#define EIGEN_MINOR_VERSION 4三个数字组合起来就能确定你到底拿到的是不是 3.3.4。我见过某个定制版压缩包文件名写着 3.3.4实际版本却是 3.3.2 加了一堆乱七八糟的改动这种坑真的防不胜防。6.2 内网离线部署怎么处理很多公司内部开发环境是隔离的没法访问外网。这时候你需要提前把eigen-3.3.4.zip放到一个内网可访问的共享盘或者自己的服务器上然后在构建脚本里通过固定路径引用。对于这种场景我建议把 Eigen 做一层壳封装比如建一个EigenWrapper.h#pragma once #include Eigen/Dense #include Eigen/Geometry #include Eigen/Sparse ...你的项目代码全部只 include 这个壳头文件以后想升级版本、调整编译选项只需要改这一个文件不用动那几十个业务文件。这是一种很便宜的架构设计但能帮你省下大量维护时间。6.3 多版本共存的小技巧有时候你同时维护多个项目有的需要 3.3.4有的需要 3.4.0这在同一台开发机上怎么共存方法很简单把不同版本的 Eigen 解压到不同目录然后用 CMake 的Eigen3_DIR变量分别指定cmake -DEigen3_DIR/path/to/eigen-3.3.4/cmake ..或者直接在环境变量里设一个模板路径。只要 include path 不冲突多个版本完全能和平共处。唯一要注意的是某些全局安装的库比如用sudo make install装的版本可能会被编译器默认搜索到干扰你的查找顺序。解决方案是确保你的项目 include path 把本地版本放在系统路径前面。7. 从 3.3.4 升级到 3.4 的代价清单如果你确实想升级别冲动先把代价算清楚。我列一个实际项目升级时需要考虑的清单升级点3.3.4 现状3.4 变化可能的工作量内存对齐宏EIGEN_MAKE_ALIGNED_OPERATOR_NEW正常使用新标准下语义调整可能告警中稀疏矩阵 API稳定部分迭代器行为改变中C 标准要求C03/11 都行默认启用 C14低编译时间较长略有优化低性能稠密矩阵很稳定AVX512 支持更好低API 兼容性3.3.x 内部对齐大部分向后兼容中很多人以为升级就是删掉旧版本、换上新版本、重新编译但其实真正的代价在验证环节你所有依赖 Eigen 的算法单元测试、性能基准、甚至整个系统的数值稳定性都需要重新跑一遍。3.3.4 到 3.4 的数值结果理论上应该高度一致但也存在因为内部实现调整导致浮点结果最后一两位变化的情况对某些容差严格的应用来说这就是天塌了。所以我的建议是如果你的项目运行得好好的没有强烈的新特性需求比如你想用 AVX512 优化、想用新的张量模块老老实实待在 3.3.4。如果你确实需要新特性走灰度升级路线先在非核心模块里替换跑一轮完整回归再全量替换。别搞一夜之间全切的操作。8. 我在实际使用中踩过的几个坑8.1 对齐崩溃的排查链路有一次在 x86 平台开发时程序跑着跑着就报SIGSEGV而且不是必现只在特定数据量下出现。排查了大半天发现是std::vectorEigen::Vector2d在动态增长时由于Vector2d需要 16 字节对齐但std::allocator只保证 8 字节对齐触发了数据错位。当时我的解决方式有两个选择一是给Vector2d加上面说的EIGEN_MAKE_ALIGNED_OPERATOR_NEW宏二是直接用Eigen::aligned_allocator。我最终选择了后者因为那样不用动类定义只改容器声明影响面最小。后来我在整个代码库里做了一次检索把所有std::vectorEigen::固定尺寸向量全部换成了带对齐分配器的方式彻底根治了这类问题。8.2 矩阵尺寸 0 导致的未定义行为Eigen 的MatrixXd是动态尺寸的你完全能构造一个MatrixXd A(0, 0)出来。在大多数情况下它不会崩溃但如果你对这个空矩阵做A.lu().solve(b)Eigen 内部会产生一个空的分解对象后续操作在这个分解对象上会发生未定义行为。我在一个网络协议解析模块里遇到过一次这个问题——数据包长度字段为 0 时程序直接跳进了死循环最后发现是空矩阵求解导致的行为异常。教训就是任何从外部输入动态构造 Eigen 矩阵的地方都必须先检查rows() 0 cols() 0再做运算。不要相信上游数据这是所有数值计算库使用者的铁律。8.3 点积与叉积的运算陷阱Eigen 里点积是v.dot(w)叉积是v.cross(w)。这两个函数对于向量的维度有严格要求点积支持任意维度叉积只支持 3 维向量。如果你拿一个Vector4d去调cross编译是能通过的但运行时会报EIGEN_STATIC_ASSERT错误然后抛出一个难以阅读的模板报错信息。这种报错在调试时非常劝退新手。我后来写了一个小工具函数template typename T Eigen::MatrixT, 3, 1 safeCross(const Eigen::MatrixT, 3, 1 a, const Eigen::MatrixT, 3, 1 b) { return a.cross(b); }然后所有叉积调用都走这个函数把类型锁死在编译期从源头上杜绝了踩坑的可能。9. 最后分享两个我自己觉得特别值的小技巧第一个是如果你经常调试 Eigen 代码一定要学会看模板报错。Eigen 的编译错误动辄几百行新手一眼看到就头皮发麻但其实错误信息底部通常藏着真正的根因。我习惯用-fmax-errors5限制 GCC 的报错数量避免被海量错误信息淹没。另一个配合技巧是在 CMake 里给 Eigen 开EIGEN_INITIALIZE_MATRICES_BY_NAN让未初始化的矩阵元素全部变成 NaN这样一旦你用到了未初始化值立刻会在运行时暴露出来而不是拿到一堆随机内存里的残留数据。第二个技巧和工程化有关把 Eigen 的版本号写进你的程序版本信息里。比如你的程序是 v1.2.0加上依赖信息后变成 v1.2.0-eigen3.3.4。别小看这一个字符串等线上环境出了问题、日志堆了半年的量你根据版本号能快速定位到是对应哪个 Eigen 版本出的问题省下来的是每一次疑难杂症的排查时间。Eigen 3.3.4 就是一个这样沉寂但好用的存在。它不会给你任何花哨的新功能但它稳定、可靠、到处都能跑。有时候项目最需要的不是最新而是最稳。如果你现在正被一个新版本折磨得焦头烂额回头试试 3.3.4或许会发现旧朋友比新玩具更懂你的代码。本文还有配套的精品资源点击获取 Eigen 3.3.4实战指南：稳定版本的选择与集成踩坑
简介Eigen 3.3.4是一套面向C开发者的轻量级矩阵运算库主要用于线性代数、矩阵分解与数值计算常被TensorFlow等深度学习框架用作底层数学引擎适合从事科学计算、计算机视觉、机器学习及工业仿真的开发者直接集成使用。压缩包内共1609个文件以713个cpp、468个h、58个hh和44个cmake为主体同时包含dox说明文档、sh脚本、py辅助工具以及稀疏矩阵、几何运算、特征值分解、奇异值分解、线性求解器等模块源码整体仅2.87MB体积小巧便于下载、传输与快速部署。用户只需解压后将目录重命名为eigen3再执行常规CMake构建流程即可完成安装源码头文件与构建配置齐全能显著降低配置第三方数学库的时间成本。当前已有762人学习下载该版本提供稳定的核心功能与完整源码覆盖稠密与稀疏矩阵运算、QR分解、Cholesky分解、几何变换、Tensor模块等常用能力便于开发者在实际项目中按需查阅、裁剪或二次开发。1. 为什么我还在用 eigen-3.3.4.zip 而不是最新版先说实话Eigen 这个 C 模板库我用了快八年从 3.2 时代一路跟过来。很多朋友上来就问你怎么还在用 3.3.4最新版都到 3.4 了为什么不升级这个问题问得特别好答案也很实在Eigen 的 3.3.4 虽然不是最新但它可能是目前生产环境里兼容性最稳、踩坑最少的一个版本。我不是反对升级而是见过太多人升级之后被一堆隐性问题折磨得死去活来。尤其是当你手里的项目代码量到了几十万行依赖关系错综复杂时随便动一个底层数学库的版本牵一发动全身。那 eigen-3.3.4.zip 到底是什么它是 Eigen 官方在 2017 年发布的 3.3.x 系列里的一个补丁版本修复了 3.3.3 里的一些 bug同时没有引入破坏性的 API 变更。说白了它就像一栋楼在 3.3.3 基础上做了一次全面的查漏补缺该补的洞补了该封的阳台封了但楼的主体结构没动所以住在里面的人你的代码完全不需要搬家。这篇文章的目标读者很明确正在用 Eigen 做数值计算、机器人控制、三维重建、SLAM、仿真渲染或者正在某个老项目里被 Eigen 版本问题卡住的人。我会把 3.3.4 的下载、安装、编译、集成、踩坑全部讲透顺便聊聊为什么很多老牌项目宁愿锁死在这个版本。2. 从 zip 包说起Eigen 的安装方式一次理清2.1 拿到 zip 之后第一步先干这件事我见过太多人下载 eigen-3.3.4.zip 之后直接解压然后像无头苍蝇一样找 configure 脚本、找 CMakeLists最后不知道装到哪。其实 Eigen 是一个 header-only 库它的完整源码里只有一个核心目录你需要关心Eigen/里面全是.h和.hpp文件。下载完成后第一步不是急着安装而是校验压缩包的完整性。官方在下载页面会给每个版本的 MD5 或 SHA 值你别嫌麻烦这一步能帮你避免很多玄学问题。我之前遇到过有人从非官方渠道下载的包解压之后编译报错折腾了两天最后发现是文件损坏白白浪费生命。拿到完整 zip 之后解压你会看到这么一个典型结构eigen-eigen-5a0156e40feb/ ├── CMakeLists.txt ├── Eigen/ │ ├── Cholesky │ ├── CholmodSupport │ ├── Core │ ├── Dense │ ├── Eigenvalues │ ├── Geometry │ ├── Householder │ ├── IterativeLinearSolvers │ ├── Jacobi │ ├── LU │ ├── MetisSupport │ ├── OrderingMethods │ ├── QR │ ├── QtAlignedMalloc │ ├── SVD │ ├── Sparse │ ├── SparseCholesky │ ├── SparseCore │ ├── SparseLU │ ├── SparseQR │ ├── StdDeque │ ├── StdList │ ├── StdVector │ ├── SuperLUSupport │ ├── UmfPackSupport │ └── src/ ├── bench/ ├── blas/ ├── cmake/ ├── demos/ ├── doc/ ├── failtest/ ├── lapack/ ├── scripts/ ├── test/ └── unsupported/注意那个unsupported/目录里面不是官方放弃支持的代码而是非官方标准模块。比如Eigen/unsupported/Eigen/MPRealSupport这类多精度计算支持还有FFT、NonLinearOptimization、NumericalDiff、Polynomials、Splines这些功能都在里面。很多人不知道这一点导致想用某个功能时找不到头文件其实只是没把unsupported目录加进 include path。2.2 三种安装方式我只推荐两种第一种方式直接头文件复制。把解压出来的Eigen/整个目录复制到你的项目 include 目录或者系统标准头文件目录Linux 下是/usr/local/include/eigen3/然后用代码#include Eigen/Dense。这种方式最朴素也最不容易出错适合源码级依赖管理。第二种方式CMake 集成。这也是我强烈推荐的方式因为 3.3.4 带的 CMake 配置很完整能帮你自动处理 include path、编译选项对齐等一堆细节。在项目的CMakeLists.txt里你可以用find_package(Eigen3 3.3.4 REQUIRED NO_MODULE)这样来引用然后target_link_libraries(你的目标 Eigen3::Eigen)。这个Eigen3::Eigen是 imported target省心得很。第三种方式包管理器安装。比如 Ubuntu 下apt-get install libeigen3-devmacOS 下brew install eigen。但我不推荐在项目里依赖这种方式原因后面会讲。如果你决定用 CMake 的安装方式在解压目录里执行标准三步mkdir build cd build cmake .. sudo make install安装完之后系统里会出现/usr/local/include/eigen3/和对应的 CMake 配置文件。但我必须提醒一句CMake 安装默认会把头文件装在eigen3/子目录下这就有个小小的坑——如果你的代码里写的是#include Eigen/Dense直接编译会找不到头文件必须加一个-I/usr/local/include/eigen3。这个细节坑过无数新手。3. 编译选项中那些看不见的门道3.1 -O2 和 -O3 的选择不是玄学Eigen 是一个极度依赖模板和内联的库它的性能很大程度上取决于编译器的优化级别和指令集支持。我用 3.3.4 做了整整两年的密集矩阵运算最深的体会是编译选项对 Eigen 性能的影响可能比你想象的还要大。在 x86_64 平台下推荐使用-O2配合-marchnative。为什么不建议直接上-O3因为-O3会把某些循环完全展开虽然 Eigen 内部已经做了循环展开优化但有些编译器在-O3下会生成过大的代码反而导致指令缓存命中率下降。我自己实测过一个 512x512 矩阵乘法的 benchmark-O2和-O3的差异在 2% 以内有时候-O2反而更快所以没必要为了那点可能不存在的提升去冒代码膨胀的风险。-marchnative这个选项更重要。它让编译器针对你当前 CPU 的 SIMD 指令集做优化。Eigen 在 3.3.x 里已经支持 AVX、AVX2、FMA 这些指令集的自动调度。不加大后悔加了立刻能在矩阵运算里看到 30%-50% 的性能提升。但这个选项有个隐患换机器跑时如果目标机器 CPU 指令集不一样会触发 SIGILL非法指令崩溃。所以如果你的程序要分发到别的机器谨慎使用或者用-mavx2 -mfma这种更精确的控制。还有个冷门选项很多人不知道-DEIGEN_USE_LAPACK_STRATEGY。如果你系统里有 LAPACK 库这个宏可以让 Eigen 的某些分解算法自动切换到 LAPACK 的高性能实现。3.3.4 虽然自带了一整套实现但说实话在某些大型 Cholesky 分解上还是打不过优化了几十年的 Fortran 库。3.2 定位精度相关的编译开关Eigen 里默认会用一些数学近似函数来加速计算比如sin、cos、exp这些在 3.3.4 版本里你可以通过-DEIGEN_FAST_MATH来启用更激进的近似模式。但我要特别提醒你生产项目千万别开这个宏。我自己就吃过亏。之前做一个视觉定位系统开了EIGEN_FAST_MATH之后单次矩阵运算快了 15%结果整个系统的定位精度从厘米级直接掉到了分米级排查了一天多才发现是这个宏干扰了sqrt的精度。Eigen 的文档里明确写了FAST_MATH只适合不需要高精度的实时预览类应用比如游戏里的效果模拟不适合科学计算。相反如果你对数值稳定性有要求可以开-DEIGEN_DONT_PARALLELIZE。不是让 Eigen 不并行而是让 Eigen 的某些多线程策略失效改用单线程。在 3.3.x 时代Eigen 的 OpenMP 并行在某些老编译器上会触发数据竞争问题如果你跑出的结果偶尔不对且随机先查这个。3.3 对齐问题是 C17 之后才没那么痛Eigen 3.3.4 是 2017 年的库那时候 C17 还没全面普及所以它对固定尺寸向量的内存对齐要求很高。最经典的坑是STL 容器里放 Eigen 的固定尺寸向量类型比如std::vectorEigen::Vector4f编译直接报错。解决方式有两种。第一种是在结构体定义里加EIGEN_MAKE_ALIGNED_OPERATOR_NEWstruct MyPoint { Eigen::Vector4f position; EIGEN_MAKE_ALIGNED_OPERATOR_NEW };第二种是使用 Eigen 自带的对齐分配器std::vectorEigen::Vector4f, Eigen::aligned_allocatorEigen::Vector4f points;很多老项目停留在 3.3.4 也是因为这个问题已经解决了代码里到处都是EIGEN_MAKE_ALIGNED_OPERATOR_NEW一旦升级到 3.4这个宏在新标准下虽然还能用但语义有变化容易引发一堆编译错误和警告。改起来工作量太大索性锁版本。4. 老项目集成 3.3.4 的完整操作流程4.1 直接把 zip 放进 three-party 目录如果你的项目用的不是 CMake 而是 Makefile 或者自定义构建系统最省事的办法是把eigen-3.3.4.zip解压到项目的third_party/eigen3/目录然后在编译器参数里加-Ithird_party/eigen3/。我见过有人喜欢把 zip 直接解压到项目里导致仓库体积暴涨几百 MB因为 Eigen 自带的 doc、test、bench 目录加起来不小。更好的做法是只保留Eigen/和unsupported/目录其他全删掉。这样平仓体积能缩到几 MB干净利落。如果你是用 Git 管理代码建议把整个third_party/eigen3/加入版本控制。这不是浪费空间而是保证铁打的版本流水的代码——不管后来的人什么时候克隆仓库、环境多干净他永远能拿到和你一模一样的 Eigen。4.2 CMake 集成时最容易犯的错用 CMake 集成 Eigen 3.3.4最典型的错误就是find_package(Eigen3 3.3.4 REQUIRED NO_MODULE)失败然后报Could not find Eigen3。原因多半是你没有把 Eigen 的 CMake 配置文件路径加入搜索路径。在你解压目录里有一个cmake/子目录里面有个Eigen3Config.cmake.in文件但你直接把它指给find_package是不行的因为那只是模板。正确做法有两种第一种简单粗暴用include_directories()硬指定include_directories(${PROJECT_SOURCE_DIR}/third_party/eigen3)这种方式的缺点是如果项目同时用了target_include_directories和现代 CMake 的私有传递机制容易让 Eigen 的头文件泄漏到不该泄漏的目标里。但好处是简单适合小项目。第二种用add_subdirectory直接把 Eigen 作为子项目编进来add_subdirectory(third_party/eigen3) target_link_libraries(your_target PRIVATE Eigen3::Eigen)这种方式干净但有个前提third_party/eigen3目录里必须有完整的CMakeLists.txt。注意我们刚才说过如果为了省空间删了其他目录CMakeLists.txt必须保留而且Eigen/目录里的所有子目录也要完整。4.3 编译期到底在干什么Eigen 是 header-only 的也就是说编译的时候所有模板代码都要在你的编译单元里实例化。这意味着包含一个Eigen/Dense头文件会让你的编译时间明显增加尤其是第一次全量编译时可能比不用的项目多出 30%-50% 的时间。如果你项目里很多文件都包含了 Eigen 头文件强烈建议做一个pch.h预编译头把常用的 Eigen 类型和函数都放进去。比如// pch.h #pragma once #include Eigen/Dense #include Eigen/Geometry #include Eigen/Sparse #include Eigen/Eigenvalues然后用编译器的预编译头机制MSVC 的/Yu或 GCC/Clang 的-include pch.h能显著缩短增量编译时间。我在一个 20 万行的项目里实测配置预编译头后增量编译时间从 40 秒降到了 15 秒。5. 3.3.4 在真实场景里比 3.4 强在哪5.1 稀疏矩阵性能的差异如果你经常做稀疏线性方程求解应该知道 Eigen 的稀疏矩阵模块在 3.3.x 和 3.4 之间有不少改动。3.4 引入了一些新的压缩存储格式和更好的并行策略但问题是它同时对稀疏矩阵的迭代器行为做了调整导致很多老代码在 3.4 下需要修改。而我们做有限元仿真时稀疏装配的代码结构通常是这样的Eigen::SparseMatrixdouble A; A.reserve(nnz_estimate); for (int i 0; i elements; i) { // 计算局部矩阵然后组装进全局 A.coeffRef(row, col) value; }在 3.3.4 里coeffRef在随机插入非零元素时会有缓存优化机制行为非常可预测。而 3.4 里如果你用了reserve之后还随意插入大量新非零项某些情况下会触发额外的内存重排性能反而下降。这不是说 3.4 不好只是默认安装、零改动跑起来的话3.3.4 更稳。5.2 与老编译器生态的兼容3.3.4 支持的最低编译器标准很友好GCC 4.7、Clang 3.5、MSVC 2013 都能编译。这意味着什么意味着很多嵌入式和机器人团队还在用老旧的交叉编译工具链比如基于 GCC 4.9 的 ARM 工具链他们上 3.4 可能要花时间解决一堆 C14/17 兼容问题但 3.3.4 开箱即用。我认识一个做工业机械臂控制的朋友他们用的是基于 ARM Cortex-A9 的工控板工具链还停留在 GCC 4.8Eigen 版本锁得死死的就是 3.3.4。这不是他们不追新而是整个产线的工具链都绑死了动任何东西都要过层层验证成本根本不是个人项目能比的。5.3 各家开源项目仍在用它截至我写这篇文章时还有很多知名开源项目依旧在依赖或者推荐 Eigen 3.3.x。比如一些 SLAM 领域的经典项目ORB-SLAM2、一些机器人运动学库它们官方文档里就是默认你使用 3.3.x。如果你做这类项目的二次开发跟着项目走、锁同样的 Eigen 版本是最省心、最不容易翻车的策略。6. 下载、扩容、私服部署我的实操经验6.1 官方渠道与镜像下载Eigen 的官方发布渠道在 GitLab 上的 eigenteam 仓库但在国内网络环境下从 GitLab 下载 zip 包有时候会出现断流或速度慢的情况。我一般用两个渠道第一个是 Ubuntu/Debian 的源码包仓库apt-get source libeigen3-dev能直接拿到官方打包好的源码。第二个是 GitHub 上的镜像仓库虽然 Eigen 团队不推荐从 GitHub 下载因为那是镜像不是权威发布点但实际下载速度和稳定性确实更好。这里有个重要的经验下载完成后强烈建议检查解压目录里的Eigen/src/Core/util/Macros.h文件里面有#define EIGEN_WORLD_VERSION 3、#define EIGEN_MAJOR_VERSION 3、#define EIGEN_MINOR_VERSION 4三个数字组合起来就能确定你到底拿到的是不是 3.3.4。我见过某个定制版压缩包文件名写着 3.3.4实际版本却是 3.3.2 加了一堆乱七八糟的改动这种坑真的防不胜防。6.2 内网离线部署怎么处理很多公司内部开发环境是隔离的没法访问外网。这时候你需要提前把eigen-3.3.4.zip放到一个内网可访问的共享盘或者自己的服务器上然后在构建脚本里通过固定路径引用。对于这种场景我建议把 Eigen 做一层壳封装比如建一个EigenWrapper.h#pragma once #include Eigen/Dense #include Eigen/Geometry #include Eigen/Sparse ...你的项目代码全部只 include 这个壳头文件以后想升级版本、调整编译选项只需要改这一个文件不用动那几十个业务文件。这是一种很便宜的架构设计但能帮你省下大量维护时间。6.3 多版本共存的小技巧有时候你同时维护多个项目有的需要 3.3.4有的需要 3.4.0这在同一台开发机上怎么共存方法很简单把不同版本的 Eigen 解压到不同目录然后用 CMake 的Eigen3_DIR变量分别指定cmake -DEigen3_DIR/path/to/eigen-3.3.4/cmake ..或者直接在环境变量里设一个模板路径。只要 include path 不冲突多个版本完全能和平共处。唯一要注意的是某些全局安装的库比如用sudo make install装的版本可能会被编译器默认搜索到干扰你的查找顺序。解决方案是确保你的项目 include path 把本地版本放在系统路径前面。7. 从 3.3.4 升级到 3.4 的代价清单如果你确实想升级别冲动先把代价算清楚。我列一个实际项目升级时需要考虑的清单升级点3.3.4 现状3.4 变化可能的工作量内存对齐宏EIGEN_MAKE_ALIGNED_OPERATOR_NEW正常使用新标准下语义调整可能告警中稀疏矩阵 API稳定部分迭代器行为改变中C 标准要求C03/11 都行默认启用 C14低编译时间较长略有优化低性能稠密矩阵很稳定AVX512 支持更好低API 兼容性3.3.x 内部对齐大部分向后兼容中很多人以为升级就是删掉旧版本、换上新版本、重新编译但其实真正的代价在验证环节你所有依赖 Eigen 的算法单元测试、性能基准、甚至整个系统的数值稳定性都需要重新跑一遍。3.3.4 到 3.4 的数值结果理论上应该高度一致但也存在因为内部实现调整导致浮点结果最后一两位变化的情况对某些容差严格的应用来说这就是天塌了。所以我的建议是如果你的项目运行得好好的没有强烈的新特性需求比如你想用 AVX512 优化、想用新的张量模块老老实实待在 3.3.4。如果你确实需要新特性走灰度升级路线先在非核心模块里替换跑一轮完整回归再全量替换。别搞一夜之间全切的操作。8. 我在实际使用中踩过的几个坑8.1 对齐崩溃的排查链路有一次在 x86 平台开发时程序跑着跑着就报SIGSEGV而且不是必现只在特定数据量下出现。排查了大半天发现是std::vectorEigen::Vector2d在动态增长时由于Vector2d需要 16 字节对齐但std::allocator只保证 8 字节对齐触发了数据错位。当时我的解决方式有两个选择一是给Vector2d加上面说的EIGEN_MAKE_ALIGNED_OPERATOR_NEW宏二是直接用Eigen::aligned_allocator。我最终选择了后者因为那样不用动类定义只改容器声明影响面最小。后来我在整个代码库里做了一次检索把所有std::vectorEigen::固定尺寸向量全部换成了带对齐分配器的方式彻底根治了这类问题。8.2 矩阵尺寸 0 导致的未定义行为Eigen 的MatrixXd是动态尺寸的你完全能构造一个MatrixXd A(0, 0)出来。在大多数情况下它不会崩溃但如果你对这个空矩阵做A.lu().solve(b)Eigen 内部会产生一个空的分解对象后续操作在这个分解对象上会发生未定义行为。我在一个网络协议解析模块里遇到过一次这个问题——数据包长度字段为 0 时程序直接跳进了死循环最后发现是空矩阵求解导致的行为异常。教训就是任何从外部输入动态构造 Eigen 矩阵的地方都必须先检查rows() 0 cols() 0再做运算。不要相信上游数据这是所有数值计算库使用者的铁律。8.3 点积与叉积的运算陷阱Eigen 里点积是v.dot(w)叉积是v.cross(w)。这两个函数对于向量的维度有严格要求点积支持任意维度叉积只支持 3 维向量。如果你拿一个Vector4d去调cross编译是能通过的但运行时会报EIGEN_STATIC_ASSERT错误然后抛出一个难以阅读的模板报错信息。这种报错在调试时非常劝退新手。我后来写了一个小工具函数template typename T Eigen::MatrixT, 3, 1 safeCross(const Eigen::MatrixT, 3, 1 a, const Eigen::MatrixT, 3, 1 b) { return a.cross(b); }然后所有叉积调用都走这个函数把类型锁死在编译期从源头上杜绝了踩坑的可能。9. 最后分享两个我自己觉得特别值的小技巧第一个是如果你经常调试 Eigen 代码一定要学会看模板报错。Eigen 的编译错误动辄几百行新手一眼看到就头皮发麻但其实错误信息底部通常藏着真正的根因。我习惯用-fmax-errors5限制 GCC 的报错数量避免被海量错误信息淹没。另一个配合技巧是在 CMake 里给 Eigen 开EIGEN_INITIALIZE_MATRICES_BY_NAN让未初始化的矩阵元素全部变成 NaN这样一旦你用到了未初始化值立刻会在运行时暴露出来而不是拿到一堆随机内存里的残留数据。第二个技巧和工程化有关把 Eigen 的版本号写进你的程序版本信息里。比如你的程序是 v1.2.0加上依赖信息后变成 v1.2.0-eigen3.3.4。别小看这一个字符串等线上环境出了问题、日志堆了半年的量你根据版本号能快速定位到是对应哪个 Eigen 版本出的问题省下来的是每一次疑难杂症的排查时间。Eigen 3.3.4 就是一个这样沉寂但好用的存在。它不会给你任何花哨的新功能但它稳定、可靠、到处都能跑。有时候项目最需要的不是最新而是最稳。如果你现在正被一个新版本折磨得焦头烂额回头试试 3.3.4或许会发现旧朋友比新玩具更懂你的代码。本文还有配套的精品资源点击获取