Meta-predicates

[weitkaemper]

I am currently porting a statistical relational machine learning system from plain Prolog to Logtalk, and I have managed to reproduce the original system's behaviour on SWI in normal compilation mode. However, when loading with the optimized flag to "on", Logtalk throws existence errors on queries whose behaviour was correct in normal mode.
It seems to have to do with the resolution of meta-predicates, and the calling contexts of goals within them.

My questions:
Are there known discrepancies here between optimized and normal compilation mode?
Does anyone have any experience as to how best to debug such errors, given that they don't occur in any debug mode?

[pmoura]

There should be no differences (other than performance). Can you post a reproducible example and the errors you get? Is there a public repo with the code?

Wondering if you're calling SWI-Prolog library meta-predicates (if so, take a look at the Logtalk meta and meta_compiler libraries) and there's some issue with SWI-Prolog auto-loading mechanism.

[pmoura]

Possibly related: #143

[weitkaemper]

Thank you for your very quick replies!
I included the source files of a small component to illustrate the issue. The call

kb::compute_gradients(father(A, B), [[0.002, 0.6, -0.01]:::father(A, B)<=((true, childof(B, C)), childof(D, A))], G).

should compute a list of different numbers, some positive, some negative.
This works in normal compilation mode. In optimised mode, however, it returns a list of only 0.5 and -0.5 (which would be the case exactly if there were empty background knowledge).

logtalk_081124_mwe.zip

[weitkaemper]

As so often, I have seen the mistake just after I posted it (the meta-predicate declaration of aggregate:aggregate_all/3 in loader.lgt was incorrect). So the only remaining question (if that is still interesting) would be why that was harmless in normal mode but not in optimize mode (and why it still doesn't work in my full condebase).

[pmoura]

The code optimizations enabled by using the optimize(on) compiler option require accurate meta-predicate template information. In normal mode, in this particular case, the meta-predicate call is being resolved at runtime.

Btw, and as you asked about debugging, are you already using the VSCode Logtalk extension?

https://marketplace.visualstudio.com/items?itemName=LogtalkDotOrg.logtalk-for-vscode

See its readme for details on debugging support.

[weitkaemper]

Thank you very much for the pointer! Unfortunately I am an incorrigible emacs user, so I very much appreciate the provided emacs mode instead :)

[pmoura]

https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx

[pmoura]

I found why you get different results between compiling the code in normal mode vs compiling the code in optimal mode. Your meta-predicate declarations are incorrect as the meta-argument in the compute_gradients/3 predicate is not a goal but a term that contains goals (see the Logtalk Handbook section on meta-predicates for details). Use instead:

:- meta_predicate(compute_gradients(*,::,*)).

Also, you don't need the meta_predicate/1 directive for the aggregate_all/3 predicate. In your loader.lgt file, simply load the aggregate library using:

:- use_module(library(aggregate),[]).

[pmoura]

Simply move the following directive from the loader.lgt file to inside the scorer object:

:- meta_predicate(c_aggregate:aggregate_all(*,0,*)).

[pmoura]

You can also make the code run on both SWI-Prolog and XSB easily. In the loader.lgt file:

:- if(current_logtalk_flag(prolog_dialect, swi)).
	:- use_module(library(aggregate), []).
:- elif(current_logtalk_flag(prolog_dialect, xsb)).
	:- ensure_loaded(c_aggregate).
:- endif.

Inside the scorer object:

:- if(current_logtalk_flag(prolog_dialect, swi)).
	:- use_module(aggregate, [aggregate_all/3]).
:- elif(current_logtalk_flag(prolog_dialect, xsb)).
	:- use_module(c_aggregate, [aggregate_all/3]).
	:- meta_predicate(c_aggregate:aggregate_all(*,0,*)).
:- endif.

Also, call the aggregate_all/3 using implicit qualification.

[weitkaemper]

That worked brilliantly, thank you. Is it a general rule that meta-predicate directives for imported predicates should be included in every object that calls them, rather than globally in the loader file?

[pmoura]

Depends on the Prolog backend and the meta_predicate/1 directives (if present). A consequence of the lack of Prolog standardization. In general, you don't need to provide or override meta_predicate/1 directives for module meta-predicates as long as these are unambiguous and can be accessed using predicate_property/2. In this particular case, for XSB, we have:

