Учитывая, что диск работает медленно и многоядерный процессор, имеет ли смысл распаковку на лету? - PullRequest
2 голосов
/ 03 декабря 2009

Раньше сжатие диска использовалось для увеличения пространства хранения за счет эффективности, но тогда мы все были на однопроцессорных системах.

В наши дни существуют дополнительные ядра, чтобы потенциально выполнять декомпрессионную работу параллельно с обработкой данных.

Для приложений, связанных с вводом / выводом (особенно для чтения последовательных данных с высокой интенсивностью), возможно, можно увеличить пропускную способность, только читая и записывая сжатые данные на диск.

Есть ли у кого-нибудь опыт поддержать или опровергнуть эту гипотезу?

Ответы [ 4 ]

5 голосов
/ 04 декабря 2009

Старайтесь не перепутать время поиска диска и скорость чтения диска. Требуется миллионы циклов ЦП (5–10 миллисекунд или 5–10 миллионов наносекунд) для поиска правильного пути на жестком диске (HDD). Оказавшись там, вы можете читать десятки мегабайт данных в секунду, предполагая низкую фрагментацию. Для твердотельных накопителей (SSD) время поиска меньше (35 000–100 000 нс), чем для жестких дисков.

Независимо от того, сжаты ли данные на диске, вам все равно придется искать. Возникает вопрос: (время чтения с диска для сжатых данных + время распаковки) <(время чтения с диска для несжатых данных). Декомпрессия относительно быстрая, так как она заменяет короткий токен более длинным. В конце концов, это, вероятно, сводится к тому, насколько хорошо данные были сжаты и насколько они велики. Если вы читаете сжатый файл размером 2 КБ вместо оригинала объемом 5 КБ, это, вероятно, того не стоит. Если вы читаете сжатый файл размером 2 МБ вместо 25 МБ оригинала, скорее всего, это так. </p>

Мера с разумной рабочей нагрузкой.

4 голосов
/ 03 декабря 2009

Да! На самом деле, процессоры теперь настолько смехотворно быстры, что даже имеют смысл для памяти. (Я полагаю, что IBM делает это.) Я полагаю, что некоторые современные железные машины даже сжимают кэш-память ЦП.

2 голосов
/ 03 декабря 2009

Да, это имеет смысл. В ОС Windows на базе NT широко распространено мнение, что иногда включение сжатия NTFS может быть быстрее, чем отключение именно по этой причине. Это было верно в течение многих лет, и многоядерный должен только сделать это более правдоподобным.

1 голос
/ 04 декабря 2009

Я думаю, это также зависит от того, насколько агрессивно ваше сжатие по сравнению с тем, насколько вы ограничены IO.

Например, функция сжатия строк DB2 предназначена для приложений, связанных с вводом-выводом: хранилищ данных, систем отчетов и т. Д. Она использует алгоритм на основе словаря и не очень агрессивна - в результате сжатие данных (таблицы составляет 50-80%) , индексы в памяти, а также в памяти). Тем не менее, он также увеличивает скорость запросов примерно на 10%.

Они могли бы пойти с гораздо более агрессивным сжатием, но тогда бы получили удар по производительности.

...