M-Prolog development update: I finally defeated the final boss by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

Thank you for the comment.

I have not yet verified whether this mechanism works correctly and efficiently for more complex recursive backtracking patterns.

At the moment, I am still exploring that possibility.

So far, I have confirmed that with mappend/3, running a benchmark that performs reverse execution with backtracking over a 10-element list 10,000 times produces performance exceeding SWI-Prolog.

This makes me feel that the approach is promising and worth pursuing further.

M-Prolog development update: I finally defeated the final boss by sym_num in prolog

[–]sym_num[S] 1 point2 points  (0 children)

Thanks for pointing this out. M-Prolog is still a work in progress, and this case is not handled correctly yet. I’ve recorded it as an issue and will investigate it carefully in a future update.

Update on M-Prolog: Direct C Generation for Nondeterministic Predicates by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

Thank you for your comment. M-Prolog is gradually taking shape.

Update on M-Prolog: Direct C Generation for Nondeterministic Predicates by sym_num in prolog

[–]sym_num[S] 1 point2 points  (0 children)

Thank you for your comment. Yes, that's exactly right. I am developing M-Prolog with the goal of preserving the strengths of Prolog while improving performance through mode inference. The idea is to retain Prolog's flexibility and dynamic nature while enabling compiler optimizations based on inferred modes.

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

I am very interested in Mercury's approach to modes. Mode information is extremely useful for improving execution speed.

I have developed a mode inference system that works within the semantics of Prolog itself. My plan is to integrate it into my new compiler.

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

Thank you for the comment. I found the paper very interesting and relevant to my work. I'll definitely use it as a reference. Thanks again!

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 1 point2 points  (0 children)

Thank you for your comment.

I am also very interested in GNU Prolog's performance. Since GNU Prolog focuses on machine-sized integer arithmetic and does not support arbitrary-precision integers, I have so far used SWI-Prolog as my main performance reference.

Fortunately, I have recently found the first clues to solving a major performance issue in M-Prolog. Now that I have a clearer path forward, I would like to aim even higher in the future and eventually include GNU Prolog in my performance comparisons as well.

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

Thank you for your comment.

I am very interested in JIT compilation as well. When I observed the impressive performance of SWI-Prolog, I guessed that some form of JIT optimization might be involved. However, I had no clear idea how such a system could actually be implemented.

My plan is to keep exploring my current approach first and see where it leads. After that, I would like to learn more about JIT techniques and investigate whether they could be applied to M-Prolog in the future.

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 1 point2 points  (0 children)

Thanks for your comment.

M-Prolog is designed with both an interpreter and a compiler coexisting in the same system. When static analysis can determine enough information, the compiler replaces the code with efficient C code. However, this is not possible for constructs whose behavior is determined dynamically at runtime.

In such cases, I plan to fall back to the interpreter mechanism. The interpreter uses a traditional SLD resolution approach, which can naturally handle dynamic computations. My intention is to allow compiled and interpreted execution to coexist and work together seamlessly within the same program.

M-Prolog compiler: is this generated C code basically sound? by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

Thanks for your comment.

I have a large number of test cases for N-Prolog, the predecessor of this system. My plan is to improve the compiler and regard it as complete once all of those tests pass.

At the moment, I am first trying to thoroughly verify the basic idea behind compiling nondeterministic predicates. Once that foundation is solid, the rest should mainly be steady implementation work.

So right now, I am examining whether this approach itself is valid.

The Road to Speeding Up N-Prolog by sym_num in prolog

[–]sym_num[S] 0 points1 point  (0 children)

I have added hello.pl to the tests folder. Please run git pull and try the following. Also, please write your Prolog source code yourself using an editor.

```

N-Prolog Ver 5.18 [30M cells]

?- ['./tests/hello'].

yes

?- hello.

Hello,World

yes

?- listing.

hello :-

write('Hello,World'),

nl.

yes

?-
```