Đây có phải là cách thiết thực để giải quyết 'Không đủ bộ nhớ' từ LuaJit với Torch

Question

StanfordNLP's TreeLSTM, khi được sử dụng với tập dữ liệu có> 30 nghìn trường hợp, khiến LuaJit gặp lỗi với "Không đủ bộ nhớ". Tôi đang giải quyết vấn đề này bằng cách sử dụng LuaJit Data Structures. Để có được tập dữ liệu bên ngoài heap của lua, cây cần được đặt trong LDS.Vector.

Kể từ khi LDS.Vector giữ cdata, bước đầu tiên là làm cho các loại cây vào một đối tượng 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; 
]]) 

Ngoài ra còn có những thay đổi nhỏ mà cần phải được thực hiện trong read_data.lua để xử lý loại CData mới. Sử dụng LDS dường như là một cách tiếp cận hợp lý để giải quyết giới hạn bộ nhớ cho đến nay; tuy nhiên, CTree yêu cầu một trường có tên 'nhà soạn nhạc'.

Nhà soạn nhạc thuộc loại nn.gModule. Để tiếp tục với giải pháp này sẽ liên quan đến việc tạo một typedef của nn.gModule dưới dạng cdata, bao gồm việc tạo một typedef cho các thành viên của nó. Trước khi tiếp tục, điều này có vẻ như hướng đi đúng không? Có ai có kinh nghiệm với vấn đề này?

Answer 1

Như bạn đã khám phá, đại diện cho dữ liệu có cấu trúc theo cách thân thiện với LuaJIT là một chút đau đớn vào lúc này.

Trong triển khai Tree-LSTM, mỗi bảng cây giữ một con trỏ đến một thể hiện trình soạn thảo chủ yếu cho hiệu quả trong thực hiện.

Một cách giải quyết khác để tránh đánh máy nn.gModule sẽ sử dụng trường idx hiện tại để lập chỉ mục thành một bảng các phiên bản trình soạn nhạc. Trong cách tiếp cận này, các cặp (sentence_idx, node_idx) có thể được sử dụng duy nhất xác định một nhà soạn nhạc trong một bảng hai cấp độ tổng thể của các nhà soạn nhạc. Để tránh các vấn đề về bộ nhớ, mã dọn dẹp hiện tại có thể được thay thế bằng một dòng đặt chỉ mục tương ứng trong bảng thành nil.