home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / graphics / 9355 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.8 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!olivea!sgigate!odin!fido!babar.asd.sgi.com!mtj
  2. From: mtj@babar.asd.sgi.com (Michael Jones)
  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: <pak809s@fido.asd.sgi.com>
  7. Date: 1 Sep 92 21:07:11 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: 47
  12.  
  13. In article <...>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
  14.  
  15. |> SGI is very eager to publish its SPECmarks for the processors on its
  16. |> machines.  The SPEC benchmark suite is similar to the PLB benchmark
  17. |> suite in conception.  The only conclusion I can draw from this is that
  18. |> SGI must not perform very well on the benchmark and doesn't want to
  19. |> publish "bad" numbers.
  20.  
  21. The PLB issue seems the perfect example of the Akin/Thomson dialogues
  22. on graphics programming interfaces. My understanding is that the PLB
  23. suite spends quite a bit of effort (thus time) "editing" the databases
  24. it is drawing. It does this *precisely because applications layered on
  25. API's like PHIGS and PEXlib* tend to spend quite a bit of their time
  26. convincing the graphics layer of their desires. This structural, non-
  27. graphic burden is a major factor in many applications, such as visual
  28. editors, CAD systems, and such.
  29.  
  30. The direct interface provided by GL and OpenGL avoids this, leaving it
  31. to the application to decide the structural issues. Often, the cost of
  32. editing the structure is zero -- once the desired changes are "known"
  33. to the application, it is then *immediately* able to issue the new
  34. graphics commands.
  35.  
  36. I feel that an SGI PLB suite benchmark would be hard to interpret. It
  37. would show, in many cases, what the cost (time) would be to do the
  38. very things that SGI has helped its customers avoid needing to do. On
  39. the other hand, it might make a good story ;-)
  40.  
  41.    (customer) "But why is this PLB application so much slower than
  42.                all the similar applications I see on SGI machines?"
  43.  
  44.    (salesman) "Because we're using a PHIGS/PEXlib style API."
  45.  
  46.    (customer) "Oh. I guess it must be the extra data movement and
  47.                redundant PHIGS structure editing."
  48.  
  49.    (salesman) "Exactly. Now let me show you the OpenGL version."
  50.  
  51.    (customer) "Wow!. No wonder they stopped making workstations."
  52.  
  53. Just my personal opinion. I have no doubt that the PLB effort is a
  54. valid one, and I freely admit that meaningful graphics benchmarks are
  55. very hard to develop.
  56.  
  57. -- Michael Jones    mtj@sgi.com  415.390.1455  M/S 7U-550
  58.             Silicon Graphics, Advanced Systems Division
  59.             2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
  60.