The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз Gzip 1.6

10.06.2013 23:08

Представлен релиз популярной программы сжатия Gzip 1.6, в котором внесено 35 изменений. Наиболее заметным новшеством является реализация опции "--keep" ("-k"), при указании которой при сжатии и распаковке сохраняются исходные файлы, по аналогии с реализацией данной опции в xz, lzip и bzip2. Работа утилиты zmore приближена к more. Кроме того исправлена интересная ошибка, проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформах в восприятии интерактивного ответа "n" как "y" при обработке запроса перезаписи существующего файла.

  1. Главная ссылка к новости (http://savannah.gnu.org/forum/...)
  2. OpenNews: Релиз Gzip 1.5
  3. OpenNews: Вышел релиз gzip 1.4 с исправлением опасной уязвимости
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37143-gzip
Ключевые слова: gzip
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:52, 10/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > интересная ошибка, проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформах в восприятии интерактивного ответа "n" как "y" при обработке запроса перетирания существующего файла.

    Это круто. Такое специально трудно сделать, если вообще возможно.

     
     
  • 2.2, pkunk (ok), 00:05, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформах

    Compiling with -O2 ... can be seen in Arch Linux and Fedora 18 x86_64 builds

     
     
  • 3.3, Аноним (-), 00:11, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ну тогда все ок. Юзерам арча, федоры и убунты такие шутки уже привычны.
     
     
  • 4.4, Аноним (-), 00:17, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    где ты увидел слово убунту?
     
     
  • 5.6, Аноним (-), 01:28, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подобный баг вполне вписывается в ее фирменный стиль :)
     
  • 5.34, Аноним (-), 14:47, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > где ты увидел слово убунту?

    Когда я говорю программе "не затирай этот файл", а она все равно затирает - как еще это назвать, если не убунту?

     
  • 3.7, Аноним (-), 01:31, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > -O2
    > x86_64

    А это точно баг gzip, а не компилятора?

     
     
  • 4.11, pavlinux (ok), 02:16, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А это точно баг gzip, а не компилятора?

    Оба виноваты.

     
  • 2.13, Аноним (-), 04:35, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Это круто. Такое специально трудно сделать, если вообще возможно.

    Услужливый оптимизатор кода всегда поможет вам принять правильное решение. Соптимизировав заодно и занимаемое всяким крапом дисковое пространство :)

     
     
  • 3.30, Аноним (-), 14:41, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > крапом

    Опять ты со своими баззвордами?


     

  • 1.5, YetAnotherOnanym (ok), 00:32, 11/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > реализация опции "--keep"

    Вах, всего-то джвадцать лет понадобилось!

     
     
  • 2.17, Mr. Cake (?), 07:17, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он уже может в поточную архивацию?
     
     
  • 3.21, Andrey Mitrofanov (?), 10:01, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Он уже может в поточную архивацию?

    Здрассте! А в tar-е он как по-твоему используется?..

    pv </dev/zero |gzip >/dev/null

     
     
  • 4.40, Аноним (-), 17:18, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > pv </dev/zero

    Есть подозрение, что pv не сможет корректно оценить размер входного файла. Как минимум по двум причинам.

     
     
  • 5.41, Аноним (-), 20:44, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не мешает pv работать. Он даже бегунок покажет, снующий туда-сюда.
     
  • 5.43, Andrey Mitrofanov (?), 21:04, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> pv </dev/zero
    > Есть подозрение, что pv не сможет корректно оценить размер

    Я вполне понимаю ваш офтопичный наброс, и, да, я в курсе, и, да, корректнее, в контексте демонстрации работоспособности gzip в конвейере, было поставить pv после gzip. </было бы, о чём говорить>

     
     
  • 6.45, Аноним (-), 21:54, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > оставить pv после gzip.

    А что, в этом случае pv сможет правильно оценить размер входного файла?

     
     
  • 7.47, Andrey Mitrofanov (?), 22:47, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> оставить pv после gzip.
    > А что, в этом случае pv сможет правильно оценить размер входного файла?

    Я т-те второй раз внимательно повторяю: я в курсе. Без размера он показывает скорость и наличие движения вообще. И это его [другой, да??] штатный режим работы. Не возбуждайся так на размер /dev/zro, прими холодный душ.

     
     
  • 8.48, Аноним (-), 00:08, 12/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Сложно не возбуждаться Ведь такой огромный ... текст свёрнут, показать
     
  • 3.27, Аноним (-), 14:38, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Он уже может в поточную архивацию?

    Вообще-то да. И уже давно.

     

  • 1.12, AMD Man (?), 03:13, 11/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Таки в gzip'e скорее всего была ошибка: You are correct.   More searching shows yesno declared as returning bool in one place and int in the other.
     
     
  • 2.23, pavlinux (ok), 12:23, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Таки в gzip'e скорее всего была ошибка: You are correct.  
    > More searching shows yesno declared as returning bool in one place
    > and int in the other.

    Ваще-то по стандарту, компулятор С обязан правильно обрабатывать неявные преобразования типов. Для С++ - это бага, для С - фича. :)

     
     
  • 3.32, Аноним (-), 14:44, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ваще-то по стандарту, компулятор С обязан правильно обрабатывать неявные преобразования типов.

    А предупреждения в таких случаях писать он случайно не обязан?

     
     
  • 4.35, Нанобот (?), 14:54, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не обязан. хотя, по доброте душевной, обычно всё таки пишет.
     
     
  • 5.38, dq0s4y71 (??), 15:22, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Компилятор - нет. Потому что в данном случае у одной и той же функции разные прототипы, и  компилятор об этом не знает. А вот линковщик мог бы и выдать предупреждение. Но я не уверен, должен ли знать сишный (не С++) линковщик что-то о типах и что именно.
     
  • 3.37, dq0s4y71 (??), 15:16, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Здесь дело не в неявном преобразовании типов, а в том, что в одном месте yesno() описана как возвращающая bool (1 байт), а в другом - как int (4 байта). Когда yesno() возвращает, допустим, false, она кладёт 0 в %al. При этом в старших байтах %eax может на тот момент содержаться всё что угодно. А вызывающая функция думает, что yesno() возвращает int и делает test %eax, %eax, и, естественно, мусор содержащийся в старших байтах, даёт ненулевой результат. Я так ДУМАЮ :)
     
     
  • 4.44, pavlinux (ok), 21:34, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В С99, _Bool - это unsigned int;



    6.3.1.2 Boolean type

    Note that, although _Bool is technically an integer type, conversion to _Bool does not always
    work the same as conversion to other integer types. Consider, for example, that the expression
    (_Bool)0.5 evaluates to 1, whereas (int)0.5 evaluates to 0. The first result is correct: it
    simply says that 0.5 is non-zero; but it may be somewhat counter-intuitive unless a _Bool is
    thought of as a “truth value” rather than as a one-bit integer.



     
     
  • 5.51, dq0s4y71 (??), 13:20, 13/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, и ваша цитата, вообще-то, это подтверждает :)

    Ещё можете для общего развития сравнить выдачу от printf("%u\n", sizeof(_Bool)); и printf("%u\n", sizeof(unsigned int));

     
     
  • 6.53, pavlinux (ok), 18:17, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет, и ваша цитата, вообще-то, это подтверждает :)

    Уверен, что читать умеешь?

    "_Bool is technically an integer type"

    > ещё можете для общего развития сравнить выдачу от printf("%u\n", sizeof(_Bool)); и printf("%u\n", sizeof(unsigned int));

    Во ты лошара  :-D



    #include <stdio.h>
    #include <stdbool.h>

    #ifdef __bool_true_false_are_defined

    int main(void) {

            printf("%zu %zu\n", sizeof(true), sizeof(false)); // %zu - sizeof возвращает size_t

      return 0;
    }
    #else
            #error "Not true boolean system"
    #endif



     
     
  • 7.58, dq0s4y71 (??), 15:43, 17/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Уверен, что читать умеешь?
    > "_Bool is technically an integer type"

    Я - да. И поэтому я прочитал предложение полностью, а не выдрал одну фразу из контекста.

    >[оверквотинг удален]
    > int main(void) {
    >         printf("%zu %zu\n", sizeof(true), sizeof(false));
    > // %zu - sizeof возвращает size_t
    >   return 0;
    > }
    > #else
    >         #error "Not true boolean
    > system"
    > #endif
    >

    И что ты этим хотел сказать? Что sizeof возвращает size_t?

     
  • 6.54, pavlinux (ok), 18:46, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ах да, в догонку _Бууль может быть как singned char, так и enum.
    И ваще, изначально это формулировалось так: Bool могёт быть представлен
    любым целым типом, позволяющим вместить 0 или 1. (как-то так)

    #ifdef Someting
    #    define _Bool signed char
    #else
         typedef enum { false = 0, true = 1 } _Bool;
    #endif

    Когда оно было енум, то вываливалась очень полезный варнинг: "Еnumerated type mixed with another type".


     
     
  • 7.59, dq0s4y71 (ok), 15:52, 17/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ты догадался, что у компиляторов, не поддерживающих _Bool, _Bool может быть вообще чем угодно? Ты умница! :)

    А теперь поставь нормальный компилятор, поддерживающий С99, и посмотри, что он скажет на твой говнокод :)

     
  • 2.39, dq0s4y71 (??), 15:31, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Таки в gzip'e скорее всего была ошибка

    Да. Оптимизатор только изменяет вероятность её срабатывания :)

     

  • 1.19, Аноним (-), 08:16, 11/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как в pigz…
     
     
  • 2.22, Аноним (-), 12:19, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как
    > в pigz…

    Чо, терабайт порева нечем по-шустрому заархивить, пока мамка не увидала и ремня не всыпала?

     
     
  • 3.28, Аноним (-), 14:39, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чо, терабайт порева нечем по-шустрому заархивить, пока мамка не увидала и ремня не всыпала?

    Считай, что так. Ты же все равно не поверишь, что на компе можно хранить что-то еще, кроме порева.

     
  • 2.24, pavlinux (ok), 12:28, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как
    > в pigz…

    А ты в курсе, что не все алгоритмы позволяют себя распараллелить?
    И уж тем более знаешь, что добавление одного ядра добавляет к производительности
    всего 22%, а не 100. (и то, это в теории) Удвоение достигается где-то около 32 ядер.
    Отседа следует, что существует такой макс. размер файла, который полюбасу обработается
    быстрее линейно, чем с динамическим распарралеливанием.

    У меня lzma даёт профит, на 4-х ядрах, только при размере сжимаемого файл от 70 мегов.

     
     
  • 3.26, Аноним (-), 12:59, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Может не стоит так троллить
     
     
  • 4.31, Аноним (-), 14:43, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Может не стоит так троллить

    Да нет, он все правильно сказал. Составление словаря проще делать на одном ядре. А уже потом можно побить данные по чанкам и раскидывать их по ядрам.

     
  • 4.42, Аноним (-), 20:49, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не "не позволяют", а "программисты ниасилили"

    О, у нас тут образец "я видел программы, которые умеют параллельную обработку, значит я знаю, как они работают. Все слушайте меня!"

     
  • 4.46, pavlinux (ok), 21:56, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>А ты в курсе, что не все алгоритмы позволяют себя распараллелить?
    > не "не позволяют", а "программисты ниасилили"

    Ну исполни параллельно нахождение корней полинома 5-ой степени.

     
  • 3.49, Аноним (-), 02:11, 12/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    4 ядра, текстовый файл 283 МБ

    time gzip -c l0611000.log > gzip.gz

    real    0m2.452s
    user    0m2.380s
    sys     0m0.064s


    time pigz -c l0611000.log > pigz.gz

    real    0m0.858s
    user    0m2.948s
    sys     0m0.140s

    и результат

    4112090 gzip.gz
    4192434 pigz.gz
    283379154 l0611000.log

    В ТРЖИ раза (ну почти), получается у меня 48 ядер?

     
     
  • 4.50, Аноним (-), 02:25, 12/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А теперь повтори для файла размером ~1 Мб. Ke-ke-ke.
     
  • 4.52, Аноним (-), 05:25, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    lz4 быстрее
     
     
  • 5.57, pavlinux (ok), 20:30, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > lz4 быстрее

    Неа, правда данные из /dev/urandom (но это похоже на видео)



    16M:
    PIGZ: 0.65 2.33 0.09
    LZ4:  1.46 1.39 0.06

    32M:
    PIGZ: 1.09 2.38 0.11
    LZ4:  2.61 2.49 0.10

    64M:
    PIGZ: 1.25 4.60 0.28
    LZ4:  5.15 4.96 0.18

    128M:
    PIGZ: 2.24 8.34 0.41
    LZ4: 10.20 9.82 0.35

    256M:
    PIGZ: 4.08 15.40 0.64
    LZ4: 20.41 19.67 0.67



     
  • 4.55, pavlinux (ok), 18:48, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    user    0m2.380s
    user    0m2.948s

    второй раз тормознее, аж на 0.6 сек!

     
  • 4.56, pavlinux (ok), 20:01, 15/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В ТРЖИ раза (ну почти), получается у меня 48 ядер?

    Да, ты обогнал скорость света.

    Смотрите как LZMA процессор утюжит! :)



    1M:
    PIGZ: 0.07 0.14 0.01
    GZIP: 0.13 0.12 0.00
    LZMA: 0.79 0.66 0.12

    2M:
    PIGZ: 0.07 0.19 0.01
    GZIP: 0.27 0.25 0.01
    LZMA: 0.94 0.84 0.09

    4M:
    PIGZ: 0.12 0.30 0.02
    GZIP: 0.20 0.20 0.00
    LZMA: 1.74 1.60 0.13

    8M:
    PIGZ: 0.19 0.66 0.03
    GZIP: 0.41 0.39 0.01
    LZMA: 3.65 3.46 0.17

    16M:
    PIGZ: 0.36 1.30 0.07
    GZIP: 0.82 0.79 0.02
    LZMA: 8.18 7.85 0.29

    32M:
    PIGZ: 0.69 2.55 0.14
    GZIP: 1.64 1.57 0.06
    LZMA: 19.61 18.93 0.62

    64M:
    PIGZ: 1.25 4.67 0.22
    GZIP: 3.33 3.20 0.10
    LZMA: 51.77 50.36 1.19

    128M:
    PIGZ: 2.51 8.28 0.40
    GZIP: 6.58 6.34 0.21
    LZMA: 124.39 122.22 1.62

    256M:
    PIGZ: 4.19 15.47 0.74
    GZIP: 13.25 12.74 0.44
    LZMA: 266.72 263.13 2.38



     
  • 2.33, Аноним (-), 14:46, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как в pigz…

    У pigz, afaik, немного другая ниша - работа с довольно большими файлами (например, образами блочных устройств). Как тут верно подметили, распараллеливание эффективно только на больших файлах.

     

  • 1.20, Андрей (??), 09:06, 11/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а что за новое слово "перетирания"
    ... я спокойно отношусь к жаргону и шуткам, но только если однозначно ясен смысл, а тут можно только из контекста догадаться что это значит
     
     
  • 2.25, pavel_simple (ok), 12:50, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >  а что за новое слово "перетирания"
    >  ... я спокойно отношусь к жаргону и шуткам, но только если
    > однозначно ясен смысл, а тут можно только из контекста догадаться что
    > это значит

    пере (ибо много) тирания... ну ты понил.

     
  • 2.29, Аноним (-), 14:40, 11/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а тут можно только из контекста догадаться что это значит
    > перетирания

    Очевидно, для перетираемого файла - ничего хорошего.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру