home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / scheme / 2748 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  1.6 KB

  1. Path: sparky!uunet!mitech!gjc
  2. From: gjc@mitech.com (George J. Carrette)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: Are interpreters now as fast as compiled code used to be?
  5. Message-ID: <4065@mitech.com>
  6. Date: 15 Dec 92 10:26:28 GMT
  7. References: <4051@mitech.com> <FEELEY.92Dec14215701@zohar.ai.mit.edu>
  8. Organization: Mitech Corporation, Concord MA
  9. Lines: 25
  10.  
  11. In article <FEELEY.92Dec14215701@zohar.ai.mit.edu>, feeley@zurich.ai.mit.edu (Marc Feeley) writes:
  12. > By the way, does SIOD implement the whole numeric tower?
  13.  
  14. No. But if it did it would be even faster(*) All computations in SIOD
  15. are done using the C double type.
  16.  
  17. Especially on newer RISC computers you will find that the time taken
  18. for dispatch (and the non-locality of dispatch) can easily be a lot
  19. more than the time to compute a 64-bit floating point result.
  20.  
  21. You really have to be careful about the ordering of the switch statements
  22. and the placement of the "goto's." Taking into account the predictive
  23. branching hardware in some processors. Truly ugly stuff.
  24.  
  25. -gjc
  26.  
  27. (*) I know this to be true because I have another Scheme interpreter used
  28. in some commercial products that has generic arithmetic and it runs 
  29. standard-fib faster than SIOD. But unfortunately some of the implementation
  30. techniques look a bit ugly (funky macro preprocessing of C-like source
  31. files written in Scheme, just for arithmetic dispatch compilation),
  32. so it is not as nice to release for public consumption as SIOD. 
  33. If C had a decent built-in macro facility, well. No, I take that back,
  34. even in LISP this kind of macro compilation of arithmetic dispatch
  35. looks pretty ugly and special-purpose. 
  36.