home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8908 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.0 KB
  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!ai-lab!zurich.ai.mit.edu!jinx
  2. From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
  3. Newsgroups: comp.arch
  4. Subject: Re: Threaded Code
  5. Message-ID: <JINX.92Aug14171357@rolex.ai.mit.edu>
  6. Date: 14 Aug 92 21:13:57 GMT
  7. References: <55535@mentor.cc.purdue.edu> <13910@goanna.cs.rmit.oz.au>
  8.     <GLEW.92Aug7185506@pdx007.intel.com>
  9.     <1992Aug10.141731.10007@email.tuwien.ac.at> <martin.713808550@bert>
  10. Sender: news@ai.mit.edu
  11. Reply-To: jinx@zurich.ai.mit.edu
  12. Organization: M.I.T. Artificial Intelligence Lab.
  13. Lines: 51
  14. In-reply-to: martin@math.rwth-aachen.de's message of 14 Aug 92 16:09:10 GMT
  15.  
  16. In article <martin.713808550@bert> martin@math.rwth-aachen.de (  Martin Schoenert) writes:
  17.  
  18. |   Date: 14 Aug 92 16:09:10 GMT
  19. |   From: martin@math.rwth-aachen.de (  Martin Schoenert)
  20. |
  21. |   So I wrote my own tests.  First I defined a virtual (stack) machine with
  22. |   28 instructions (not just 2 as in Anton's tests).  For this virtual
  23. |   machine I wrote a small test program, which computes the number of primes
  24. |   less than 40000 in a very straightforward way.  Then I wrote and tested
  25. |   the following 6 implementations of this virtual machine.
  26. |
  27. |   ...
  28. |
  29. |   If a compiler performed those optimizations the implementations of
  30. |   bytecode and direct threaded interpreters such as 'swi' and 'sub' would
  31. |   be just as efficient as the implementations using gcc's label pointers.
  32. |   Such optimizations might also be worthwile in other situations where
  33. |   label pointers would not help at all.
  34.  
  35. Actually, I'm not convinced.  I don't know what your bytecode is like,
  36. but I can tell you that our interpreter lost a factor of 2 in speed
  37. when recoded in C (and compiled with gcc) from the original 68k
  38. version.
  39.  
  40. One of the major sources of this performance difference was not the
  41. instruction dispatch, which after all, a switch can do moderately
  42. well, and where you are inherently dispatching on a compact type code,
  43. but on two other places where first-class labels would be useful (we
  44. used addresses of instructions in machine language), namely:
  45.  
  46. - "return addresses" into the interpreter.  
  47. Our interpreter is one big loop and manipulates its own stack.  When
  48. "invoking itself recursively", it pushes a "return address" on the
  49. stack.  The 68k version just pushed the address of the return
  50. instruction, as you would expect.  The C version pushes a "return
  51. code" that we dispatch to (with a switch) on return.
  52.  
  53. If you wonder why we don't use C function calls, the answer is pretty
  54. straight-forward:
  55.  
  56. x Function call overhead, as you noticed yourself.
  57. x Implicit state.  Scheme has first-class continuations which imply
  58. that you must be able to capture the stack of pending operations.  The
  59. code for doing this with the C function-call stack would not be
  60. portable.
  61.  
  62. - "primitive procedures" of the language.  Again, a primitive of the
  63. language is naturally represented as the address of its first
  64. instruction in assembly language.  In portable C you would have to use
  65. a table of procedures (with its associated cost) or another switch
  66. statement.
  67.