home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / graphics / 9356 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.0 KB

  1. Path: sparky!uunet!olivea!sgigate!odin!fido!akin
  2. From: akin@sgi.com (Allen Akin)
  3. Newsgroups: comp.graphics
  4. Subject: Re: NCGA Picture Level Benchmark (was: Time to put up or shut up)
  5. Keywords: benchmarks NCGA GPC
  6. Message-ID: <pakhf8k@fido.asd.sgi.com>
  7. Date: 1 Sep 92 21:17:17 GMT
  8. References: <1992Aug20.172200.17418@dsd.es.com> <ortnla8@fido.asd.sgi.com> <1992Sep1.194132.2601@dsd.es.com>
  9. Sender: news@fido.asd.sgi.com (Usenet News Admin)
  10. Organization: Silicon Graphics, Inc.
  11. Lines: 35
  12.  
  13. In article <1992Sep1.194132.2601@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:
  14. | In article <ortnla8@fido.asd.sgi.com>
  15. |     akin@sgi.com (Allen Akin) writes:
  16. | >If I had to guess, I'd say that SGI hasn't pursued the PLB because it
  17. | >hasn't made a difference to sales.  If PLB numbers were prerequisites
  18. | >for some significant number of purchase orders, the company would work
  19. | >on them more aggressively.
  20. | ...
  21. | SGI is very eager to publish its SPECmarks for the processors on its
  22. | machines.  The SPEC benchmark suite is similar to the PLB benchmark
  23. | suite in conception.  The only conclusion I can draw from this is that
  24. | SGI must not perform very well on the benchmark and doesn't want to
  25. | publish "bad" numbers.
  26.  
  27. Gee, Rich, that's not very imaginative.  Surely you can draw more than
  28. one conclusion from that data. :-)
  29.  
  30. The most likely situation is the one I mentioned earlier:  It takes
  31. time and effort to do a good job on the PLB, and if there's little
  32. demand for the result, then it makes sense to use the resources on
  33. other projects.  That's just normal business practice, especially in
  34. lean economic times.
  35.  
  36. SPEC is different because it figures prominently in many RFPs.  If
  37. there was comparable demand for PLB data, then I imagine SGI would
  38. pursue the PLB project more energetically.
  39.  
  40. This group is read by a number of people who are better-informed than I
  41. am about the state of PLB at SGI, so perhaps one of them will reply.
  42. I truly don't know how well SGI machines perform on the PLB, or if
  43. anyone is spending time to find out.
  44.  
  45. Allen
  46.