Представлен (http://savannah.gnu.org/forum/forum.php?forum_id=7623) релиз популярной программы сжатия Gzip 1.6 (http://www.gnu.org/software/gzip/), в котором внесено 35 изменений. Наиболее заметным новшеством является реализация опции "--keep" ("-k"), при указании которой при сжатии и распаковке сохраняются исходные файлы, по аналогии с реализацией данной опции в xz, lzip и bzip2. Работа утилиты zmore приближена к more. Кроме того исправлена интересная ошибка, проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформах в восприятии интерактивного ответа "n" как "y" при обработке запроса перетирания существующего файла.URL: http://savannah.gnu.org/forum/forum.php?forum_id=7623
Новость: http://www.opennet.me/opennews/art.shtml?num=37143
> интересная ошибка, проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформах в восприятии интерактивного ответа "n" как "y" при обработке запроса перетирания существующего файла.Это круто. Такое специально трудно сделать, если вообще возможно.
> проявляющаяся при определённом сочетании опций оптимизации компилятора на некоторых платформахCompiling with -O2 ... can be seen in Arch Linux and Fedora 18 x86_64 builds
Ну тогда все ок. Юзерам арча, федоры и убунты такие шутки уже привычны.
где ты увидел слово убунту?
Подобный баг вполне вписывается в ее фирменный стиль :)
> где ты увидел слово убунту?Когда я говорю программе "не затирай этот файл", а она все равно затирает - как еще это назвать, если не убунту?
> -O2
> x86_64А это точно баг gzip, а не компилятора?
> А это точно баг gzip, а не компилятора?Оба виноваты.
> Это круто. Такое специально трудно сделать, если вообще возможно.Услужливый оптимизатор кода всегда поможет вам принять правильное решение. Соптимизировав заодно и занимаемое всяким крапом дисковое пространство :)
> крапомОпять ты со своими баззвордами?
> реализация опции "--keep"Вах, всего-то джвадцать лет понадобилось!
Он уже может в поточную архивацию?
> Он уже может в поточную архивацию?Здрассте! А в tar-е он как по-твоему используется?..
pv </dev/zero |gzip >/dev/null
> pv </dev/zeroЕсть подозрение, что pv не сможет корректно оценить размер входного файла. Как минимум по двум причинам.
Это не мешает pv работать. Он даже бегунок покажет, снующий туда-сюда.
>> pv </dev/zero
> Есть подозрение, что pv не сможет корректно оценить размерЯ вполне понимаю ваш офтопичный наброс, и, да, я в курсе, и, да, корректнее, в контексте демонстрации работоспособности gzip в конвейере, было поставить pv после gzip. </было бы, о чём говорить>
> оставить pv после gzip.А что, в этом случае pv сможет правильно оценить размер входного файла?
>> оставить pv после gzip.
> А что, в этом случае pv сможет правильно оценить размер входного файла?Я т-те второй раз внимательно повторяю: я в курсе. Без размера он показывает скорость и наличие движения вообще. И это его [другой, да??] штатный режим работы. Не возбуждайся так на размер /dev/zro, прими холодный душ.
> Не возбуждайся так на размер /dev/zroСложно не возбуждаться. Ведь такой... огромный.
> Он уже может в поточную архивацию?Вообще-то да. И уже давно.
Таки в gzip'e скорее всего была ошибка: You are correct. More searching shows yesno declared as returning bool in one place and int in the other.
> Таки в gzip'e скорее всего была ошибка: You are correct.
> More searching shows yesno declared as returning bool in one place
> and int in the other.Ваще-то по стандарту, компулятор С обязан правильно обрабатывать неявные преобразования типов. Для С++ - это бага, для С - фича. :)
> Ваще-то по стандарту, компулятор С обязан правильно обрабатывать неявные преобразования типов.А предупреждения в таких случаях писать он случайно не обязан?
не обязан. хотя, по доброте душевной, обычно всё таки пишет.
Компилятор - нет. Потому что в данном случае у одной и той же функции разные прототипы, и компилятор об этом не знает. А вот линковщик мог бы и выдать предупреждение. Но я не уверен, должен ли знать сишный (не С++) линковщик что-то о типах и что именно.
Здесь дело не в неявном преобразовании типов, а в том, что в одном месте yesno() описана как возвращающая bool (1 байт), а в другом - как int (4 байта). Когда yesno() возвращает, допустим, false, она кладёт 0 в %al. При этом в старших байтах %eax может на тот момент содержаться всё что угодно. А вызывающая функция думает, что yesno() возвращает int и делает test %eax, %eax, и, естественно, мусор содержащийся в старших байтах, даёт ненулевой результат. Я так ДУМАЮ :)
В С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.
Нет, и ваша цитата, вообще-то, это подтверждает :)Ещё можете для общего развития сравнить выдачу от printf("%u\n", sizeof(_Bool)); и printf("%u\n", sizeof(unsigned int));
> Нет, и ваша цитата, вообще-то, это подтверждает :)Уверен, что читать умеешь?
"_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
> Уверен, что читать умеешь?
> "_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?
Ах да, в догонку _Бууль может быть как 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".
Ты догадался, что у компиляторов, не поддерживающих _Bool, _Bool может быть вообще чем угодно? Ты умница! :)А теперь поставь нормальный компилятор, поддерживающий С99, и посмотри, что он скажет на твой говнокод :)
> Таки в gzip'e скорее всего была ошибкаДа. Оптимизатор только изменяет вероятность её срабатывания :)
Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как в pigz…
> Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как
> в pigz…Чо, терабайт порева нечем по-шустрому заархивить, пока мамка не увидала и ремня не всыпала?
> Чо, терабайт порева нечем по-шустрому заархивить, пока мамка не увидала и ремня не всыпала?Считай, что так. Ты же все равно не поверишь, что на компе можно хранить что-то еще, кроме порева.
> Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как
> в pigz…А ты в курсе, что не все алгоритмы позволяют себя распараллелить?
И уж тем более знаешь, что добавление одного ядра добавляет к производительности
всего 22%, а не 100. (и то, это в теории) Удвоение достигается где-то около 32 ядер.
Отседа следует, что существует такой макс. размер файла, который полюбасу обработается
быстрее линейно, чем с динамическим распарралеливанием.У меня lzma даёт профит, на 4-х ядрах, только при размере сжимаемого файл от 70 мегов.
Может не стоит так троллить
> Может не стоит так троллитьДа нет, он все правильно сказал. Составление словаря проще делать на одном ядре. А уже потом можно побить данные по чанкам и раскидывать их по ядрам.
> не "не позволяют", а "программисты ниасилили"О, у нас тут образец "я видел программы, которые умеют параллельную обработку, значит я знаю, как они работают. Все слушайте меня!"
>>А ты в курсе, что не все алгоритмы позволяют себя распараллелить?
> не "не позволяют", а "программисты ниасилили"Ну исполни параллельно нахождение корней полинома 5-ой степени.
4 ядра, текстовый файл 283 МБtime gzip -c l0611000.log > gzip.gz
real 0m2.452s
user 0m2.380s
sys 0m0.064s
time pigz -c l0611000.log > pigz.gzreal 0m0.858s
user 0m2.948s
sys 0m0.140sи результат
4112090 gzip.gz
4192434 pigz.gz
283379154 l0611000.logВ ТРЖИ раза (ну почти), получается у меня 48 ядер?
А теперь повтори для файла размером ~1 Мб. Ke-ke-ke.
lz4 быстрее
> lz4 быстрееНеа, правда данные из /dev/urandom (но это похоже на видео)
16M:
PIGZ: 0.65 2.33 0.09
LZ4: 1.46 1.39 0.0632M:
PIGZ: 1.09 2.38 0.11
LZ4: 2.61 2.49 0.1064M:
PIGZ: 1.25 4.60 0.28
LZ4: 5.15 4.96 0.18128M:
PIGZ: 2.24 8.34 0.41
LZ4: 10.20 9.82 0.35256M:
PIGZ: 4.08 15.40 0.64
LZ4: 20.41 19.67 0.67
user 0m2.380s
user 0m2.948sвторой раз тормознее, аж на 0.6 сек!
> В ТРЖИ раза (ну почти), получается у меня 48 ядер?Да, ты обогнал скорость света.
Смотрите как LZMA процессор утюжит! :)
1M:
PIGZ: 0.07 0.14 0.01
GZIP: 0.13 0.12 0.00
LZMA: 0.79 0.66 0.122M:
PIGZ: 0.07 0.19 0.01
GZIP: 0.27 0.25 0.01
LZMA: 0.94 0.84 0.094M:
PIGZ: 0.12 0.30 0.02
GZIP: 0.20 0.20 0.00
LZMA: 1.74 1.60 0.138M:
PIGZ: 0.19 0.66 0.03
GZIP: 0.41 0.39 0.01
LZMA: 3.65 3.46 0.1716M:
PIGZ: 0.36 1.30 0.07
GZIP: 0.82 0.79 0.02
LZMA: 8.18 7.85 0.2932M:
PIGZ: 0.69 2.55 0.14
GZIP: 1.64 1.57 0.06
LZMA: 19.61 18.93 0.6264M:
PIGZ: 1.25 4.67 0.22
GZIP: 3.33 3.20 0.10
LZMA: 51.77 50.36 1.19128M:
PIGZ: 2.51 8.28 0.40
GZIP: 6.58 6.34 0.21
LZMA: 124.39 122.22 1.62256M:
PIGZ: 4.19 15.47 0.74
GZIP: 13.25 12.74 0.44
LZMA: 266.72 263.13 2.38
> Интересно, сколько ещё лет пройдёт пока запилят задействование всех ядер процессора, как в pigz…У pigz, afaik, немного другая ниша - работа с довольно большими файлами (например, образами блочных устройств). Как тут верно подметили, распараллеливание эффективно только на больших файлах.
а что за новое слово "перетирания"
... я спокойно отношусь к жаргону и шуткам, но только если однозначно ясен смысл, а тут можно только из контекста догадаться что это значит
> а что за новое слово "перетирания"
> ... я спокойно отношусь к жаргону и шуткам, но только если
> однозначно ясен смысл, а тут можно только из контекста догадаться что
> это значитпере (ибо много) тирания... ну ты понил.
> а тут можно только из контекста догадаться что это значит
> перетиранияОчевидно, для перетираемого файла - ничего хорошего.