home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / smalltal / 2830 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.1 KB  |  77 lines
  1. Newsgroups: comp.lang.smalltalk
  2. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!news.uta.edu!utafll!bruce
  3. From: bruce@utafll.uta.edu (Bruce Samuelson)
  4. Subject: for Claus Gittinger
  5. Message-ID: <1993Jan26.191446.16764@utagraph.uta.edu>
  6. Sender: news@utagraph.uta.edu (USENET News System)
  7. Nntp-Posting-Host: utafll.uta.edu
  8. Organization: University of Texas at Arlington
  9. Date: Tue, 26 Jan 1993 19:14:46 GMT
  10. Lines: 65
  11.  
  12. Claus, here is email I tried to send you but my mailer returned with
  13. host unknown.
  14.  
  15. Date: Tue, 26 Jan 93 13:00:18 CST
  16. From: bruce (Bruce Samuelson)
  17. To: gitting@slsvftt.us-es.sel.de
  18. Subject: your comments on slopstones and smopstones
  19.  
  20. Thanks for your comments, which are all valid. I have received similar
  21. comments privately and publicly, and I agree that Slopstones in particular has
  22. shortcomings. I tried developing several earlier versions prior to the one I
  23. published. All the earlier ones were either flawed worse, or made ST/V-DOS
  24. crash when I ran them.
  25.  
  26. Slopstones is intended to measure strictly low level operations and will not
  27. necessarily reflect performance in an actual application. I wanted to measure
  28. seven common operations and get the fastest time I could for each. I agree
  29. that a compiler could theoretically compile away some of them, and in fact, if
  30. you had seen a posting a couple weeks ago by Urs Hoelzle, Self did in fact do
  31. just that. You are correct, though, that theoretically they cannot be
  32. optimized away, because one could always redefine integer addition, for
  33. example, to not only add two integers, but to do something else such as keep
  34. track of how many times integer addition has been invoked.
  35.  
  36. Fractonaccis: yes, fractions in themselves are not that interesting, but the
  37. machinery needed to add/subtract them does invoke quite a lot of integer
  38. arithmetic, which *is* interesting. However, I did not choose fractions
  39. because they were interesting, but because fibonaccis do not produce usable
  40. runs.  Either the numbers grow larger than 16-bit integer limits on ST/V-DOS
  41. (16363) or the run time is too small to be reliably measured. Regarding
  42. breaking the fractonacci test into recursion plus something else, that would
  43. have been a possibility. I'll comment on this more later.
  44.  
  45. [] value: I agree that passing arguments and referencing method variables
  46. would have also been interesting tests. I limited myself severely as to the
  47. number of tests I did because ST/V-DOS was too crash-prone whenever I got too
  48. ambitious. If I had not been constrained to 16-bit integers and ST/V-DOS
  49. compatibility, I could have done more that was interesting. The reason I broke
  50. the tests up into a 'setup' method and 'execute' method was that the ST/V-DOS
  51. compiler could not handle it when it was combined into one large method.
  52.  
  53. Your simple recursion test: this was almost identical to the one posted by
  54. Marten Feldtmann a few weeks ago. It turned out that ST/V-PM outperformed
  55. ST80-Win on his benchmark. I wrote Slopstone and Smopstone to see whether it
  56. would also beat ST80 on a wider range of tests. In general, I don't think ST80
  57. is very well optimized for recursive calls.
  58.  
  59. Your sieve test: I wish I had this when I wrote Smopstones. I probably would
  60. have included it.
  61.  
  62. Conclusion: Thank you for your constructive criticisms. I would incorporate
  63. some of your suggestions into a revised form of Slopstone and Smopstone, but I
  64. don't have the time. They are already set in concrete, and quite a few results
  65. have already been tabulated for them. However, perhaps in the future, you or I
  66. or someone else may offer a new set of benchmarks that are more theoretically
  67. sound and well balanced. Thanks again for your comments.
  68.  
  69. I plan to write a short article for The Smalltalk Report on benchmarking, and
  70. will cite your concerns there, along with similar concerns from others. I'll
  71. keep your name anonymous unless you tell me otherwise.
  72. -- 
  73. **********************************************************
  74. * Bruce Samuelson    Department of Linguistics     *
  75. * bruce@ling.uta.edu    University of Texas at Arlington *
  76. **********************************************************
  77.