pegasus@quiche.cs.mcgill.ca (Philippe PROVOST) (10/02/90)
Hello Folks, i ve a single question: can t NeXT use his chip (from Ccube i guess) to compress part of the Extended OS for buyer of a NeXTDimension Board ? Another suggestion: since it appears that any owner of a NeXT computer get a licence for the entire Operating system (Extensions included), why NeXT couldn tset up a ftp server to broadcast such Extensions , thus giving users a chance to upload such files over the net ? [ie, if NeXT cantdo such operation,is it possible for a couple of sites to do such thing ? cs.orst.edu and *.purdue.edu for instance] May be silly questions after all ! :) But we all know that NeXT listen all suggestion from users, so i am quite confident :-) [ Pegasus ] French exchange Student pegasus@calvin.cs.mcgill.ca Master in Computer Sc. a New NeXT's user
mdixon@parc.xerox.com (Mike Dixon) (10/03/90)
i've a single question: can' t NeXT use this chip (from Ccube i guess)
to compress part of the Extended OS for buyer of a NeXTDimension Board?
uh, no. there's no magic algorithm that gives you perfect 20-to-1
compression of arbitrary bit streams. jpeg compression and decompression
is almost certain to give you a different set of bits than you started
with; it's just that they'll look similar on a color monitor. that's
not a satisfactory property when you're interested in compressing a file
system.
--
.mike.madler@piglet.caltech.edu (Mark Adler) (10/03/90)
JPEG only approximately recovers the original and only works well on video images anyway. However, I saw mentioned in one of the NeXT blurbs on the new machines that the 56001 is being used for sound and data compression. I could easily imagine the Unix compress command running several times faster on the DSP. Mark Adler madler@piglet.caltech.edu
amanda@visix.com (Amanda Walker) (10/03/90)
In article <1990Oct3.061950.29203@nntp-server.caltech.edu>, madler@piglet.caltech.edu (Mark Adler) writes: > 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 680x0 :-), it would be of no help whatsoever... -- 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)
scott@NIC.GAC.EDU (10/03/90)
madler@piglet.caltech.edu (Mark Adler) writes:
JPEG only approximately recovers the original and only works well on video
images anyway. However, I saw mentioned in one of the NeXT blurbs on the
new machines that the 56001 is being used for sound and data compression.
I could easily imagine the Unix compress command running several times
faster on the DSP.
I'm sure they mean that with regards to sound, or data taken through the
DSP port. Currently, there's not very good support for large-scale
communications with the DSP from the main processor (no DMA). I hear
that the new version doesn't do it, either, but that's rumor (please!).
Without hi-speed large data transfer, many operations simply run faster
on the '030. Considering the size of compress'ed files, this would be
one of them.
Of course, a nice '040 would cure many of those complaints (compress
speed), expect that much of compress' overhead is in file reading
and writing, so don't expect a 3x speedup :-) I may be wrong (please!).
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
NeXT Campus Consultant (Not much, really)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)glenn@heaven.woodside.ca.us (Glenn Reid) (10/04/90)
In article <1990Oct3.084923.22547@visix.com> amanda@visix.com (Amanda Walker) writes: >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 >680x0 :-), it would be of no help whatsoever... Hmmmm. If 'compress' is I/O bound, how come it takes so much longer than 'cp'? heaven> time compress Aachen-Bold 1.3u 0.3s 0:02 75% 0+0k 8+16io 0pf+0w heaven> uncompress Aachen-Bold.Z heaven> time cp Aachen-Bold foo 0.0u 0.1s 0:00 31% 0+0k 0+14io 0pf+0w I should have used a larger file, of course, but you get the idea. Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
amanda@visix.com (Amanda Walker) (10/05/90)
In article <288@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > Hmmmm. If 'compress' is I/O bound, how come it takes so much longer > than 'cp'? Well, as several people have also pointed out in email, I seem to have been smoking my socks :-). Now, it is true that LZW compression is asymmetric in time--it takes less time to decompress than compress. I may have been thinking of some experiments I did a while back with *de*compression speeds. Even so, though, measurement seems to show that it's still pretty CPU-bound. Well, nobody's perfect. I'm still not convinced the DSP would be faster, but I promise not to make any pronouncement about it until I've actually tried it this time :-). -- 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)