^ ^                 ^ ^
=(o.o)=  ~byakuren  =(o.o)=
  m m                 m m

Flowlog

Flowlog (v4.6.4) is an ISO-style Prolog system implemented as a single, portable C file (flowlog.c), with a focus on running unmodified Prolog search faster on multicore CPUs.

It provides:

• A small, self-contained Prolog runtime (no external libraries required beyond libc + pthreads)
• Multiple execution engines (wamvm, wam, interp/tree)
• Optional OR-parallelism (parallel exploration of choicepoints) and conservative AND-parallelism (parallel execution of independent subgoals when safe)
• A practical REPL with history and line editing
• An ISO conformance workflow (INRIA suite + regression tests)

Why it exists

Prolog is a great fit for search problems, constraint-style programming, and symbolic manipulation, but classic implementations tend to exploit only limited parallelism automatically. Flowlog’s goal is to keep Prolog’s familiar ISO semantics while also making it easy to:

• Use all available CPU cores during nondeterministic search
• Trade strict, classic “left-to-right” solution ordering for throughput when desired
• Keep a simple “one C file” implementation that is easy to build and embed

Quick start

download all files:

flowlog.tar.gz

Build:

cd flowlog
make

Or compile directly:

cd flowlog
cc -O2 -Wall -Wextra -pthread flowlog.c -lm -o flowlog

Run the REPL:

./flowlog

Load a file and run a goal:

./flowlog program.pl -g 'main.'

Control the number of worker threads:

./flowlog --threads 12 program.pl -g 'goal(X).'

Engines (and defaults)

Flowlog ships three execution engines:

• wamvm — bytecode WAM VM (default). Designed to be fast and parallel-friendly; may fall back to wam/interp if a feature is not supported in VM-only mode.
• wam — a “WAM-lite” direct solver (still a Prolog engine, but not a classic WAM bytecode VM).
• interp / tree — a full tree-walking interpreter (useful as the most conservative reference behavior).

Select an engine:

./flowlog --engine wamvm   program.pl -g 'goal.'
./flowlog --engine wam     program.pl -g 'goal.'
./flowlog --engine interp  program.pl -g 'goal.'

Parallelism

Flowlog’s parallel features are opt-in/controllable so you can choose between classic behavior and maximum throughput:

• OR-parallelism: splits choicepoints across workers (best for large search spaces)
• AND-parallelism: runs proven-safe independent subgoals in parallel (conservative by design)

The main user-facing switch is the parallel profile:

• fast — prefer throughput; may return solutions in a different order than classic Prolog
• iso — prioritize classic ordering/behavior where possible
• off — disable Flowlog parallelism features

./flowlog --parallel-profile fast program.pl -g 'goal.'
./flowlog --parallel-profile iso  program.pl -g 'goal.'
./flowlog --parallel-profile off  program.pl -g 'goal.'

Flowlog also supports the same controls as Prolog flags (so an ISO Prolog program can enable them explicitly when running under Flowlog):

:- set_prolog_flag(flowlog_parallel_profile, fast).

ISO conformance

Flowlog targets ISO/IEC 13211-1 behavior for the core language and built-in predicates. The recommended way to check conformance in this repo:

cd flowlog
make test
make test-inria

To lock in that the INRIA suite runs entirely in the wamvm VM (no fallback):

make test-inria-wamvm-vmonly

Documentation

Start here:

• README.md — high-level overview
• QUICKSTART.md — build + first run
• USER_GUIDE.md — using Flowlog as a Prolog system (REPL, loading, running)
• CLI.md — CLI flags and environment variables

Core references:

• PREDICATES.md — built-in predicates and evaluable functors
• ISO_CHECKLIST.md — checklist of ISO predicate coverage
• CONFORMANCE.md — conformance strategy + test suites

Parallel/runtime internals:

• PARALLELISM.md — OR/AND parallelism model, profiles, tradeoffs
• IMPLEMENTATION.md — overall architecture (parser → program → engine → runtime)
• TECHNICAL_DETAILS.md — data structures, memory model, low-level notes
• WAM_ROADMAP.md — notes/roadmap for engine coverage and performance work

Contributing:

• DEVELOPMENT.md — development workflow and conventions
• TROUBLESHOOTING.md — common build/runtime issues

Benchmarks and tests:

• BENCHMARKS.md — benchmark harnesses and reference programs (includes full source)
• TESTS.md — regression tests and ISO suite runners (includes full source)

Performance comparison

These tables are derived from the raw timing logs in this repo: magic_square_timings.txt and nqueens_timings.txt. Times are wall-clock real seconds (lower is better), sorted fastest → slowest.

Magic square timings (magic_square(4, _)):

N-queens timings (nqueens(13, _)):

A short history of parallel Prolog (and what’s different here)

Parallel execution in Prolog has a long research lineage:

• OR-parallelism (splitting different clause alternatives/choicepoints across workers) appeared in systems like Muse and Aurora.
• AND-parallelism (running independent subgoals in parallel) was explored in systems like &-Prolog and related work on dependency analysis.
• Practical systems often combine these ideas with other features (tabling, indexing, compilation, constraints) but typically require either explicit parallel constructs or careful programming patterns to get consistent wins.

Flowlog’s approach is:

• Keep the surface language close to ISO Prolog.
• Provide a fast-by-default runtime profile for search workloads (unordered when permitted).
• Make parallelism a runtime policy (flags/profiles), not a separate language.
• Keep the whole system small, hackable, and easy to build as a single C source file.

If you’re new: start with QUICKSTART.md, then skim USER_GUIDE.md and PARALLELISM.md.

Version history

Flowlog has gone through a few distinct implementation phases. This is a high-level timeline of the ideas that shaped the current system:

• v0 — BMDFM-based prototype: The original Flowlog experiments were built on top of the BMDFM runtime, using its flow/parallel model to explore how Prolog search could map onto a graph-like execution substrate (especially OR-parallel search and “run independent work at once” ideas).
• v1 — tree-walking engine (pure C + pthreads): A standalone implementation that removed BMDFM constraints and made it easier to reason about performance, memory layout, and scheduling. This phase focused on correctness (ISO-style behavior), a practical REPL, and making OR-parallelism a first-class runtime policy.
• v2 — WAM-lite engine: Introduced a faster execution core than the interpreter, keeping the same surface language while improving clause selection, unification, and backtracking hot paths. This was the first “compiled-ish” step toward closing the performance gap with established Prolog systems while preserving Flowlog’s parallel hooks.
• v4 — WAMVM engine: Added a bytecode-based WAM VM (wamvm) as the default engine, aiming for higher instruction-cache locality and tighter inner loops while still supporting Flowlog’s OR/AND parallel policies. VM-only conformance runs (no fallback) make it easier to track and close remaining feature gaps.