4

因此，当我尝试声明大于 10000x10000 的矩阵时，我发现Eigen包崩溃。我需要声明一个这样的矩阵.. 大约 13000x13000 个元素可靠。我进行了如下测试：

for( int tortureEigen = 1 ; tortureEigen < 50000 ; tortureEigen++ )
{
  printf( "Torturing Eigen with %dx%d..\n", tortureEigen, tortureEigen ) ;
  Eigen::MatrixXd m( tortureEigen, tortureEigen ) ;
}

我的机器（6 GB RAM）在 14008 个元素处崩溃。

我有点失望！我认为 Eigen 就像 MATLAB 或 octave 并且不应该使用更大的数组崩溃，即使它确实撞到了磁盘或其他东西..

更重要的是，当我运行这个测试并保持 TaskMan 处于打开状态时，创建这些矩阵的进程甚至不会使用那么多内存。TaskMan 报告低于 2k 的使用量。

使用 Eigen 2.0.15 稳定版

4

4 回答 4

6

本征开发人员在这里。您最好在我们的支持渠道（例如论坛）上询问 Eigen 问题... ;-)

简短的回答：您使用的是固定大小的矩阵还是动态大小的矩阵？

  • 如果是固定尺寸，则切换到动态尺寸（对于如此大的尺寸，无论如何这都是不费吹灰之力）

  • 如果您遇到动态大小矩阵的错误，我会感到惊讶，但同时我可以看到值 10000 的来源。无论如何，如果您升级到 eigen3（开发分支），您的问题就会消失。

于 2010-08-11T03:35:41.033 回答
4

这里的所有答案都有帮助！

事实证明，当编译为32 位应用程序时，如果您像我一样尝试声明一个密集的 MatrixXd大于 14000 个元素左右，则 Eigen 将崩溃。崩溃发生_aligned_malloc在 Eigen 分配代码 (MatrixXd::resize()) 中返回 0，这意味着 1.5GB 的连续对齐 RAM 无法在 32 位下分配，这是有道理的，因为这接近一半最大可寻址内存位置。我想，在 4.0 中找到超过 1.5 GB 的连续空间真的不太可能！不幸的是，升级到 Eigen 3.0并不能解决问题。

解决方案#1

好的，所以我用 64 位编译，在我的 6GB 机器上，程序成功运行，密集的 MatrixXd 分配和解决方案工作得很好。

解决方案#2

另一种解决方案是使用DynamicSparseMatrix<double>. Sparse 不会在大尺寸分配上崩溃，即使是 32 位应用程序，但 API 支持解决是另一回事（API 似乎想要转换为 MatrixXd 密集类型以解决，这给我们留下了相同的原始问题。）

于 2010-08-14T16:27:42.773 回答
1

在 Eigen 文档中：

密集与稀疏：这个 Matrix 类处理密集的，而不是稀疏的矩阵和向量。对于稀疏矩阵和向量，请参阅稀疏模块。
密集矩阵和向量是普通的常用系数数组。所有系数都存储在一个普通的连续数组中。这与稀疏矩阵和向量不同，其中系数存储为非零系数列表。

让我们看看，10000x10000x8（双矩阵）大约 1.5GB。这大约是 32 位操作系统下连续堆块的最大大小，可以预期。尝试稀疏矩阵。

如果你真的需要这么大的密集矩阵，那么你还有一些其他的问题：计算会在下次断电之前结束吗？

于 2010-08-10T14:08:53.477 回答
1

鉴于您的硬件规格，我只能假设您在 64 位操作系统上运行。

即使内存被分页到页面文件，您仍然可能崩溃。这可能意味着内存碎片化，或者您的页面文件仍然太小。如果是这样，您应该将您的页面文件提高到 8 或 12 GB 左右。

于 2010-08-10T14:15:25.517 回答