home *** CD-ROM | disk | FTP | other *** search
/ Internet File Formats / InternetFileFormatsCD.bin / graphics / tiff / unix / archive.z / archive / text0044.txt < prev    next >
Encoding:
Text File  |  1995-09-20  |  2.9 KB  |  66 lines
  1.     To:  sam@cthulhu.engr.sgi.com
  2.     Subject:  Re: JBIG compression
  3.     Cc:  tiff@sgi.sgi.com
  4.     Date: Fri, 16 Dec 1994 16:02:03 EST
  5.     From:  kg@mykonos.rc.rit.edu (Kyriakos Georgiou)
  6.  
  7.     In response to Sam's comments:
  8.     
  9.     >     Also, can the current libtiff G4 decompression implementation be
  10.     >     improved ? What sort of improvements can be expected ?
  11.     > 
  12.     > What's wrong with the current implementation?
  13.     
  14.     The current implementation is fine, but.. I have in my hands a commercial
  15.     product (no source) that does decompression in noticable less time.
  16.     That suggests that there are faster ways to decompress G4 in software,
  17.     alas my question.
  18.  
  19. The code distributed in the library runs on a multitude of platforms
  20. and is not tuned to any one specific platform.  I can easily squeeze
  21. a noticeable improvement out of my specific code by tuning it to say,
  22. a MIPS R4000 CPU with a particular cache configuration.
  23.     
  24.     >     I don't want to get into algorithmic issues, my question is, is there
  25.     >     room for >15% improvement on G4 for the implementation of libtiff ?
  26.     > 
  27.     > Until you cite specific goals (and architecture for running the
  28.     > software) this question is silly.  Try measuring the performance of the
  29.     > current algorithm before looking for improvements.
  30.     
  31.     Unless you didn't understand what I am talking about - CCITT Group 4
  32.     decompression speed - I find this answer silly.  What does the
  33.     architecture have to do with algorithmic improvements ? Perhaps you
  34.     should read a computational theory and algorithms book before defining
  35.     what silly questions are.
  36.  
  37. Well, try tuning algorithms for RISC style machines and you'll quickly
  38. find that significant performance differences can be due to cache
  39. effects and/or optimal organization of instructions to reflect CPU and
  40. compiler pipeline scheduling algorithms.  Additional effects are often
  41. noticed when working with large images or on multi-user systems where
  42. memory contention can significantly impact performance.
  43.  
  44. Asking for >15% improvement in a vaccum typically means you're asking
  45. for a different algorithm.
  46.  
  47.     In response to your 2nd comment, why would I be looking for improvements 
  48.     if I had not measured the performance of the current algorithm?  If you
  49.     remember, few weeks ago I sent some remarks on the new improved G4
  50.     decompression running on a pentium.
  51.     
  52. i didn't connect your previous mail to this one (there was no
  53. mention).  I would have taken your comment more seriously if you'd
  54. identified what you were comparing, in what environment, cited results
  55. for both algorithms/implementations, and identified the input data.
  56. Then it might have been possible to evaluate the performance figures
  57. in such as way as to identify whether your question was answerable w/o
  58. a peek at the source code?
  59.     
  60. BTW, you weren't using an FDIV instructions in calculating the 
  61. performance figures? :-)
  62.  
  63.     Sam
  64.  
  65.  
  66.