Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.arch
Subject: Re: Architecture questions
Message-ID: <6851.26efc686@vax1.tcd.ie>
Date: 13 Sep 90 17:48:54 GMT
References: <10057@goofy.Apple.COM> <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <390@tygra.UUCP>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 24

In article <390@tygra.UUCP>, dave@tygra.UUCP (David Conrad) writes:
> I'll only list two: Huffman coding and LZW compression.  But notice, every one
> of the things you've mentioned typically use large disk files.  And I've listed
> data compression algorithms.  If data could be uncompressed on the fly faster,
> then this would be done more often - with a decrease in the disk I/O needed by
> these operations which would be paid for in computation time.  Disk reads vs.
> number crunching cycles.  My guess is there would be a net gain in efficiency
> there.
> --

To make Huffman more efficient you don't just need bit pointers, you need bit
pointers that can overlap a word boundary. I'm not familiar with the LZW
algorithm but I suspect the same thing applies. To implement this you'd need so
much extra hardware in the data fetch path that the reduction in speed in
instruction fetches, counter operations, word transfers to/from disk buffers
etc. would probably more than outweigh the speed increase in bit manipulation.
In other words, even data compression could end up SLOWER with non-aligned bit
pointers. And as I said I don't believe there are significant uses for aligned
bit pointers (which would still slow down the chip but not as much).

-- 
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie