Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jarthur!nntp-server.caltech.edu!piglet!madler From: madler@piglet.caltech.edu (Mark Adler) Newsgroups: comp.sys.next Subject: Re: DSP compression (was Re: Extended OS Part II) Message-ID: <1990Oct3.204010.17437@nntp-server.caltech.edu> Date: 3 Oct 90 20:40:10 GMT References: <5122@quiche.cs.mcgill.ca> <1990Oct3.061950.29203@nntp-server.caltech.edu> <1990Oct3.084923.22547@visix.com> <1990Oct3.163742.13055@nntp-server.caltech.edu> <1990Oct3.182137.24329@visix.com> Sender: news@nntp-server.caltech.edu Organization: California Institute of Technology, Pasadena Lines: 35 Nntp-Posting-Host: piglet.caltech.edu amanda@visix.com (Amanda Walker) believes: >> The CPU certainly has some stuff to do, and it's slightly busier >> during a compress, but the inner loop of the program is really >> pretty small once everything has been set up. Then perhaps setting up takes longer than you think. Here is some data using the Unix "time" command on compress, uncompress, and cp (straight file i/o): time uncompress Buzz9.ps 22.0u 4.3s 0:28 92% 0+0k 97+317io 0pf+0w time cp Buzz9.ps x.x 0.0u 3.3s 0:11 28% 0+0k 313+319io 0pf+0w time compress Buzz9.ps 43.2u 3.8s 0:49 95% 0+0k 309+97io 0pf+0w time cp Buzz9.ps.Z y.y 0.0u 0.9s 0:02 38% 0+0k 28+97io 0pf+0w The "u" times compared to the real times indicate that the process is definitely not I/O bound. I was the only one on the machine, so averaging the copy (cp) real times gives about 7 seconds for the file i/o. That indicates that on the compress, about 14% of the time was spent on file i/o, and on the uncompress, about 25% of the time was spent on file i/o. If the compression could be made I/O bound, this would give about 7 times the speed on compress and 4 times the speed on uncompress. I therefore stand by my previous statement that compression could be sped up "several" times. Mark Adler madler@piglet.caltech.edu