Re: multisets

On 2008-02-28, Bart Demoen <bmd@xxxxxxxxxxxxxxxxx> wrote:
Jan Wielemaker wrote:

Anyone with a rough model of Prolog execution will assume that the
findall/between version is slower. Ok, on one particular system it is
the other way around, but by so little it doesn't matter much which
option you choose.

Eh, no.
As a user I expect the numlist version to be faster by a factor 4 to 15
(according to my measurements on other systems, that is reasonable).
So if in a particular system, the numlist version is as slow as the findall
version, the difference between what I expected to get and what I actually get
is huge, not little - and so it does matter.

Well, that depends. If you *need* the list of integers, there are
these two choices (in a lot of variations of course). So you take
numlist/3 and you are happy on (I hope) all systems. If you have the
choice to solve your problem without generating the list of integers,
things may become different. Still, the
non-findall/assert/whatever-database-operation version is generally
faster on most Prolog systems, given equal complexity of the
algorithm.

Of course it is annoying that the execution time of your algorithm is
hard to estimate on a particular Prolog platform and thus a
`non-portable' aspect of the program.

This is not new and not unique to Prolog. SWI-Prolog uses two
radically different implementations for message queues between threads
(Windows/Unix), because after simple porting of the Unix implemention
using pthread-win32 the Windows version was 100 times slower. This
was caused by pthread-win32 sticking too close to the POSIX semantics
for condition variables. A weaker conforming implementation that
still satisfied Prolog's needs could be implemented, getting
comparable performance.

I have encountered many similar issues in the operating system
interfaces. Annoying, but a fact of life. The good news it that as
long as there is a healthy competition some of these issues are
resolved.

Cheers --- Jan
.

Relevant Pages

  • Re: multisets
    ... Jan Wielemaker wrote: ... findall/between version is slower. ... So if in a particular system, the numlist version is as slow as the findall ... not little - and so it does matter. ...
    (comp.lang.prolog)
  • Re: OBarrs comments on SR and LET.
    ... and independent absolute time? ... matter) in the direction of travel, and do all clocks physically run slower ... when we consider them moving relative to the absolute ether frame? ...
    (sci.physics.relativity)
  • Re: IF NOTs
    ... I did a quick test on gForth 0.6.2 on a PC and found the true case was ... slower in roughly the ratio 8:5. ... With completely empty branches, the do loop took a bit more than half ... the timing between true and false cases to matter much. ...
    (comp.lang.forth)
  • I have already justified the Einsteins specific relativity
    ... In the theory of specific relativity, we face the matter that if we ... III - The time will go by slower for it. ... II- It's mass decreases. ...
    (sci.physics.relativity)
  • I have already justified the Einsteins specific relativity
    ... In the theory of specific relativity, we face the matter that if we ... III - The time will go by slower for it. ... II- It's mass decreases. ...
    (sci.physics)