libove@libove.UUCP (Jay Mathew Libove) (07/26/88)
Well, I received two sets of speedup sources - one from ucbvax!cogsci!jsilva
and a second from hutch@hubcap.clemson.edu (gatech!hubcap.clemson.edu!hutch)
and I built compress with the two of these upgrades (one at a time, of
course; the two speedups replace the same routine) and then I compressed
a copy of /xenix and a 500K text file with each.
Results:
file straight compress +jsilva +hutch
/xenix 3.2s 4.8s 3.7s
500K text 4.9s 5.0s 5.1s
Now, I don't know if I did something funny, but I've been at this kind
of stuff for a while, and I don't think I missed anything.
So, has anyone else tried these "speed-ups" out yet? What results did
you get? For me, obviously, I am staying with the distribution version!
--
-Jay Libove {pitt|bellcore}!darth!libove!libove *or* Jay.Libove@andrew.cmu.edujsilva@cogsci.berkeley.edu (John Silva) (07/28/88)
libove@libove.UUCP writes: >Well, I received two sets of speedup sources - one from ucbvax!cogsci!jsilva >and a second from hutch@hubcap.clemson.edu (gatech!hubcap.clemson.edu!hutch) >and I built compress with the two of these upgrades (one at a time, of >course; the two speedups replace the same routine) and then I compressed >a copy of /xenix and a 500K text file with each. > >Results: >file straight compress +jsilva +hutch > >/xenix 3.2s 4.8s 3.7s >500K text 4.9s 5.0s 5.1s > >Now, I don't know if I did something funny, but I've been at this kind >of stuff for a while, and I don't think I missed anything. > >So, has anyone else tried these "speed-ups" out yet? What results did >you get? For me, obviously, I am staying with the distribution version! >-- >-Jay Libove {pitt|bellcore}!darth!libove!libove *or* Jay.Libove@andrew.cmu.edu I'm not sure what was going on, but it sounds to me like your compiler was generating the proper instructions in the first place. You wouldn't happen to be running a 386 box, would you? If so, that explains the slowdown. (Doesn't help to replace a 32 bit shift instruction with a function call to several 16 bit shifts...) Your figures sound like the cpu time figures from csh's 'time' command. In my tests, the user time decreased, the cpu time increased, the actual elapsed time decreased (this is where I drew the percentage speedup percentages from), and cpu utilization increased. Did you take your figures from the x.xs field that 'time' returns? BTW, I also recieved a copy of hutch's speedup code, and found that his code was optimized much better than my code was. He did miss one place where he could remove one instruction, however. (I have since re-optimized my routines, which are now nearly identical to hutch's routines... So much for original looking code.... :) Both sets of routines seem to work fine, however, so I wouldn't be concerned about which set to use. Both definately speed compress up more than 25% when used with a 286 compiler. John P. Silva --- UUCP: ucbvax!cogsci!jsilva DOMAIN: jsilva@cogsci.berkeley.edu
det@hawkmoon.MN.ORG (Derek E. Terveer) (07/30/88)
In article <60@libove.UUCP>, libove@libove.UUCP (Jay Mathew Libove) writes: > So, has anyone else tried these "speed-ups" out yet? What results did > you get? For me, obviously, I am staying with the distribution version! I have attempted to compile the speedup assembly routine in with the compress 4.0 that i have and, so far, i have gotten it to compile and link but when compressing a sample file, say /tmp/compress.c, i get: -12.5% compression -- file not changed obviously something is wrong. Perhaps it is the way i compiled it. is there any special way one can cause the speedup.s code to be compiled in 286 mode? I have to use the -Ml model to get compress to compile and i have tried doing a cc -Ml on the speedup.c and a "file speedup.o" states that it is an 8086 relocatable. I know that problems will occur when trying to link differing memory models. Does anyone know how to generate a 286 object out of the assembly code (or is that file can't tell the model from relocatables?). I have even tried sticking in a ".286p" directive into the code. This stuff didn't work with just 8086 either, btw. -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 h(612)688-0667
jsilva@cogsci.berkeley.edu (John Silva) (08/01/88)
Derek, it is possible that your compiler generates the calls to the long integer shift routines somewhat differently. The only thing you'll be able to do to get it to work (I think) is to use adb, determine how the original shift routines are called, and rewrite the speedup assembly to function as with your particular calling sequence. It does seem strange. In any case, I use cc -M2le -o compress compress.c speedup.s to compile compress. Seems to work. BTW, has anyone solved the problem with SCO Xenix and compress where compress will refuse to compress certain files and get a segmentation violation? John Silva --- UUCP: ucbvax!cogsci!jsilva DOMAIN: jsilva@cogsci.berkeley.edu