Положить в папку sxs содержимое из установочного диска (microsoft-windows-netfx3-ondemand-package.cab). При этом сам скачивать по сети, или же использовать распакованный образ из шары — отказывался.
Хибернейт, но несколько месяцев хибернейт. Сделал проверку на виндовые апдейты, и оно вылезло, т.е. если и кешировал где, то очень тайно, потому что скачивал всё целиком.
Вчера включил ноутбук и он упорно мне предлагал обновиться на Win10, стало интересно, сроки ведь прошли — обновился, активировался. Так что, судя по всему, даже инвалидом не надо быть, до сих пор всё само происходит.
Ну, это не ко мне вопрос :) А к разработчикам Microsoft. А если серьёзно, то встроенная индексация ещё смотрит содержимое файлов и метатеги. Т.е. этим поиском может найти письма по содержимому, музыку по тегам и прочее. И вообще там есть целый язык запросов для всего этого барахла.
Другое дело, что многим этого не надо, и большинство этим не пользуется.
И? Чем это противоречит тому, что я сказал? Файл будет обработан точно также. Как поток. Хотя в реальности, данный поток или файл приведут тупо к заполнению внутреннего буфера определённой длины (32-64Кб), который будет пожат и выплюнут наружу.
Вообще, давайте прекращать эту дискуссию (или уходить в ЛС), а то совсем от темы статьи уехали. Вот я напишу статью про устройство архиваторов с примером реализации (я джва года уже хочу это сделать, но лень), и там уже знатно посрёмся и помакаем друг друга в нечистоты ;)
Сравните «ацки быстрый lzo» с rar на реальных файлах и вы прозреете. Понятно, что lzo быстрее, но в большинстве случаев место важнее. Не, ну кого интересует файл из одних нулей. Не прикалывайтесь.
Сравнивал, знаю. Двукратное улучшение сжатия и десятикратное падение скорости.
Один словарь хорошо, когда файлы одного типа(например текст на одном языке). Если тип данных меняется(а это почти всегда), множественные словари выигрывают.
Да какие там словари… нет в LZ77 словарей, там плавающее окно. И это гораздо проще, понятнее и быстрее чем словари. А это плавающее окно само подстроится под данные.
У винрара множество алгоритмов с эврестическим выбором по типу файла и/или характеристикам данных.
Кроме PPMd, там, насколько я помню, трансформирующие алгоритмы. А это всего-лишь пред.обработка перед тем же самым сжатием.
У винрара множество алгоритмов с эврестическим выбором по типу файла и/или характеристикам данных.
Ну, я вроде это и написал, LZ77 + энтропия. Но они не двухпроходные, а один поверх другого. Или вы считали подготовительные алгоритмы за проход?
Все архиваторы в конце концов работают с потоком (ну или с массивом байт). В данном случае, AdventureWorks (100 или 200 мегабайт) в потоке с флушами (могу сделать и независимыми блоками). Вообще, этот график был в своё время сделан не для демонстрации не размеров блоков, а полезности при «запоминании» предыдущего блока. Ну и для размера блока он подошёл.
Но в целом, при размерах блоков больше 64Кб — разница уже небольшая. Связано с тем, что размер «словаря» (не люблю это слово для LZ77), как раз 32-64Кб у данных архиваторов. Больший размер словаря даёт мало эффекта.
Хм, я всегда считал, что чем более крупный блок анализируется, тем лучше сжатие, ведь на бОльшем блоке можно найти бОльше совпадений и создать лучший словарь?
Да, но при размере в 1Mb, уже копеечная разница получается.
Картинка по размеру блоков
Тут как раз видно, насколько влияют граничные байты (Blazer и GZip) и независимые блоки (LZ4, Snappy)
Есть где-то ссылка, где бы детальнее показывалось как работает winrar, имеется ввиду именно работа с блоками? В стандартном faq и быстрым гуглением не вижу…
Да вроде бы он достаточно простой — LZ77 + энтропийное сжатие (тут не помню какое). Блоки, думаю как и в 7zip — при 1-2 тредах — потоковый, при большем количестве — независимые.
Делают. Ибо это аццки быстрее. Смотрите на LZ4, Snappy, LZO, QuickLZ и прочие. Это получается практически бесплатное архивирование при хорошем результате.
Есть граничные байты.
На них, как раз и проблема. Представьте для простоты файл в миллиард нулей. Сжимается в условные 5 байт (повторить миллиард раз ноль). С блоками у вас будет — повторить размер блока ноль. В реальности, это копейки, правда.
Потому необходим этап проверки «а не получится ли лучше если вот эти 10 кусков подряд сделать одним словарем»
Или вы фигню говорите, или в вашем понимании куски являются последовательностью, а не блоками. И классического Хаффмана (Дефри-Халман — это что-то среднее из Хаффмана и Диффи-Хеллмана, т.е. вообще не по делу), никто не использует. Обычный однопроходной энтропийный алгоритм.
Если данные iPhone поставить друг на друга, то можно будет достать до луны. А если разложить горизонтально, то можно покрыть 18 футбольных полей. Если уж мерять всё в них, надо другие стандартные единицы тоже не забывать :)
Я тоже обычно выбираю модель, потом производителя. И я в принципе смотрю на их особенности, но если видеокарта не какая-либо специальная «разогнанная» с другой системой охлаждения, то она скорее всего будет на референсной платформе, с референсным кулером, полностью идентичная любой другой. И тут 1% производительности вверх по тестам может заставить сделать выбор именно в пользу данного производителя.
Положить в папку sxs содержимое из установочного диска (microsoft-windows-netfx3-ondemand-package.cab). При этом сам скачивать по сети, или же использовать распакованный образ из шары — отказывался.
Другое дело, что многим этого не надо, и большинство этим не пользуется.
Вообще, давайте прекращать эту дискуссию (или уходить в ЛС), а то совсем от темы статьи уехали. Вот я напишу статью про устройство архиваторов с примером реализации (я джва года уже хочу это сделать, но лень), и там уже знатно посрёмся и помакаем друг друга в нечистоты ;)
Сравнивал, знаю. Двукратное улучшение сжатия и десятикратное падение скорости.
Да какие там словари… нет в LZ77 словарей, там плавающее окно. И это гораздо проще, понятнее и быстрее чем словари. А это плавающее окно само подстроится под данные.
Кроме PPMd, там, насколько я помню, трансформирующие алгоритмы. А это всего-лишь пред.обработка перед тем же самым сжатием.
Ну, я вроде это и написал, LZ77 + энтропия. Но они не двухпроходные, а один поверх другого. Или вы считали подготовительные алгоритмы за проход?
Но в целом, при размерах блоков больше 64Кб — разница уже небольшая. Связано с тем, что размер «словаря» (не люблю это слово для LZ77), как раз 32-64Кб у данных архиваторов. Больший размер словаря даёт мало эффекта.
Да, но при размере в 1Mb, уже копеечная разница получается.
Тут как раз видно, насколько влияют граничные байты (Blazer и GZip) и независимые блоки (LZ4, Snappy)
Да вроде бы он достаточно простой — LZ77 + энтропийное сжатие (тут не помню какое). Блоки, думаю как и в 7zip — при 1-2 тредах — потоковый, при большем количестве — независимые.
Делают. Ибо это аццки быстрее. Смотрите на LZ4, Snappy, LZO, QuickLZ и прочие. Это получается практически бесплатное архивирование при хорошем результате.
На них, как раз и проблема. Представьте для простоты файл в миллиард нулей. Сжимается в условные 5 байт (повторить миллиард раз ноль). С блоками у вас будет — повторить размер блока ноль. В реальности, это копейки, правда.
Или вы фигню говорите, или в вашем понимании куски являются последовательностью, а не блоками. И классического Хаффмана (Дефри-Халман — это что-то среднее из Хаффмана и Диффи-Хеллмана, т.е. вообще не по делу), никто не использует. Обычный однопроходной энтропийный алгоритм.