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 +/– |
Ну тогда все ок. Юзерам арча, федоры и убунты такие шутки уже привычны.
| |
|
|
5.34, Аноним (-), 14:47, 11/06/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> где ты увидел слово убунту?
Когда я говорю программе "не затирай этот файл", а она все равно затирает - как еще это назвать, если не убунту?
| |
|
|
|
2.13, Аноним (-), 04:35, 11/06/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Это круто. Такое специально трудно сделать, если вообще возможно.
Услужливый оптимизатор кода всегда поможет вам принять правильное решение. Соптимизировав заодно и занимаемое всяким крапом дисковое пространство :)
| |
|
|
|
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, прими холодный душ.
| |
|
|
|
|
|
|
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 [^] [^^] [^^^] [ответить]
| +/– |
> Ваще-то по стандарту, компулятор С обязан правильно обрабатывать неявные преобразования типов.
А предупреждения в таких случаях писать он случайно не обязан?
| |
|
|
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 мегов.
| |
|
|
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 ядер?
| |
|
|
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.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 [^] [^^] [^^^] [ответить]
| +/– |
> а тут можно только из контекста догадаться что это значит
> перетирания
Очевидно, для перетираемого файла - ничего хорошего.
| |
|
|