c - 这是使用 Torch 从 LuaJit 解析 'Not enough memory' 的实用方法吗

Question

StanfordNLP's TreeLSTM ，当与具有 > 30K 个实例的数据集一起使用时，会导致 LuaJit 出现“内存不足”错误。我正在使用 LuaJit Data Structures 解决这个问题.为了在 lua 堆之外获取数据集，需要将树放在 LDS.Vector 中。

由于 LDS.Vector 包含 cdata，因此第一步是将 Tree 类型转换为 cdata 对象:

local ffi = require('ffi')

ffi.cdef([[
typedef struct CTree {
   struct CTree* parent;
   int num_children;
   struct CTree* children [25];
   int idx;
   int gold_label;
   int leaf_idx;
} CTree;
]])

还需要在 read_data.lua 中进行一些小改动以处理新的 cdata CTree 类型。到目前为止，使用 LDS 似乎是解决内存限制的合理方法；但是，CTree 需要一个名为“composer”的字段。

Composer 是 nn.gModule 类型。要继续此解决方案，将涉及创建 nn.gModule 的 typedef 作为 cdata，包括为其成员创建 typedef。在继续之前，这看起来是正确的方向吗？有没有人有这个问题的经验？

Answer 1

正如您所发现的，目前以 LuaJIT 堆友好的方式表示结构化数据有点痛苦。

在 Tree-LSTM 实现中，每个树表都包含一个指向 composer 实例的指针，主要是为了实现方便。

避免 typedef-ing nn.gModule 的一种解决方法是使用现有的 idx 字段索引到 composer 实例表中。在这种方法中，可以使用对 (sentence_idx, node_idx) 在 Composer 实例的全局两级表中唯一标识 Composer 。为避免内存问题，可以将当前清理代码替换为将表中相应索引设置为 nil 的行。