home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / prolog / 1429 < prev    next >
Encoding:
Text File  |  1992-07-21  |  3.0 KB  |  58 lines
  1. Newsgroups: comp.lang.prolog
  2. Path: sparky!uunet!email!mips.complang.tuwien.ac.at!andi
  3. From: andi@mips.complang.tuwien.ac.at (Andi Krall)
  4. Subject: Re: Term comparisons w/ variables
  5. Message-ID: <1992Jul21.122720.10071@email.tuwien.ac.at>
  6. Keywords: unsafe variables
  7. Sender: news@email.tuwien.ac.at
  8. Nntp-Posting-Host: mips.complang.tuwien.ac.at
  9. Organization: Technical University Vienna
  10. References:  <1992Jul17.152828.3861@cs.kuleuven.ac.be> <1992Jul20.180957.26834@quintus.com>
  11. Date: Tue, 21 Jul 1992 12:27:20 GMT
  12. Lines: 44
  13.  
  14. Tim Lindholm writes
  15.  
  16. >Bart Demoen writes:
  17.  
  18. >> The implementation of ProLog by BIM has no "unsafe" variables (this wasn't true
  19. >> in 1984, otherwise there wouldn't have been the need to invent the trick). It
  20. >> was the idea of Herman Crauwels (no longer at BIM) to get rid of them. Some
  21. >> people claim that not having "unsafe" variables, is a bad idea. Anybody
  22. >> interested in discussing this in this news group ?
  23.  
  24. >Quintus has (and likes) unsafe variables.  Years ago as a study for release
  25. >3.0 I modified a QP system to get rid of unsafe variables (by immediately
  26. >globalizing them -- I hope that's what we are talking about!).  The system
  27. >also recorded stack "high water marks", the maximum size of the stacks for
  28. >a given run.  We expected to see additional global stack required, and were interested in >getting some estimates of how much more would be used.
  29.  
  30. >We were quite surprised that on a range of examples (compiling code, running
  31. >our test suite, running CHAT-80 and various other tests) that global stack 
  32. >usage increased substantially, by 50-100% across the majority of examples we tested.  This >increase also caused runtime penalties due to increased stack shifting and GC.
  33.  
  34. >This seemed so unacceptable that we didn't even bother to tune the system to
  35. >measure what performance increase we might expect.  Bart, do you have any estimate of the >performance BIM gained (and Quintus gave up) by abandoning
  36. >unsafe variables?
  37.  
  38. Since about three years the VAM (Vienna Abstract Machine) stores unbound variables
  39. on the global Stack. In the optimized version the stack size grow by about 15%
  40. (4.44% to 26.40% depending on the benchmark (small benchmarks, prolog compiler,
  41. meta interpreter, theorem prover)). The optimized version eliminates the creation
  42. of unbound variables for builtin predicates like for the result of is. If the bips
  43. creates unbound variables too the stack size grows by additional 36% (1.37 to 94%).
  44.  
  45. Storing unbound variables on the global stack was a great win for the VAM. The
  46. optional trail test was simplified (only one comparison). The last call optimization
  47. speeded up due to the elimination of checking the stack frame for unbound variables
  48. and self references. The number of unbound variables is smaller in the VAM than in
  49. the WAM (Warren Abstract Machine). So the grow of stack sizes can not compared
  50. directly.
  51.  
  52. -- Andi
  53. -- 
  54. Andreas Krall, andi@mips.complang.tuwien.ac.at
  55. +431 58801/4477  fax +431 5057838
  56. Technische Univ. Wien, Inst.f. Computersprachen E185/1
  57. Argentinierstr.8/4, A-1040 Wien Austria
  58.