home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10505 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.0 KB  |  66 lines

  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsk!cbnewsj!davet
  3. From: davet@cbnewsj.cb.att.com (Dave Tutelman)
  4. Subject: Re: COMPILING SPEED
  5. Organization: AT&T Bell Labs - Lincroft, NJ
  6. Date: Wed, 11 Nov 1992 12:55:14 GMT
  7. Message-ID: <1992Nov11.125514.1465@cbnewsj.cb.att.com>
  8. Summary: Pascal was slow, but C was slower
  9. References: <1dj8miINN6sl@matt.ksu.ksu.edu> <1992Nov10.160940.5958@exu.ericsson.se>
  10. Lines: 54
  11.  
  12. In article <1992Nov10.160940.5958@exu.ericsson.se> exuhag@exu.ericsson.se writes:
  13. >Dan Odom writes:
  14. >>Yes, it is.  Go write a compiler for Pascal.  Then write a compiler for
  15. >>C++.  You'll see.
  16. >
  17. >But until Turbo came along, MS-DOS Pascal compilers were total
  18. >dogs.
  19.  
  20. Well, sort of.  The competitors to Turbo in 1983 were compiled Pascals by
  21. Microsoft and IBM (the same product, I thought), and an interpreted Pascal
  22. by (if memory serves) P-systems.  The ads in Byte for Turbo (I still have a
  23. copy somewhere) stressed that it:
  24.  - Compiled much faster than IBM/Microsoft.
  25.  - Ran much faster than P-systems.
  26.  - Ran in less RAM / disk than either.
  27.  - Was MUCH cheaper than either.
  28.  
  29. One of those "too good to be true" ads, but I figured for $49 I could take a
  30. chance, and it WAS true.  (Still have Turbo Pascal 1.0 floppy, Ser #1027.)
  31. Besides, I was talked into it by their EXCELLENT, free tech support.
  32. (Apropos another discussion in this newsgroup.)
  33.  
  34. ON THE OTHER SIDE OF THE FENCE ......
  35. Did you ever try a C compiler of the same era?  MUCH SLOWER than even IBM
  36. Pascal in compiling. Much worse.
  37. The biggest speed problem with IBM Pascal was not just compute speed,
  38. but juggling the 3-4 floppies you needed for
  39. a floppy-only machine -- which was most PCs back then.  Most of Turbo's
  40. speed advantage came from doing the whole job in RAM.
  41.  
  42. The C compilers of the day also required floppy-juggling.  But you COULD
  43. take a coffee break between handling floppies.
  44.  
  45. >What's troubling here is that people are blindly accepting
  46. >the "fact" that C++ compilers _have_ to be slow.
  47.  
  48. Borland C++ runs REAL fast on my home machine; I have no complaints at all
  49. about speed.  But that's because they haven't forgotten their roots. They
  50. use as much extended memory as they can eat, and I've found that compile
  51. speed is very sensitive to RAM (both extended and lower) available to
  52. BC++.  They're STILL doing it by keeping as much as possible in core.
  53. Evidence:
  54.  - A home machine memory upgrade gave a manifold increase in compile speed.
  55.    I went from 1Meg to 4Meg, giving almost a 10X speed gain.
  56.  - My office machine, with even more extended memory but with less available
  57.    space in the lower 640K, compiles fast enough for a while (about 1200
  58.    lines at a clip), but then stops and waits for a while... an annoying
  59.    while.  On a few occasions, such hiccups end with an "out of memory"
  60.    fatal error.  I'll unload a TSR or two, and recompile successfully,
  61.    and much faster.
  62.  
  63. Dave
  64. ---
  65. Not associated with Borland, but a usually-satisfied customer.
  66.