| ?- predicate_property(c_aggregate:aggregate_all(_,_,_), P).

P = static;

P = exported;

no

Thus we need to provide ourselves the meta_predicate/1 directive to enable Logtalk to properly compile calls to the meta-predicate. But this is not an issue with SWI-Prolog:

?- predicate_property(aggregate:aggregate_all(_,_,_), P).
P = interpreted ;
P = visible ;
P = exported ;
P = static ;
P = transparent ;
P = (meta_predicate aggregate_all(?, 0, -)) ;
...

[weitkaemper]

You can also make the code run on both SWI-Prolog and XSB easily. In the loader.lgt file:

...

Also, call the aggregate_all/3 using implicit qualification.

That's exactly what I am doing in my actual application. In fact, there is a lot more conditional compilation happening...
I just stripped that down to provide a sort-of minimal working example for this thread.

[pmoura]

The code you shared suggests an application of the many worlds design pattern. See e.g. https://logtalk.org/2019/11/13/many-worlds-design-pattern.html

[pmoura]

Running the plain Prolog query using swipl -O takes 19.206 seconds, i.e. ~3 seconds faster than the Logtalk version. Logtalk sets by default the SWI-Prolog optimise flag to true. Given the performance issue I mentioned above with circular references, I find the small performance expected and reasonable.

[weitkaemper]

That is indeed completely reasonable, and I am not sure why the difference is somewhat larger for me (but still OK). Since I am personally using and running the program under XSB, I was more concerned with the larger performance drop there than under SWI-Prolog.

[pmoura]

Hard to tell. Trying the Prolog version with XSB in my Ubuntu 20 VM gives an error:

| ?- time(b_rlr(father(_,_),WC)).
[Compiling /home/pmoura/xsbgit/XSB/prolog-commons/c_numlists]
[Module c_numlists compiled, cpu time used: 0.000 seconds]
% 0.0 CPU in  0.003 seconds (0% CPU)
++Error[XSB/Runtime/P]: [Existence (No predicate c_numlists : sum_list / 2 exists)] []
...

The Logtalk version is faster than SWI-Prolog:

| ?- time(boostrlr::b_rlr(father(_,_),WC)).
% 12.201 CPU in  12.412 seconds (98% CPU)
...

Anyway, see the warning in the https://logtalk3.readthedocs.io/en/latest/userman/performance.html page regarding benchmarking at the top-level. Not an issue with SWI-Prolog as this system provides the necessary hooks to bypass the issue.

Also, the Logtalk (not LogTalk!) code you sent me requires hacking when switching between SWI-Prolog and XSB. First step is to not use any explicit module-qualification in the code but instead rely on use_module/2 and import/2 directives inside conditional compilation blocks. You'll need to write the import/2 directives in canonical form to avoid syntax errors when running the code with SWI-Prolog, however. For example, instead of writing:

:- import aggregate_all/3 from c_aggregate.

use instead:

:- import(from(/(aggregate_all,3),c_aggregate)).

[weitkaemper]

Thank you very much for the analysis, and my apologies for the delayed reply. I cannot currently reproduce the plain XSB error, but your reported performance seems more reasonable than mine. Is there a canonical way to measure performance while bypassing the top-level issues? Would wrapping the testing command in a static tester object be sufficient?

[pmoura]

I'm using the current XSB git version. Maybe some bug introduced after the 5.0.0 released. I already reported it to Theresa and David.

Indeed, wrapping the benchmark query in a static object compiled optimized would bypass top-level interpreter overheads. But if the query requires a non-trivial number of computations, the overheads should be small. As I mention above when discussing circular references, changing the files loader order may help (notably, kb before scorer).

[pmoura]

Btw, why:

compute_gradients(Head,WeightedClauses,Gradients) :-
    findall(Gradient,(
                term::varnumbers((Head,WeightedClauses),(ReHead,ReWeightedClauses)),
                compute_gradients_aux(ReHead,ReWeightedClauses,Gradient)),
            Gradients).

instead of:

compute_gradients(Head,WeightedClauses,Gradients) :-
    term::varnumbers((Head,WeightedClauses),(ReHead,ReWeightedClauses)),
    findall(Gradient, compute_gradients_aux(ReHead,ReWeightedClauses,Gradient)), Gradients).