home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3263 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.7 KB
  1. Xref: sparky comp.object:3263 comp.lang.clos:671
  2. Newsgroups: comp.object,comp.lang.clos
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!fstop.csc.ti.com!fstop.csc.ti.com!djohnson
  4. From: djohnson@mtc.ti.com (Doug Johnson)
  5. Subject: Re: Beginner's Question - CLOS
  6. In-Reply-To: eric@tfs.com's message of Wed, 19 Aug 1992 21:38:18 GMT
  7. Message-ID: <DJOHNSON.92Aug19183847@mycroft.mtc.ti.com>
  8. Sender: usenet@csc.ti.com
  9. Nntp-Posting-Host: mycroft
  10. Reply-To: johnson@mycroft.mtc.ti.com (Doug Johnson)
  11. Organization: Texas Instruments
  12. References: <KERS.92Aug19111407@cdollin.hpl.hp.com> <graham.714230337@galois>
  13.     <16u2tpINN9ad@early-bird.think.com> <1992Aug19.213818.21709@tfs.com>
  14. Date: Thu, 20 Aug 1992 00:38:47 GMT
  15. Lines: 41
  16.  
  17.  
  18.  
  19.  >But doesn't that make method dispatch very time consuming?  It seems like
  20.  >it would involve searching for the method in tables, and that the amount
  21.  >of time consumed would depend on how many methods were in those tables and
  22.  >how many class arguments each method had.
  23.  
  24. Naive implementations are slow, sophisticated ones can be quite fast
  25. (by Lisp standards).  Techniques like caching methods are used to
  26. speed up dispatch.
  27.  
  28.  >In C++, method dispatch is trivial to the CPU, such that on most modern
  29.  >CPU's it would take a fraction of a microsecond.  I can see the advantages
  30.  >of dispatching according to the types of multiple arguments, but I'm just
  31.  >wondering how much of a speed impact it has.  In C++ the same functionality
  32.  >requires more code, but it seems like it would still be faster. 
  33.  
  34. Lisp has always tended to buy richness of expression with speed.  "In
  35. C++ the same functionality requires more code, but it seems like it
  36. would still be faster" implies that programmer time is cheaper than
  37. CPU time.  It varies from case to case, but it is often a poor
  38. trade to increase code to increase speed.
  39.  
  40.  >For
  41.  >example, a terminal object's display function would take a base class of data
  42.  >as its argument, and then it would get the data converted to its requirement
  43.  >by invoking a conversion method on the data object.  That conversion method
  44.  >would be known to the terminal object at compile time, so the resulting code
  45.  >would involve no lookups other than the initial sub-microsecond dispatch to
  46.  >the terminal object's display function, followed by the sub-microsecond
  47.  >dispatch to the data objects's conversion function for that terminal object's
  48.  >data format.
  49.  
  50. In general, EVERYTHING in Lisp is deferred to runtime.  Richer
  51. expression at the cost of performance.  CLOS is entirely consistent
  52. with Lisp philosophy.  C++ is entirely consistent with C.   Both have
  53. their virtues.  Neither solves all the world's problems, no matter
  54. what the bigots say.  
  55.  
  56. Doug Johnson
  57. Lisp Bigot (retired)
  58.