There is huge impact if we write edge(X,Y) before reach. But when I try this in swi-prolog(there is no cputime/1, so I cannot table it), there is no significant different between different ways of implementation.
I found somewhing interesting when I tried to use swi-prolog to program this question. The following code works in swi-prolog(not xsb):
```prolog
attacks((Row1, Col1), (Row2, Col2)) :-
Row1 =:= Row2;
Col1 =:= Col2;
abs(Row1 - Row2) =:= abs(Col1 - Col2).
no_attacks(_, []).
no_attacks(Queen, [OtherQueen|OtherQueens]) :-
\+ attacks(Queen, OtherQueen),
no_attacks(Queen, OtherQueens).
queen_positions(0, []).
queen_positions(N, [(N, Col)|Queens]) :-
N > 0,
N1 is N - 1,
queen_positions(N1, Queens),
member(Col, [1,2,3,4,5,6,7,8]).
legal_queens([]).
legal_queens([Queen|Queens]) :-
legal_queens(Queens),
no_attacks(Queen, Queens).
n_queens(N, Solution) :-
queen_positions(N, Solution),
legal_queens(Solution).
```
but it runs ridiculously slow(takes seconds to compute one solution of 8 queens).Then I tried to play with it and rearrange it a little bit and the answer I got (in A/queens.P) now runs much faster in swi-prolog and runs succesfully in XSB.
Though it looks like the Way4 is way better tha Way 1(Almost twice as fast), but if we let the computer to rest for a while and rerun them the other way(start from 4, then 3, follow by 2 and 1), we got
(42 MByte), so it waste a lot of time to load it to memory then cache, and the following ones has much higher cache hits rate, so the first one takes way longer than the others.
The runtime grows linearly respect to the input size, and there is no significant difference between different implementations.
