Author: Jeremiah Penery
Date: 10:12:53 01/20/00
Go up one level in this thread
On January 20, 2000 at 12:54:53, Dave Gomboc wrote: >On January 20, 2000 at 12:12:44, Jeremiah Penery wrote: > >>On January 20, 2000 at 04:39:38, Dave Gomboc wrote: >> >>>On January 20, 2000 at 03:30:03, Jeremiah Penery wrote: >>> >>>>I can say that for native NTFS (WinNT) disk compression, there was no noticable >>>>impact on performance for any program. I had things like TBs (Edwards) >>>>compressed, and performance wasn't slowed at all. Before Nalimov compression, I >>>>had those compressed that way also, with no noticable performance hit. >>>>I think NTFS compression is a bit conservative, though, and if you use something >>>>else, performance might be a bit less. YMMV. :) >>>> >>>>Jeremiah >>> >>>Probably NTFS was smart enough to detect that it couldn't recompress the data, >>>and consequently left the actual data alone. Some compression implementations >>>are not so clever. >> >>For which data? NTFS compressed the uncompressed Nalimov TBs from a total of >>~22GB to about 10GB. The Edwards TBs were compressed from 2.5GB to about 1GB, >>IIRC. > >Earlier in the thread I mentiioned "the latest" tablebases. By this, I meant >the compressed Nalimov ones. I would be surprised if NTFS could do a better job >compressing the databases than the code written specifically to do so. Maybe >you can compare the sizes and see. Ah. :) I didn't realize what exactly you were talking about. The specific compression is better. It is about 10GB for NTFS compression vs. 6GB for the Nalimov-specific compression for the full set of 3/4/5 piece TBs. Using NTFS compression to further compress the compressed Nalimov TBs doesn't gain a thing. IIRC, the sizes are identical, because NTFS can't compress them any further.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.