madler@piglet.caltech.edu (Mark Adler) (10/03/90)
>> I could easily imagine the Unix compress command running several times >> faster on the DSP. > I can't. The current 'compress' is basically I/O bound on any machine > worth its salt. Unless the DSP can talk to the disk faster than the Then perhaps the 030 isn't worth its salt (or sand in the case of a chip). Or maybe its the program, but Monitor shows the CPU at 100% utilization during a compress or decompress. Am I misreading Monitor? Mark Adler madler@piglet.caltech.edu
amanda@visix.com (Amanda Walker) (10/04/90)
In article <1990Oct3.163742.13055@nntp-server.caltech.edu>, madler@piglet.caltech.edu (Mark Adler) writes: > Monitor shows the CPU at 100% utilization > during a compress or decompress. Am I misreading Monitor? I'm not too familiar with Monitor, but try compiling compres with profiling and looking at where inside the program it's spending its time--on most machines, most of the real time will be spent reading and writing. 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. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "In this age, the mere example of nonconformity, the mere refusal to bend the knee to custom, is itself a service." --John Stuart Mill, "On Liberty" (1859)
madler@piglet.caltech.edu (Mark Adler) (10/04/90)
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
kline@cs.arizona.edu (Nick Kline) (10/04/90)
I don't find it too surprising that compress is cpu bound. Consider the limpel-ziv algorithm: A lot of time is spent working on quanties that are not byte sizes. You have to do a lot of shifting and things like that. -nick