【问题标题】:Using .npy arrays generated in Python3.x in Python2.7 scripts?在 Python2.7 脚本中使用 Python3.x 中生成的 .npy 数组?
【发布时间】:2016-03-14 02:40:43
【问题描述】:

我有许多在 Python 3.4 脚本中生成并保存的 numpy 数组,即

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

我似乎在尝试在 Python2.7 中使用这些性能方面遇到了一些小问题(也许更多)。有区别吗?

编辑:numpy 数组是多维的,大约有 1e8 元素。我在 Python2.7 中使用在 Python3.4 中创建的 .npy 文件运行的脚本需要永远/无休止地运行。我怀疑存在兼容性问题。

【问题讨论】:

  • I seem to be running into slight issues trying to use these in Python2.7 in terms of performance - 你能在代码 sn-p 中显示这个吗?
  • 请更具体。它是一个什么样的数组?多大?什么样的“性能问题”?
  • @ali_m 这些是(999, 1000, 1000) 形状的数组。像这样的尺寸。 dtype('float64')。至于行为,如果我在 Python2.7 脚本中运行这些 Python3 数组,它们有时会“停止”,即它们不会运行完成
  • 每个数组的大小约为 8GB。你确定你不仅仅是内存不足吗?
  • 如果您可以显示 哪里 您的脚本停滞不前会有所帮助 - 是在您读取数组时字面意思,还是稍后在处理它们时出现问题?能举个例子吗?

标签: python arrays python-2.7 python-3.x numpy


【解决方案1】:

在上面的一条(现已删除)评论中,原来 OP 正在比较 Python2.7 的 32 位版本和 Python3.4 的 64 位版本。这几乎肯定是问题中提到的“性能问题”的原因。

(999, 1000, 1000) float64 数组,例如 OP 正在使用的数组,大小约为 8GB。尽管 OP 有 16GB 的 RAM,但 32 位进程将无法处理超过 4GB 3GB of memory 的地址。因此,它必须要么崩溃,要么开始交换并变得非常慢。

【讨论】:

  • 为什么会开始交换?该进程正在运行到地址空间限制,而不是物理内存限制。
  • @user2357112 你可能是对的——我必须承认我以前从未达到地址空间的进程级别限制。据我所知,只有两种情况之一可能发生 - 进程将无法为数组分配足够的内存并立即崩溃,或者它将开始交换。后一种情况似乎与 OP 所描述的更加一致。无论如何,我确信问题的根本原因是 Python 进程的位数。写一个更好的答案,让我直截了当:-)
猜你喜欢
  • 1970-01-01
  • 2018-07-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多