Re: Caching in the dynamic database

Vitor had a talk at the last ICLP, introducing some form
of limited predicates that are much more compact than
normal predicates.  If I recall well, it demanded all
clauses to be facts and I think it also had limits on
the head arguments.  That was particularly intended to
load huge tables with some form of `case data'.

Michael says he is interested in user-data that can
be unused for long periods of time.  If you have really
many users I guess this does require some form of demand
loading to avoid long startup times, even if you could
manage to load all predicates in memory.  If you already
have demand loading, it makes some sense to unload for
releasing memory as well.

There are two typical problems.  One is that it is hard
to deal with data that does not exist.  Is it not loaded
or does it really not exist?  Explicit negation is one
possible solution.  The other is when to throw out old
data and whether you can load it before you really need it.
These are the common issues with paging, caching, etc. :-(

It also relates a little to SWI-Prolog's JIT indexing.
Like YAP (AFAIK), it creates indexes on first use and
never deletes them.  Well, this is not entirely true;
indexes are deleted if the system believes they are too
much out of date.  For example, instead of resizing a
hash index after asserts made it too small it deletes
the hash index.  It will be re-created at the right size
by the JIT indexer if it is ever needed again.

	Cheers --- Jan

On 02/12/2014 09:31 PM, Richard A. O'Keefe wrote:
> Didn't Ken Bowen's Prolog implementation have some sort
> of software paging for compiled code?
> I have a vague idea that it swapped entire predicates,
> which would be a lot easier than swapping clauses.
>
> Is it possible to partition some tables so that whole-
> predicate swapping could be done instead of clause swapping?
>
> One thing that's old technology in Smalltalk is having
> two representations of compiled code: a really compact byte
> code with a byte code interpreter and native code; for top
> speed you use the native code, for debugging and trawling
> the code for cross references you use the byte code.  And
> when memory gets tight, you throw away the native code.
> (The trick is to be able to map native code addresses back
> to byte code addresses, but that's a solved problem.)
>
> Back in the 80s SICStus Prolog had :- fast_code and
> :- compact_code directives so that you could chose which
> predicates to make small and which to make fast.
>
> Another idea that was tried for Smalltalk was swapping
> entire objects.  Before that, back in the early 70s,
> the B6700 virtual memory system took arrays and procedures
> as units of swapping, even quite small ones.
>
> Before trying anything exotic, is there any possible
> refactoring of the existing data to take less memory to
> start with?