Received: by cthulhu.engr.sgi.com (941129.SGI.8.6.9/911001.SGI)
	for tiff-list id NAA15865; Fri, 16 Dec 1994 13:19:13 -0800
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (941129.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id NAA15858; Fri, 16 Dec 1994 13:19:06 -0800
Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.sgi.com> id NAA28456; Fri, 16 Dec 1994 13:19:04 -0800
Received: from oxford.chez.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI)
	 id NAA17505; Fri, 16 Dec 1994 13:19:03 -0800
Received: by oxford.chez.sgi.com via SMTP (931110.SGI/930416.SGI)
	for tiff@sgi.sgi.com id AA19363; Fri, 16 Dec 94 13:17:20 -0800
Message-Id: <9412162117.AA19363@oxford.chez.sgi.com>
To: kg@mykonos.rc.rit.edu (Kyriakos Georgiou)
Cc: tiff@sgi.sgi.com
Subject: Re: JBIG compression 
Reply-To: Sam Leffler <sam@engr.sgi.com>
In-Reply-To: Your message of "Fri, 16 Dec 1994 16:02:03 EST."
             <m0rIjmt-0007zYC@mykonos.rc.rit.edu> 
Date: Fri, 16 Dec 1994 13:17:19 PST
From: Sam Leffler <sam@oxford.chez.sgi.com>
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

    To:  sam@cthulhu.engr.sgi.com
    Subject:  Re: JBIG compression
    Cc:  tiff@sgi.sgi.com
    Date: Fri, 16 Dec 1994 16:02:03 EST
    From:  kg@mykonos.rc.rit.edu (Kyriakos Georgiou)

    In response to Sam's comments:
    
    >     Also, can the current libtiff G4 decompression implementation be
    >     improved ? What sort of improvements can be expected ?
    > 
    > What's wrong with the current implementation?
    
    The current implementation is fine, but.. I have in my hands a commercial
    product (no source) that does decompression in noticable less time.
    That suggests that there are faster ways to decompress G4 in software,
    alas my question.

The code distributed in the library runs on a multitude of platforms
and is not tuned to any one specific platform.  I can easily squeeze
a noticeable improvement out of my specific code by tuning it to say,
a MIPS R4000 CPU with a particular cache configuration.
    
    >     I don't want to get into algorithmic issues, my question is, is there
    >     room for >15% improvement on G4 for the implementation of libtiff ?
    > 
    > Until you cite specific goals (and architecture for running the
    > software) this question is silly.  Try measuring the performance of the
    > current algorithm before looking for improvements.
    
    Unless you didn't understand what I am talking about - CCITT Group 4
    decompression speed - I find this answer silly.  What does the
    architecture have to do with algorithmic improvements ? Perhaps you
    should read a computational theory and algorithms book before defining
    what silly questions are.

Well, try tuning algorithms for RISC style machines and you'll quickly
find that significant performance differences can be due to cache
effects and/or optimal organization of instructions to reflect CPU and
compiler pipeline scheduling algorithms.  Additional effects are often
noticed when working with large images or on multi-user systems where
memory contention can significantly impact performance.

Asking for >15% improvement in a vaccum typically means you're asking
for a different algorithm.
 
    In response to your 2nd comment, why would I be looking for improvements 
    if I had not measured the performance of the current algorithm?  If you
    remember, few weeks ago I sent some remarks on the new improved G4
    decompression running on a pentium.
    
i didn't connect your previous mail to this one (there was no
mention).  I would have taken your comment more seriously if you'd
identified what you were comparing, in what environment, cited results
for both algorithms/implementations, and identified the input data.
Then it might have been possible to evaluate the performance figures
in such as way as to identify whether your question was answerable w/o
a peek at the source code?
    
BTW, you weren't using an FDIV instructions in calculating the 
performance figures? :-)

    Sam


