I am exploring the potential of offloading traditional computations to a GPU, particularly for a large dataset. The data is indexed by atoms, accompanied by a list of numbers which will undergo the numeric processing.
Once constructed, this dataset remains static. My intention is to transfer the data to the GPU once and subsequently perform multiple mathematical computations on it. A concern arises if garbage collection takes place. The renaming of atoms might invalidate the return results, unless there’s a complete reload.
One solution could be to entirely disable garbage collection, which, while effective in the short term, would lead to increased memory consumption in regular Prolog operations.
Is it feasible to set a threshold, allowing garbage collection only beyond the top of the stacks as determined by a checkpoint?
Would utilizing modules help? I am uncertain whether garbage collection can be restricted or disabled within specific modules.
The ideal scenario allows the GPU to handle mathematical and search computations, while the CPU and threads manage traditional tasks.
Your insights would be appreciated. I hope I haven’t overlooked a straightforward built-in solution.
Using set_prolog_flag(gc, false) disables term-gc in the calling thread.
That is similar to generational GC. That is not implemented in SWI-Prolog. Contact me if paying for it is an option for you.
No. Modules are just namespaces for predicates. They are unrelated to atoms and terms.
I don’t have the picture clear though. I have the impression that you have large data structures in Prolog (vectors, I guess) on which you want the GPU to do some crunching. Seems you want the GPU to run concurrently working on the data on a Prolog stack that is actively used by Prolog?
Atoms should not bother you. The atom_t handle is static until the atom is garbage collected. If the atom lives on the stack this won’t happen. If it may not be on a stack and you still want to preserve it you need to call PL_register_atom() on it.
Accessing data on a Prolog stack from multiple threads may be a challenge. GC is probably out as it relies on pointer reversal and thus the data is a mess while GC is active. Best representation for an array is probably a compound term (that has unlimited arity in SWI-Prolog). At least a compound term is a simple array on the stacks.
My first intuition would be to create a proper C vector from the Prolog data, let the GPU do its work and get the results back to Prolog. An alternative might be to represent the arrays using blobs. That is fine for uniform arrays of numbers or atoms, but you cannot deal with logical variables this way (well, maybe there are ways around).
Thanks Jan
Firstly I dont have a specific task in mind at the moment,… but am typing to establish the art of the possible… Im interested in Graphs and use them often and am looking at the possible intersection of Graphs Prolog and GPU’s the graohs are static which makes things simpler and as you say i agree creation of Blobs may be best… ultimatyly thats all a gpu takes…
Im thinking of graphs in GPUs for accelerated caclulations… and searches. so some mapping between prolog representation and a ‘BASE’ representation may suffice, with an element of decode once returned.
perhaps affinity calculations etc …
But at the moment learning… may be best to place core graph in module with no GC and have an outer set of logic make demands on it …