GHC non può gestire tabelle di ricerca di grandi dimensioni

Ho bisogno di utilizzare una tabella di ricerca in 3 dimensioni. Il tavolo stesso ha valori doppi 73x73x73 (389017).GHC non può gestire tabelle di ricerca di grandi dimensioni

module Hammer.Texture.Table3D where 

import qualified Data.Vector   as V 
import qualified Data.Vector.Unboxed as U 

import   Data.Vector.Unboxed (Vector) 

table3D :: V.Vector (V.Vector (Vector Double)) 
table3D = V.fromList [table0, table1, ... table72] 

table0 = V.fromList $ map U.fromList [ 
    [1.973921e+01, 0.000000e+00, ... 0.000000e+00], 
    ..... 
    [1.973921e+01, 0.000000e+00, ... 0.000000e+00]] 
..... 
table72 = V.fromList $ map U.fromList [ 
    [1.973921e+01, 0.000000e+00, ... 0.000000e+00], 
    ..... 
    [1.973921e+01, 0.000000e+00, ... 0.000000e+00]]

Il problema è che GHC non può gestire questa dimensione del vettore doppio o [Doppia], la compilazione GHC prende un sacco di tempo (~ 2 min) fino a quando, finalmente, la memoria fa saltare in aria. Sembra che ci sia una perdita di memoria su GHC o qualche bug perché funziona perfettamente con String molto grande ([Char]).

Quali soluzioni, se presenti, sono disponibili per la creazione di tabelle di ricerca "grandi" (tipo doppio) utilizzando GHC?

fonte

2013-07-21 LambdaStaal

Avete provato a utilizzare array come 'Data.Array' o' Data.Array.Repa'? Sembra che tu abbia bisogno di un contenitore di dimensioni fisse piuttosto che di un vettore –

Quindi ... questo è un tipo di file sorgente di 10 MB con l'intera tabella in forma di testo al suo interno? Perché dovresti farlo in questo modo? Sono abbastanza sicuro che non sarebbe un problema generare "Vector's di questo tipo in fase di esecuzione, leggere molto più efficientemente da un file binario. Anche se ammetto che semplicemente inserire la fonte è un buon modo per evitare facilmente l'uso di IO. – leftaroundabout

Se funziona bene con stringa ... perché non stringhe hardcode (non doppie)? (quindi 'leggi', ovviamente), è brutto ma forse funziona bene ... – josejuan

Mi vengono in mente due possibilità:

serializzare i vettori in un file, e all'avvio del programma li deserializzare (magari utilizzando unsafeInterleaveIO se si desidera che questo accada quando la tabella di ricerca viene utilizzato per la prima piuttosto che quando inizia il programma).
Se la tabella di ricerca è davvero scarsa come suggerisce lo pseudocodice, è consigliabile utilizzare una struttura di dati sparsa, ad es. Data.Map o anche solo una semplice funzione. Se necessario, è possibile utilizzare questa struttura dati sparsa per generare i vettori (di nuovo in fase di esecuzione).

fonte

2013-07-21 18:50:51

GHC non può gestire tabelle di ricerca di grandi dimensioni

risposta

Problemi correlati