Кажется, что увеличение ЦП на какое-то время опережает скорость диска. Если предположить, что настольный компьютер или ноутбук с современным двухъядерным процессором Intel / AMD и одним средним диском SATA, даст ли сжатие большей части диска более высокую общую производительность? В основном ли уменьшенная пропускная способность диска более чем компенсирует возросшую нагрузку на ЦП? Я уверен, что настоящий ответ - «это зависит от того, что вы делаете». Задавая этот вопрос, я надеюсь, что кто-то, кто уже проделал эту трубку, даст несколько примеров или ошибок.
Да, сжатие диска может обеспечить лучшую производительность при определенных обстоятельствах:
Есть причина, по которой и ZFS, и Btrfs, недавние разработки с нуля, включают положения для сжатия.
В пространстве HPC, когда приложение выполняет контрольные точки из памяти на диск, процессоры часто вообще не делают ничего полезного. На этот раз по сути чистые накладные расходы. Любое использование ЦП для сокращения этого времени - это победа.
Сжатие диска будет никогда дать вам лучшую производительность.
Это может дать вам почти нет штрафа из-за быстрых современных процессоров, но это совсем другое дело.
Вы предполагаете, что необходимость передачи меньшего количества данных с / на диск может повысить производительность; но передача больших данных почти никогда не является узким местом ввода-вывода: настоящие узкие места - это время поиска и задержка. Современные жесткие диски действительно быстро при устойчивой передаче данных с большими файлами, замедляет их небольшая передача со всего диска.
Некоторые сценарии:
Существуют определенные ситуации, которые делают это уже на уровне приложения, например сжатие видео - система, которая не может достаточно быстро читать необработанное видео высокого качества из dsk, может вместо этого считывать сжатую информацию и расширять ее, используя память и мощность процессора. . Нет никаких причин, по которым это не могло быть также применимо к другим, конкретным ситуациям, но это может быть лучше всего обработано на уровне приложения, поэтому используемые методы сжатия оптимизированы для их целей.
Имейте в виду, что накладные расходы на декомпрессию имеют смысл, если общая пропускная способность увеличивается, поэтому эту идею нельзя сразу отбрасывать - я не думаю, что мы готовы к универсальному сжатию, повышающему производительность, но это теоретически возможно обменять ресурсы, которые у вас есть (ЦП и память), на повышение в другом месте (общий объем данных, считанных с жесткого диска)
Скорость процессора всегда была выше скорости диска. IMHO, сжатие увеличивает накладные расходы и, следовательно, снижает производительность.
Вчера я читал нечто похожее на это относительно OSX и его сжатия файловой системы - в основном ответ вращается вокруг того, что вы хотите сжать - в этом примере он говорит о данных "FAT"; файловые структуры, свойства, метаданные и т. д., которые при хранении вместе могут быть сжаты для экономии места и считаны в ЦП быстрее, чем при поиске заголовка повсюду для поиска данных для каждого файла ...
В любом случае, стоит прочитать, если вы думаете о таких вещах :-p
Но сжатие - это не только экономия места на диске. Это также классический пример обмена циклами ЦП для уменьшения задержки ввода-вывода и пропускной способности. За последние несколько десятилетий производительность ЦП улучшилась (а вычислительных ресурсов стало больше - подробнее об этом позже) гораздо быстрее, чем увеличивалась производительность дисков. На современных жестких дисках время поиска и задержки вращения по-прежнему измеряются миллисекундами. За одну миллисекунду процессор 2 ГГц проходит два миллиона циклов. И, конечно же, нужно учитывать фактическое время передачи данных.
Конечно, несколько уровней кэширования в ОС и аппаратном обеспечении эффективно скрывают эти задержки. Но эти биты должны в какой-то момент оторваться от диска, чтобы заполнить кеши. Сжатие означает, что нужно передать меньше битов. Учитывая почти комичный избыток ресурсов ЦП на современном многоядерном Mac при нормальном использовании, общее время, необходимое для передачи сжатой полезной нагрузки с диска и использования ЦП для распаковки его содержимого в память, обычно будет намного меньше, чем время потребуется передать данные в несжатом виде.
Это объясняет потенциальные преимущества в производительности при передаче меньшего количества данных, но использование расширенных атрибутов для хранения содержимого файла также может ускорить работу. Все это связано с локализацией данных.
Если есть что-то, что замедляет жесткий диск больше, чем передача большого количества данных, то это перемещение его головок с одной части диска на другую. Каждое движение означает, что по времени головка начнет двигаться, затем остановится, затем убедитесь, что она правильно расположена в желаемом месте, а затем подождите, пока вращающийся диск поместит желаемые биты под себя. Все это реальные, физические, движущиеся части, и удивительно, что они танцуют так же быстро и эффективно, но у физики есть свои пределы. Эти движения - настоящие убийцы производительности для вращающихся хранилищ, таких как жесткие диски.
Формат тома HFS + хранит всю информацию о файлах - метаданные - в двух основных местах на диске: в файле каталога, в котором хранятся даты файлов, разрешения, права собственности и множество других вещей, и в файле атрибутов, в котором хранятся «именованные вилки». . "
Расширенные атрибуты в HFS + реализованы как именованные ответвления в файле атрибутов. Но в отличие от вилок ресурсов, которые могут быть очень большими (вплоть до максимального размера файла, поддерживаемого файловой системой), расширенные атрибуты в HFS + хранятся «встроенно» в файле атрибутов. На практике это означает ограничение примерно 128 байтами на атрибут. Но это также означает, что головке диска не нужно совершать поездку в другую часть диска, чтобы получить фактические данные.
Как вы понимаете, к дисковым блокам, которые составляют файлы каталога и атрибутов, обращаются часто, и поэтому они с большей вероятностью, чем большинство других, находятся где-то в кэше. Все это направлено на то, чтобы обеспечить полное хранение файла, включая его метаданные в данных, в каталоге с B-древовидной структурой и файлах атрибутов, для повышения общей производительности. Даже восьмибайтовая полезная нагрузка, которая увеличивается до 25 байтов, не вызывает беспокойства, если она все еще меньше, чем размер блока распределения для обычного хранилища данных, и пока все это умещается в узле B-дерева в файле атрибутов, который в любом случае ОС должна быть прочитана полностью.
Есть и другие существенные вклады в сокращение занимаемой в Snow Leopard места на диске (например, удаление ненужных локализаций и файлов "designable.nib"), но сжатие HFS +, безусловно, наиболее технически интересно.
Из: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3
Сжатие Microsoft Disk уродливо СТАРЫЕ. По соотношению он не сравним с методом ARJ 80-х годов. Но даже сжатие Microsoft может обеспечить лучшую производительность на очень медленных жестких дисках (портативных). Особенно, если ОЗУ достаточно для кэширования записи и предотвращения чрезмерной записи.
Процесс записи - слабое место любого метода сжатия с произвольным доступом.
Итак, если вам нужен сжатый диск, вам лучше перейти на какой-нибудь Linux.
Сжатие диска также очень подходит для RAM-накопителей, не нужно объяснять почему.
Сомнительно. Сжатие и распаковка затрагивают не только диск и процессор; в частности, будет много операций по передаче данных в память и из памяти (в дополнение к стандартным накладным расходам на передачу без сжатия), что действительно повредит с точки зрения ошибок страницы.
Короче говоря, нет, вы, вероятно, не выиграете в производительности.
Хотя сжатие улучшит производительность вашего хранилища, оно значительно снизит скорость вашего процессора. Вероятно, все сводится к тому, какой тип файлов вы собираетесь распаковывать. Если вы имеете дело только с word, excel и другими базовыми типами файлов, сжимайте их. Если отдельные файлы более громоздкие, вам придется больше жертвовать своим временем.