tnphhbu@dutrun.UUCP (Hans Buurman) (07/21/88)
We currently have Poplog on trial (on a sun 3/50). After having used it for two days, I must say that it seems to be about twice as slow as C-prolog, that I have also worked with on the same machine. Also, debugging seems to have less options. This amazes me, as I saw somewhere on the net that C-prolog isn't really thought of very highly when it comes to speed. Are my conclusions valid, or am I missing something ? Please reply to: dutrun!duttnph!hans@mcvax.nl Hans Any opinions, wrong postings and other errors are my own. I do not represent Delft University or Systems Designers and I don't live in Edinburgh.
cam@aiva.ed.ac.uk (Chris Malcolm) (07/26/88)
Poplog's garbage collection mechanism makes it unusually demanding of memory. I found that my 4,000 line prolog (poplog) program ran about five times faster in an 8Mbyte Sun3/160 as a 4Mbyte Sun3/160. 4Mbytes wasn't even enough to run at full speed as the sole application in a headless fileserver, though it did run faster than in the 3/160 workstation.
sfk@otter.hple.hp.com (Stephen Knight) (07/29/88)
> [Chris Malcolm] > Poplog's garbage collection mechanism makes it unusually demanding of > memory. The garbage collection mechanism in Poplog until recently was a stop and copy garbage collector. In this case, that means that Poplog temporarily doubles its process size (well, asks the operating system for a region the size of the non-constant area of the heap -- which will usually be the greater part of the process size). However, since version 13.5 Poplog can be requested to garbage collect in the existing heap space. This is a slightly slower algorithm in a fast- access VM environment but obviously ideal if paging is done over the network or there is a limited amount of physical memory. You can find out details by mailing johnw@cvaxa.sussex.ac.uk It is also the case that data structures are not stored especially compactly in Poplog Prolog. There are several worthwhile, simple optimisations that may be of value. (You may already know this but just in case ...) A good starting point for finding out what you can do is PLOGHELP SYSTEM. The most relevant points from this are 1. prolog_gcratio( N ) -- determines the dynamic heap size 2. prolog_lock_code. -- extremely valuable. Freezes heap & reduces memory requirements for copying 3. prolog_no_clauses -- stops the text of predicates being recorded (listing, clause, retract, assert will not work) but does save memory & clauses compile quicker. 4. prolog_syspredicates( on ) -- subsequent predicates are compiled as system predicates. There are other pointer to efficiency held in PLOGHELP EFFICIENCY. The most notable points are 5. avoid unwittingly producing rational-numbers by using "/" with an integer denomiator. Use div. 6. compile predicates in one go. Poplog Prolog is helped if a predicate is defined with contiguous clauses (both in space & time). 7. cuts can significantly improve the space performance in Poplog Prolog (as well as the time performance of course). A few well-chosen cuts can make a big difference in this way, too. Finally, if you are relaxed about mixed language programming, you might like to pursue an optimisation approach I have used with great success in Poplog. By structuring the Prolog program with reasonable care it is usually possible to isolate the main bottlenecks (speed OR space) into a few predicates. I then hand-translate these into Pop11 using the continuation-passing interface. The key to using this technique effectively is for the Pop11-procedures to use the original Prolog-predicate as a fallback. In this way, the common cases can be efficiently coded & the less common cases can be handled with the full generality. The advantage of this approach is that it does not affect the portability of the underlying Prolog program nor does it affect the generality of the program. In one example which I did this way the key predicate was improved in performance by a factor of 300 & the overall performance impact across the program was about a factor of 2. (Although I should point out that the enormous factor of 300 could have been greatly reduced by careful optimisation at the prolog level -- probably by as much as a factor of 100.) A large part of this performance impact could be attributed to the greater control over store allocation afforded in Pop11. I hope these comments are of interest. Steve Knight