home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1373 < prev    next >
Encoding:
Text File  |  1992-08-15  |  4.1 KB  |  93 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!gumby!yale!mintaka.lcs.mit.edu!spdcc!iecc!compilers-sender
  3. From: macrakis@osf.org (Stavros Macrakis)
  4. Subject: Re: Why is compiled basic slower than C? (Basic is the future)
  5. Reply-To: macrakis@osf.org (Stavros Macrakis)
  6. Organization: OSF Research Institute
  7. Date: Fri, 14 Aug 1992 16:57:10 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-08-072@comp.compilers>
  10. References: <92-08-042@comp.compilers> <92-08-064@comp.compilers>
  11. Keywords: Basic, interpreter, performance
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 78
  14.  
  15. scott@bbx.basis.com (Scott Amspoker) writes:
  16.  
  17.    We market a business-oriented BASIC-style language called BBx.  It is
  18.    interpreted.  Although it is quite different from Microsoft BASIC there
  19.    are still common qualities of any BASIC dialect.
  20.  
  21.    A few years ago there was some discussion about producing a compiler for
  22.    it.  We found several reasons why a compiler would not be a great idea.
  23.    The main reason is that the runtime dynamics of BASIC don't translate well
  24.    to a compiled environment.  The most important aspects are dynamic
  25.    string/array management and dynamic flow control involving error/exception
  26.    handling.  The latter is especially hard to optimize.
  27.  
  28. Dynamic strings and arrays are supported in many programming languages
  29. besides Basic.  Many of these languages have compilers (in fact, many have
  30. only compilers and not interpreters).
  31.  
  32. Reasonable error and exception handling are also supported by many
  33. languages.
  34.  
  35.    A C programmer tends to approach these things with a more "static" frame
  36.    of mind resorting to a dynamic model only if it is really necessary (and
  37.    knowing there will be a performance hit).  Furthermore, BASIC normally
  38.    performs lots of runtime checks such as array subscripts and ranges.
  39.  
  40. Yes, so do other languages with compilers.  A compiled range check is much
  41. more efficient than an interpreted one, especially when analysis shows (as
  42. is often the case) that no check needs to be performed at all.
  43.  
  44.    Granted, a BASIC compiler could allow the option of turning these checks
  45.    off but I'm assuming a proper semantical translation.
  46.  
  47. Proper semantic translation does not preclude correct optimizations.
  48. Consider the following loop:
  49.  
  50.     FOR I = 1 TO N
  51.       A(I) = A(I)*3
  52.     NEXT I
  53.  
  54. Array bounds checking need only be performed once (to assure that 1..N
  55. fall within A's subscript bounds).
  56.  
  57.    Since our product is used primarily for business data processing
  58.    applications which spend most of their time performing file and user i/o,
  59.    the need for a compiler isn't as critical.  Indeed we have been known to
  60.    beat some compiled languages in file-oriented benchmarks.
  61.  
  62. This is a quite different argument.  This shows why you believe you do not
  63. need a compiler, but it does not show that Basic cannot be compiled.
  64.  
  65.    I just don't think interpreted languages compile well.
  66.  
  67. ?!  There is no such thing as an `interpreted language'.  There are
  68. interpretive implementations.  True, some languages lend themselves more
  69. to easy interpretation, and others to easy compilation, but that's an
  70. implementor's problem.  Anyway, Basic's first implementation (at
  71. Dartmouth) was compiled....  You might consider Lisp to be an `interpreted
  72. language'.  Compilers typically speed up Lisp programs by an order of
  73. magnitude or so over interpretive execution, often more for numerical
  74. code.  The resulting code may or may not be faster than compiled C or
  75. Fortran code, but it is certainly faster than interpreted Lisp code.
  76.  
  77.    If they do then they really aren't exploiting the special strengths
  78.    of interpretation.
  79.  
  80. The special strengths of interpretation have mostly to do with debugging
  81. and quick turn-around of code corrections.
  82.  
  83.   You end up with the worst of both worlds.  --
  84.  
  85. Nonsense.  There are also many environments (e.g. most Lisp environments)
  86. which permit mixing interpreted and compiled code.  This gives you in many
  87. ways the best of both worlds.
  88.  
  89.     -s
  90. -- 
  91. Send compilers articles to compilers@iecc.cambridge.ma.us or
  92. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  93.