home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1366 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.9 KB

  1. Path: sparky!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!faatcrl!iecc!compilers-sender
  2. From: scott@bbx.basis.com (Scott Amspoker)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Why is compiled basic slower than C? (Basic is the future)
  5. Keywords: Basic, performance
  6. Message-ID: <92-08-064@comp.compilers>
  7. Date: 13 Aug 92 15:41:07 GMT
  8. References: <92-08-042@comp.compilers> <92-08-049@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: scott@bbx.basis.com (Scott Amspoker)
  11. Organization: BASIS International, Ltd., Albuquerque NM USA
  12. Lines: 46
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. jch@rdg.dec.com (John Haxby) writes:
  16. >Glenn_Johansson@f313.n203.z2.fidonet.cd.chalmers.se writes:
  17. >|> [How much slower is compiled Basic than C, and why?]
  18. >
  19. >There has been a lot of work put into optimizing C compilers: the efforts
  20. >of FSF, Sun and MIPSCO to mention but three.  There hasn't been a great
  21. >deal of work put into optimizing BASIC compilers, at least not that I know
  22. >of.
  23. >
  24. >There seems to be a more general problem though: compilers of high-level
  25. >languages tends to produce optimal machine code, whereas compilers of
  26. >low-level languages tend to produce sub-optimal machine code.
  27.  
  28. We market a business-oriented BASIC-style language called BBx.  It is
  29. interpreted.  Although it is quite different from Microsoft BASIC there
  30. are still common qualities of any BASIC dialect.
  31.  
  32. A few years ago there was some discussion about producing a compiler for
  33. it.  We found several reasons why a compiler would not be a great idea.
  34. The main reason is that the runtime dynamics of BASIC don't translate well
  35. to a compiled environment.  The most important aspects are dynamic
  36. string/array management and dynamic flow control involving error/exception
  37. handling.  The latter is especially hard to optimize.
  38.  
  39. A C programmer tends to approach these things with a more "static" frame
  40. of mind resorting to a dynamic model only if it is really necessary (and
  41. knowing there will be a performance hit).  Furthermore, BASIC normally
  42. performs lots of runtime checks such as array subscripts and ranges.
  43. Granted, a BASIC compiler could allow the option of turning these checks
  44. off but I'm assuming a proper semantical translation.
  45.  
  46. Since our product is used primarily for business data processing
  47. applications which spend most of their time performing file and user i/o,
  48. the need for a compiler isn't as critical.  Indeed we have been known to
  49. beat some compiled languages in file-oriented benchmarks.
  50.  
  51. I just don't think interpreted languages compile well.  If they do then
  52. they really aren't exploiting the special strengths of interpretation.
  53. You end up with the worst of both worlds.
  54. -- 
  55. Scott Amspoker
  56. Basis International, Albuquerque, NM
  57. scott@bbx.basis.com
  58. -- 
  59. Send compilers articles to compilers@iecc.cambridge.ma.us or
  60. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  61.