lua - 如何在 Linux 上超过 64 位 LuaJIT 的 1gb 内存限制？

Question

概述是我正在对代码进行原型(prototype)设计以了解我的问题空间，并且我遇到了“ panic :调用 Lua API 时出现不 protected 错误(内存不足)”错误。我正在寻找绕过这个限制的方法。

环境底线是 Torch，一个运行在 LuaJIT 上的科学计算框架，LuaJIT 运行在 Lua 上。我需要 Torch，因为我最终想在 GPU 上解决我的神经网络问题，但要到达那里，我需要一个很好的问题表示来提供给网络。我(卡住)在 Centos Linux 上，我怀疑尝试在 32 位模式下从源代码重建所有部分(据报道这会将 LuaJIT 内存限制扩展到 4gb)如果它对所有的都有效，那将是一场噩梦图书馆。

问题空间本身可能不是特别相关，但总的来说，我有一些点的数据文件，我计算它们之间的距离，然后对这些距离进行 bin(即制作直方图)以尝试计算出最有用的范围。方便地，我可以创建复杂的 Lua 表，其中包含各种 bin 和 torch.save() 计数的困惑，然后稍后将其拾取并使用不同的标准化等进行检查 - 所以在玩了一个月后，我发现这是真的很容易和强大。

我可以让它工作查看多达 3 个距离，每个 15 个 bin(15x15x15 加上开销)，但这只能通过添加显式garbagecollection()调用并为每个数据文件使用fork()/wait()，以便外部循环将保持如果一个数据文件(几千个)仍然超出内存限制并使 child 崩溃，则运行。这变得更加痛苦，因为现在每个成功的子进程都必须读取、修改和写入当前的 bin 计数集——而我目前最大的文件是 36mb。我想要更大(更多的垃圾箱)，并且真的更愿意将计数保留在我似乎无法访问的 15 GB RAM 中。

所以，这里有一些我想到的路径；如果您可以确认/否认其中任何一个将/不会让我超出 1gb 边界，或者只会提高我在其中的效率，请发表评论。如果您能提出另一种我没有想到的方法，请发表评论。

我是否错过了一种启动 Lua 进程的方法，我可以从中读取任意表？毫无疑问，我可以将我的问题分解成更小的部分，但是从 stdio 解析返回表(如从系统调用到另一个 Lua 脚本)似乎容易出错，并且写入/读取小的中间文件将是大量的磁盘 i/o。

我是否缺少高内存模块中的存储和访问表？这似乎是我真正想要的，但还没有找到它

FFI C 数据结构可以放在 1gb 之外吗？情况似乎并非如此，但我当然对首先导致限制的原因缺乏充分的了解。我怀疑这会让我比通用 Lua 表的效率提高一些，因为它已经超出了原型(prototype)设计的范围？ (除非我对每个更改都进行大量编码)

当然，我可以通过在 C 中编写扩展来摆脱困境(Torch 似乎支持应该超出限制的网络)，但我在那里的简短调查发现了对“lightuserdata”指针的引用——这是否意味着更正常的扩展获胜也不能超过 1gb 吗？这似乎也为原型(prototype)设计工作带来了沉重的开发成本。

我很了解 C，所以走 FFI 或扩展路线不会打扰我 - 但我从经验中知道，以这种方式封装算法既非常优雅，又非常痛苦，有两个地方可以隐藏错误。在堆栈上的表中处理包含表的数据结构似乎也不是很好。在我做出这个努力之前，我想确定最终结果真的会解决我的问题。

感谢您阅读长文。

Answer 1

只有 LuaJIT 本身分配的对象被限制在前 2GB 内存中。这意味着使用 ffi.new 分配的表、字符串、完整用户数据(即不是 lightuserdata)和 FFI 对象将计入限制，但分配有 malloc 的对象, mmap等不受此限制(无论是否由 C 模块或 FFI 调用)。

使用 malloc 分配结构的示例:

ffi.cdef[[
    typedef struct { int bar; } foo;
    void* malloc(size_t);
    void free(void*);
]]

local foo_t = ffi.typeof("foo")
local foo_p = ffi.typeof("foo*")

function alloc_foo()
    local obj = ffi.C.malloc(ffi.sizeof(foo_t))
    return ffi.cast(foo_p, obj)
end

function free_foo(obj)
    ffi.C.free(obj)
end

在 LuaJIT 3.0 IIRC 中实现的新 GC 不会有这个限制，但我最近没有听到任何关于它的发展的消息。

来源: http://lua-users.org/lists/lua-l/2012-04/msg00729.html