home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3128 < prev    next >
Encoding:
Text File  |  1992-09-14  |  3.0 KB  |  68 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!cunews!csi.uottawa.ca!news
  3. From: cbbrowne@csi.uottawa.ca (Christopher Browne)
  4. Subject: Re: Sampler Forth
  5. Message-ID: <1992Sep15.040007.4183@csi.uottawa.ca>
  6. Sender: news@csi.uottawa.ca
  7. Nntp-Posting-Host: prgv
  8. Organization: Dept. of Computer Science, University of Ottawa
  9. References: <15034@mindlink.bc.ca> <int452w.716514917@lindblat.cc.monash.edu.au>
  10. Date: Tue, 15 Sep 92 04:00:07 GMT
  11. Lines: 55
  12.  
  13. In article <int452w.716514917@lindblat.cc.monash.edu.au> int452w@lindblat.cc.monash.edu.au (Michael R. Geddes) writes:
  14. >Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
  15. >
  16. >>> (a) Forth is NEVER  going to be the fastest executing language.
  17. >
  18. >>That's not necessarily true.  If Forth had the support C has, it
  19. >>would also have nice systems with Forth CPUs, and I think for equal
  20. >>investment in hardware and programming time, the application in Forth
  21. >>would run a lot faster. 
  22. >
  23. >I agree with this, but also, I have been told that better hardware can
  24. >often give you a reasonable increase in speed, but better algorithms
  25. >give you an order of magnitude increase in speed.  Forth is 'slow' on
  26. >most systems because of the forth 'engine' that goes between machine
  27. >code and forth code..  Forth is 'fast' because you can code all the
  28. >critical bits with an efficient algorithm (not just by putting it into
  29. >assembler, you don't always get small critical bits.).
  30.  
  31. The problem is that everybody takes a look at Forth and says "I can do
  32. THIS to the interpreter/threading mechanism/whatever" and uses it to
  33. essentially "redesign" the underlying data structures.
  34.  
  35. They wind up putting the proverbial cart before the horse - they
  36. optimize before they know what the bottlenecks might be.  And they're
  37. having so much fun optimizing that they tend to forget about actually
  38. putting something new and original in terms of FUNCTIONALITY into it.
  39.  
  40. I'm currently working on a moderately large thesis project, using a
  41. combination of linear regression code (being misused :-)) to optimize
  42. linear programs, and a specialized "network simplex" solver.
  43.  
  44. I could have great fun trying to optimize the Network Simplex code;
  45. (I've had great fun translating it from FORTRAN to C - NOT!)
  46. unfortunately, this optimization would be of very little value, since
  47. the bottleneck is in fact the regression code.  For problems of
  48. trivial size, the time spent doing Simplex stuff is maybe 25%; as the
  49. problems grow larger, it looks like it becomes insignificant.
  50.  
  51. Forth SHOULD allow programmers to optimize the IMPORTANT parts
  52. ("bottlenecks").  Unfortunately, it makes optimizations so
  53. easy/obvious that I've always found it hard to actually get code to
  54. WORK.
  55.  
  56. I'm not sure that Forth NEEDS to be the fastest executing language;
  57. people have been able to live with the problems of Lisp garbage
  58. collection, and still swear by Lisp.
  59.  
  60. Forth DOES need to make it possible to go fast; the typical built-in
  61. assembler allows this quite eminently.
  62.  
  63. -- 
  64. Christopher Browne
  65. cbbrowne@csi.uottawa.ca
  66. University of Ottawa
  67. Master of System Science Program
  68.