home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / arch / storage / 937 next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.1 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!yale.edu!ira.uka.de!sbusol.rz.uni-sb.de!coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman
  2. From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
  3. Newsgroups: comp.arch.storage
  4. Subject: Re: Managing a Terabyte (was: Re: Dumping a Gigabyte )
  5. Followup-To: comp.arch.storage
  6. Date: 21 Jan 1993 14:14:42 GMT
  7. Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
  8. Lines: 24
  9. Message-ID: <SPACKMAN.93Jan21151944@disco-sol.dfki.uni-sb.de>
  10. References: <1j55eiINNk3d@BSDI.COM> <1993Jan19.135733.838@walter.cray.com>
  11.     <1993Jan20.173950.20531@murdoch.acc.Virginia.EDU>
  12. Reply-To: stephen@acm.org
  13. NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
  14. In-reply-to: sdm7g@elvis.med.Virginia.EDU's message of Wed, 20 Jan 1993 17:39:50 GMT
  15.  
  16. In article <1993Jan20.173950.20531@murdoch.acc.Virginia.EDU> sdm7g@elvis.med.Virginia.EDU (Steven D. Majewski) writes:
  17.  
  18. [Lots of unassailable stuff - has anyone not worked this out yet? Then:]
  19.  
  20. |[ (**) This imbalance has other implications. Processor speeds are 
  21. |increasing faster than disk i/o speeds. At what point is uncompressing a
  22. |compressed instruction stream, or incremental compilation of a minimal
  23. |I-code faster than paging in code from virtual memory?  ] 
  24.  
  25. You lose big on optimisation this way. When compressing the results of
  26. translation tasks (whether that's parsing natural language or generating
  27. code) *for rapid decompression* you want to save the input **and
  28. selected choicepoint oracles**. As the compression folks will tell you,
  29. data modelling is the important part.... So the "I-code" shouldn't be so
  30. minimal, or rather, it should be augmented with the results of any
  31. computationally expensive decisions that the full compiler might once
  32. have made. (The advantage to two streams is architecture independence,
  33. of course).
  34.  
  35. Damn, here I go giving all my secrets away.... ;-)
  36. ----------------------------------------------------------------------
  37. stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
  38.       dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
  39. ----------------------------------------------------------------------
  40.