在Python2.7脚本中使用Python3.x中生成的.npy数组？

我在Python3.4脚本中生成并保存了许多numpy数组，即

import numpy as np
np.save('array1.npy')

我在Python2.7中使用这些工具时，在性能方面似乎遇到了一些小问题（可能更多）。有区别吗

编辑：numpy数组是多维的，大约包含

1e8

元素。我在Python2.7中运行的脚本，其中包含在Python3.4中创建的.npy文件，这些脚本将永远/无休止地运行。我怀疑存在兼容性问题

在上面的一条（现已删除）评论中，OP将32位版本的Python2.7与64位版本的Python3.4进行了比较。这几乎可以肯定是问题中提到的“性能问题”的原因

---

（999、1000、1000）

float64数组（如OP正在使用的）的大小约为8GB。虽然OP有16GB的RAM，但32位进程的地址不能超过4GB。因此，它要么崩溃，要么开始交换并变得极其缓慢

我试图在Python2.7中使用这些工具时，在性能方面似乎遇到了一些小问题

-您能在代码片段中演示一下吗？请更具体一些。它是什么类型的数组？多大？什么样的“性能问题”？@ali\m这些是阵列形状

（999、1000、1000）

。像这样的尺寸<代码>数据类型（'float64'）。至于行为，如果我在Python2.7脚本中运行这些Python3阵列，它们有时会“暂停”，即它们不会运行到完成状态。这些阵列中的每个阵列的大小约为8GB。你确定你不仅仅是在内存不足吗？如果你能显示你的脚本在哪里暂停，那会很有帮助-是在你读取数组的时候，还是在以后处理它们的时候，问题会出现？你能举个例子吗？为什么它会开始交换？进程运行时遇到了地址空间限制，而不是物理内存限制。@user2357112您可能是对的-我必须承认，我以前从未遇到过地址空间的进程级限制。在我看来，只有两种情况会发生——要么进程无法为阵列分配足够的内存并立即崩溃，要么它将开始交换。后一种情况似乎更符合OP所描述的情况。无论如何，我确信问题的根本原因是Python进程的比特性。请随便给我写一个更好的答案：-）