🚀 go-pugleaf

In article <1991May13.045839.12228@uvm.edu> wollman@emily.uvm.edu (Garrett Wollman) writes:
> However, {,un}yabba will never replace compress so long as the latter
> compiles and runs without error on every popular machine and
> architecture, with the optimizer on, and and the former does not.

Since yabba compiles and runs without trouble under (for example) the
Acorn Archimedes, the Amiga, and MS-DOS with someone's version of gcc,
not to mention UNIX, while the compress source only works under UNIX and
has to be ported to each of those others individually, I'd say I'm
winning in the portability department. You were saying?

> [For example, yabba will not work for (some subset of the set of)
> large binary files on our SGI 4D/340S.

Let me suggest that you run ``checkconf'', included in the package, to
see whether you have configured the package properly. If that doesn't
work, then you should try turning off your optimizer and seeing what
happens. If the code works after that, then your optimizer is buggy, and
you should report the problem to your vendor.

> Dan also spent so much effort
> unrolling loops that the source is nearly incomprehensible,

I'm sorry you feel that way. The code is sufficiently well modularized
that I can easily read it and make changes to it, and that's all I need.

(As a matter of fact, I only unrolled one loop, and that was hardly any
effort. Most of the changes came from other types of optimizations. I
think they were worth it for more than a 2x speedup, though---Y coding
inherently involves three to five times more work than LZW, so I'm glad
that I was able to make yabba competitive in speed with compress.)

> and breaks
> a parallelizing preprocessor which can be used by the MIPS/SGI
> compiler to great effect.]

You should try compiling with -DOPTCANT1, as per instructions, to use
the minimum unrolling level. Be aware that on most machines this will
produce somewhat slower code.

---Dan