The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход/выход
слежка
RSS


"В ядре Linux оптимизирована реализация алгоритма CRC32C"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от opennews (??), 28-Окт-24, 16:11 
Для включения в состав будущей ветки ядра Linux 6.13 предложен патч с переработанной реализацией алгоритма нахождения контрольной суммы CRC32C. Код реализации CRC32C уменьшен примерно в 10 раз  (с 4546 до 418 байт). При выключенной защите retpoline от атак класса Spectre прирост  производительности при использовании новой реализации достигает 11.8% на процессорах AMD Zen 2, 6.4% - Intel Emerald Rapids и 4.8% Intel Haswell. При включении retpoline прирост производительности более заметен и достигает 66.8%  на системах с процессорами Intel Emerald Rapids,  35.0% - Intel Haswell и 29.5% - AMD Zen 2...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=62123

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "В ядре Linux ускорен алгоритм CRC32C"  +14 +/–
Сообщение от Аноним (1), 28-Окт-24, 16:11 
> Код реализации CRC32C уменьшен примерно в 10 раз (с 4546 до 418 байт).

Наконец-то правильный академический код добрался до Linux.

Ответить | Правка | Наверх | Cообщить модератору

2. "В ядре Linux ускорен алгоритм CRC32C"  +12 +/–
Сообщение от swarus (ok), 28-Окт-24, 16:15 
на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее
Ответить | Правка | Наверх | Cообщить модератору

4. "В ядре Linux ускорен алгоритм CRC32C"  +3 +/–
Сообщение от нах. (?), 28-Окт-24, 16:17 
Не исключено что на могущих, но имеющих чуть меньшую глубину очереди - тоже быстрее.

Но мерять вам интел запретил.

Ответить | Правка | Наверх | Cообщить модератору

31. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Анонимemail (31), 28-Окт-24, 17:09 
> "Но мерять вам интел запретил."

Интел выкладывает весь мёд для повышения капитализации перед продажей Квалкому.

Ответить | Правка | Наверх | Cообщить модератору

101. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (101), 29-Окт-24, 05:39 
https://3dnews.ru/1101603/
Ответить | Правка | Наверх | Cообщить модератору

106. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (106), 29-Окт-24, 08:52 
Обратите внимание на дату публикации. Это показатели задолго до публичного скандала с саморазлагающимися процессорами последних поколений.
Ответить | Правка | Наверх | Cообщить модератору

111. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (101), 29-Окт-24, 12:30 
>процессорами последних поколений

По факту, проблемы были замечены у k-процессоров 13 и 14-го поколения.
https://3dnews.ru/1112050/

Ответить | Правка | Наверх | Cообщить модератору

173. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 21:17 
>>процессорами последних поколений
> По факту, проблемы были замечены у k-процессоров 13 и 14-го поколения.
> https://3dnews.ru/1112050/

При том если это все почитать детально - там просто парад бракоделия. Видно что интел выжимает свой кремний в режиме овердрафта. И перестарался настолько что за полгода стало выгорать.

Ответить | Правка | Наверх | Cообщить модератору

179. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (179), 29-Окт-24, 22:15 
Да. Но публичный скандал разразился после. Примерно в июле текущего года.

До этого были отдельные разрозненные сообщения что «как–то оно слишком плохо всё, думал лучше будет». Intel удавалось морозиться, кормить отдельных пользователей завтраками (у п*арщиков это называется crisis–management) и обещаниями исправления микрокода. После того как замалчивать проблему стало более невозможно, всё покатилось как снежный ком — протраченный контракт на чипы для PS6, оглушительное падение стоимости акций, массовые увольнения, сброс активов и сворачивания проектов.

Так что трясти какими–то там показателями за прошлый год, как минимум, странно.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

182. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (182), 30-Окт-24, 02:59 
А теперь подъехали тесты последнего их поколения которое на равные с 11...вот незадача то
Ответить | Правка | Наверх | Cообщить модератору

184. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (182), 30-Окт-24, 03:02 
Зато не гниёт...и наверное без дыр)
Ответить | Правка | Наверх | Cообщить модератору

46. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 17:51 
> Не исключено что на могущих, но имеющих чуть меньшую глубину очереди -
> тоже быстрее.

Вон то должно быть так же или быстрее на почти всем отдаленно напоминающим современный проц, чуть ли не эпохи первопня, уже умевшего спекулятивщину.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

23. "В ядре Linux ускорен алгоритм CRC32C"  –2 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:01 
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее

Вот и сидите на старых процессорах со старым ядром.
Хлам не должен замедлять прогресс, особенно когда речь идет о +66.8% прироста.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

90. "В ядре Linux ускорен алгоритм CRC32C"  –2 +/–
Сообщение от scriptkiddis (?), 28-Окт-24, 23:33 
Только в твоем воображении.
Ответить | Правка | Наверх | Cообщить модератору

137. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 17:37 
> особенно когда речь идет о +66.8% прироста.

Да, но - прироста _только_ в расчёте CRC32 сумм. ... А теперь ты берёшь и смотришь _где_оно_ещё_осталось_?!?! ;-)
И понимаешь что это громогласный анонс об установке на паравоз новейшей карбид-вольфрамовой турбины 8-о Повышает экономичность паровоза серии "овца" аж на "+66.8%"!!!
Ну что - "запануемо"?!? ;-)

PS: Тут вон - всё что меньше sha256 списывают ...

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

144. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (144), 29-Окт-24, 18:21 
> А теперь ты берёшь и смотришь _где_оно_ещё_осталось_?!?!

Во всех современных файловых системах, например.

> Тут вон - всё что меньше sha256 списывают ...

Слышал звон, да не знаешь где он. SHA1 спысывают *для задач криптографии*.

Ответить | Правка | Наверх | Cообщить модератору

151. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 19:15 
>> особенно когда речь идет о +66.8% прироста.
> Да, но - прироста _только_ в расчёте CRC32 сумм. ... А теперь
> ты берёшь и смотришь _где_оно_ещё_осталось_?!?! ;-)

В чертовой куче протоколов, форматов файлов, ФС и проч - как чексумы для обнаружения разрушения данных.

> PS: Тут вон - всё что меньше sha256 списывают ...

Вот ща буду на уберскоростном SSD считать sha256 для проверки целостности блоков файлов в ФС. И все упрется - в счет SHA256. Оно мне такое надо?

Как криптографически стойкое CRC32 не котировалось никогда - элементарно подгоняется до оригинала целенаправленной заменой 32 бит в другом месте потока. Но вероятность самопроизвольного возникновения такой замены от разрушения данных, при редких разрушениях - скромная. С другой стороны всего 4 байта внагрузку, относительно шустро считается и хорощие свойства детекта битовых ошибок.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

172. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 21:05 
А то, для чего ты хочешь его пользовать ... так уже миллион лет есть да хоть blacke* ! , раз уж ты любитель прогресса, то будь последователен, как минимум! :)
Основная фишка CRC32 - что оно реализуется даже на контроллере стиральной машинки :) В линуксе оно быть должно, но пользовать его нынче ... :)
Ответить | Правка | Наверх | Cообщить модератору

175. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 21:26 
> А то, для чего ты хочешь его пользовать ... так уже миллион
> лет есть да хоть blacke* !

Чего есть? Если это чукотское название Blake2 и проч, оно производительное только по меркам криптографических чексум типа SHA256, где и правда оно дает ему мастеркласс. Но CRC32 куда быстрее считается. Криптографии надо достаточно раундов для сильной диффузии, чтобы нельзя было инверсию сделать, упрощенными вычислениями. CRC32 не имеет таких ограничений, и - вот - легко костылится в старое значение 4 байтами "поправки".

> , раз уж ты любитель прогресса, то будь последователен, как минимум! :)

Как максимум XXHASH какой сравнивать можно. И то основной аргумент за него - 64 бита. Так что вероятность ложняка на битых данных - ниже. Но он тоже не является криптографически стойким, и таки - медленнее CRC32 (в среднем считается 1.4x slower примерно).

> Основная фишка CRC32 - что оно реализуется даже на контроллере стиральной машинки

Основная фишка CRC32 - что он достаточно быстрый с 1 стороны и неплохо ловит определенные классы ошибок с другой. И никаких особых прорывов в теориях CS на тему hamming distance, полиномов и тому подобного - с тех пор не происходило, внезапно.

Так что это все ваши личные бредни. А CRC32 сейчас довольно много где в ходу до сих пор. По моему зипархивы до сих пор его по дефолту юзают для проверки целостности файлов.

Ответить | Правка | Наверх | Cообщить модератору

36. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:19 
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее

Это каких? 486 чтоли? Они пропатчили x86 реализацию, и если x86 такое не умеет - это что? У вас x86 древнее Haswell?

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

48. "В ядре Linux ускорен алгоритм CRC32C"  –2 +/–
Сообщение от Аноним (48), 28-Окт-24, 17:53 
Haswell - это не x86. Это haswell.
Ответить | Правка | Наверх | Cообщить модератору

57. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 18:10 
> Haswell - это не x86. Это haswell.

Haswell это микроархитектура одного из x86(-64) процессоров.

Ответить | Правка | Наверх | Cообщить модератору

92. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от _kp (ok), 28-Окт-24, 23:51 
Ну, у меня ноут на i5-3210.
Конечно не основной, но для 3д печати, интернета и ютубов в гараже - и он годен! На последнем Ubuntu, KDE, и не жужжит.

А производительность, понятие относительное. Вот, Windows планшеты совсем недавно этого старичка по производительности обошли, а Андроид планшеты до сих пор клячи, и ничего, народ радуется флагманам.
А по сравнению с упомянутым i5, и Haswell конфетка.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

94. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (-), 29-Окт-24, 03:08 
> Ну, у меня ноут на i5-3210.

Я думаю что OoO механика уже и на нем была - в примерно том же виде. Это знание появилось в середине нулевых, когда до народа стало доходить что порой излишний unroll даже все портит, вымывая кеш жирным кодом лишний раз и ничего нового не давая т.к. команду бранча параллельно обсчитали и оверхеда и так особо не было, оно так только для in-order без спекулятивщины и предсказаний. А в x86 это все уже есть очень давно. Ну вот кроме некоторых атомов разве что.

Ответить | Правка | Наверх | Cообщить модератору

96. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 03:19 
Это не тоже самое но, для понимания разницы между процессорами и такое есть. Чтобы увеличить в браузере с прокруткой, нажать на картинку в браузере, в верхнем правом углу закрыть картинку X, только тогда появляется увеличенная картинка с прокруткой - так в Лисе. https://ibb.co/GdfvWHF
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

97. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 04:02 
У современных процессов те что после примерно 2020 разработанных это будет или тысячи МиБ/сек. или десятки тысяч точно не помню.
Ответить | Правка | Наверх | Cообщить модератору

40. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от Аноним (40), 28-Окт-24, 17:31 
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее

В случае x86 это не старый а очень старый.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

67. "В ядре Linux ускорен алгоритм CRC32C"  +3 +/–
Сообщение от старый процессор (?), 28-Окт-24, 19:41 
Те кто сидят на старых процессорах за производительностью не гонятся. И за новыми не lts ядрами тоже, пройдет ещё 15 лет прежде чем к ним придет этот патч.

Нет никакой логики тормозить новое ради ускорения старого.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

112. "В ядре Linux ускорен алгоритм CRC32C"  +1 +/–
Сообщение от n00by (ok), 29-Окт-24, 13:06 
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее

То есть процессор неспособен заблаговременно выбрать адрес из таблицы переходов, но исполняться волшебным образом будет быстрее. И это без учёта загрязнения кеша и задержек  из-за чтения ОЗУ.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

129. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (129), 29-Окт-24, 16:15 
Чего там на страрых? Cortex-A53 же in-order. И их ещё полно, где используется. И в сетевых девайсах тоже, ага, CRC32.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

103. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от mos87 (ok), 29-Окт-24, 07:27 
Теперь Linux станет такой же ненужной поделкой, как академические ОС на грантах?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

115. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (115), 29-Окт-24, 13:39 
Теперь люди будут переходить на академическую ОС и закапывать это ядро.
Ответить | Правка | Наверх | Cообщить модератору

130. "В ядре Linux ускорен алгоритм CRC32C"  +/–
Сообщение от Аноним (129), 29-Окт-24, 16:17 
В параллельной академической вселенной.
Ответить | Правка | Наверх | Cообщить модератору

3. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –4 +/–
Сообщение от нах. (?), 28-Окт-24, 16:16 
> на процессорах AMD Zen 2, 6.4% - Intel Emerald Rapids и 4.8%
> Intel Haswell

а у кого процессор немодный - идет найух.

Не зря Линукса в консультанты интела взяли. Вот, работает человек над повышением продаж.

P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах?

Ответить | Правка | Наверх | Cообщить модератору

5. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (5), 28-Окт-24, 16:21 
Этим процам больше 5 лет
Ответить | Правка | Наверх | Cообщить модератору

15. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +3 +/–
Сообщение от Игорь (??), 28-Окт-24, 16:51 
> Этим процам больше 5 лет

Ага, особенно Intel Emerald Rapids, которые вышли в декабре 2023г

Ответить | Правка | Наверх | Cообщить модератору

42. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 17:38 
> Ага, особенно Intel Emerald Rapids, которые вышли в декабре 2023г

Но профит есть и на Haswell который весьма немолодая штука уже. И вообще это оптимизация родом из середины нулевых, а то что всякие похонахи не отпустили тормоз с еще тех пор... а вот эти - уже отпустили! :)

Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Oe (?), 28-Окт-24, 16:33 
А зачем тебе CRC32C на обогревателе со встроенной функцией компьютера?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

9. Скрыто модератором  +3 +/–
Сообщение от Someone (??), 28-Окт-24, 16:38 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

25. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –6 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:04 
AMD Zen 2 вышли в 2019 году.
Сейчас их даже бомж в качестве подарка не примет!

> P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах?

Просто никому нет дела до всякого старья.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

37. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +12 +/–
Сообщение от Abra (?), 28-Окт-24, 17:22 
подари мне, пожалуйста?
Ответить | Правка | Наверх | Cообщить модератору

41. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 17:37 
> подари мне, пожалуйста?

С радость, но уже остались только Zen 4 и Zen 5.
Придется подождать пару лет.

Ответить | Правка | Наверх | Cообщить модератору

86. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от COBA (?), 28-Окт-24, 21:54 
Куда слать?
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

116. Скрыто модератором  +/–
Сообщение от Аноним (115), 29-Окт-24, 13:41 
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

118. Скрыто модератором  +/–
Сообщение от Аноним (-), 29-Окт-24, 13:47 
Ответить | Правка | Наверх | Cообщить модератору

119. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 15:09 
У меня zen2 работают и менять я их не собираюсь, ибо тот же zen2 не сильно лучше, и в целом на АМ4 платформе разница такая что смысла особо нет менять проц если он у тебя уже есть.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

133. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –1 +/–
Сообщение от Имя (?), 29-Окт-24, 17:29 
А что не так с zen2 ? Смотрю на сравнительную табличку, и каких-то шокирующих отличий не наблюдаю. https://en.wikipedia.org/wiki/Zen_(microarchitecture)
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

32. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –2 +/–
Сообщение от Аноним (32), 28-Окт-24, 17:11 
> я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах?

Как будто другие процессоры кому-то интересны в бизнесе. IBM со своими сам справится, на китайские лонгсуны всем просто плевать (кроме китая, на который всем тоже плевать), а больше ничего особо так и нет. Огороженный Apple silicon? Так на них линукс ставят только энтузиасты, бизнес макось и так устраивает. Так что всё правильно сделали, неча усилия распылять. Кому очень надо — patches are welcome (если это не байКал хехехе).

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

38. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от нах. (?), 28-Окт-24, 17:27 
> Как будто другие процессоры кому-то интересны в бизнесе.

я и говорю - кто не успел купить последнего поколения - тот л-х педальный, и должен, собака, страдать!

> Кому очень надо — patches are welcome

не, это так не работает. Продажи интел не должны страдать от твоих косоруких патчей!

Иди вон колор на колор поисправляй для начала.

Ответить | Правка | Наверх | Cообщить модератору

43. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 17:38 
> я и говорю - кто не успел купить последнего поколения - тот л-х педальный, и должен, собака, страдать!

А что посидеть на старом ядре уже нельзя? Ну типа корона отвалится?
На крайняк есть гентушники, они только рады ядро пересобирать.

> Иди вон колор на колор поисправляй для начала.

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

Надо провести серию экспериментов - выкидывать по 1 или пачкой, со скандалом или по тихому, говорить прямо "вы №№№№" или "ну вы же понимаете ситуацию"...
В общем простора для исследований просто море.

Ответить | Правка | Наверх | Cообщить модератору

45. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –1 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:50 
> А что посидеть на старом ядре уже нельзя? Ну типа корона отвалится?
> На крайняк есть гентушники, они только рады ядро пересобирать.

Вы издеваетесь чтоли? Вон то дает эффект на почти всех более-менее не ископаемых процах умеющих OoO. Модуль для crc-intel патчили - так что всяким ARM и прочим RISCV где in-order еще бывает местами актуально ради мелкости ядер - это вообше пофиг.

>> Иди вон колор на колор поисправляй для начала.
> Не, сейчас гораздо популярнее проверять цвет пачпорта.
> Вот ссаными тряпками выгнали 11 штук и... ядро ускорилось!

Торвальдс очень понятно объяснил кой-кому что за ними накопился нехилый техдолг.

Ответить | Правка | Наверх | Cообщить модератору

71. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от нах. (?), 28-Окт-24, 19:59 
> А что посидеть на старом ядре уже нельзя?

ну типа без исправлений багов? Можно, разрешаю.

> В общем простора для исследований просто море.

угу, а через недельку расстрелять всех рыжих. И, пожалуй, велосипедистов.

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

  

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

39. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (40), 28-Окт-24, 17:29 
> а у кого процессор немодный - идет найух.

Что за проц такой?То что столь жесткий unroll циклов не имеет особого смысла на процах с OoO известно с середины нулевых, наверное. Почему до вон тех дошло только в 2024 - загадка, но хорошо что дошло, минус 3 с фигом кило мусора без каких либо потерь и даже вот с профитом.

> Не зря Линукса в консультанты интела взяли. Вот, работает человек над повышением продаж.

Повышением продаж ... чего? OoO с предсказаниями появился еще в первопнях по моему.

> P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах?

На чем надо было crc32-intel тестировать? На первом пне? 486?

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

78. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (78), 28-Окт-24, 20:39 
> На чем надо было crc32-intel тестировать? На первом пне? 486?

На первых atom, они как раз без OoO. С другой стороны, они и 15 лет назад в момент своего выхода были непойми для чего созданы, учитывая, что на них тормозило абсолютно всё.

Ответить | Правка | Наверх | Cообщить модератору

81. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 20:55 
> На первых atom, они как раз без OoO. С другой стороны, они
> и 15 лет назад в момент своего выхода были непойми для
> чего созданы, учитывая, что на них тормозило абсолютно всё.

Это наверное единственные x86 которые могут быть как-то затронуты. И то - ждем когда их владельцы забенчат это. Ну, если им оно надо.

Ответить | Правка | Наверх | Cообщить модератору

138. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 17:49 
> Почему до вон тех дошло только в 2024 - загадка

Загадка?! :) Да ладно! Просто прикинь кому оно нынче надо это CRC32. Ты бы ещё на драйвер для флоппи пожаловался :)

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

153. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –1 +/–
Сообщение от Аноним (-), 29-Окт-24, 19:20 
> Загадка?! :) Да ладно! Просто прикинь кому оно нынче надо это CRC32.
> Ты бы ещё на драйвер для флоппи пожаловался :)

На минуточку дефолтовый чексум в btrfs. Обслуживающем всего-то пару миллиардов хомяков фэйсбука. Для обнаружений кривого хардвара - вполне хватает. А вы можете SHA256 считать пытаясь угнаться за энтерпрайзным SSD конечно. Или заякорить перфоманс всего IO счетом SHA256.

Ответить | Правка | Наверх | Cообщить модератору

165. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 19:56 
Согласно вот этому от самих btrfs: https://btrfs.readthedocs.io/en/latest/Checksumming.html

Digest        Cycles/4KiB    Ratio    Implementation
CRC32C        470        1.00    CPU instruction, PCL combination
BLAKE2b        14500        34    builtin, reference impl.


И если _никто_ не менял, то ... им станет лучше, да :)
Но это много говорит о людях которые не сделали единственное изменение в конфиге чтобы улучшить производительность НА ДВА ПОРЯДКА! 8-)

Ответить | Правка | Наверх | Cообщить модератору

176. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 21:37 
> Digest  Cycles/4KiB Ratio Implementation
> CRC32C  470  1.00 CPU instruction, PCL combination
> BLAKE2b  14500  34 builtin, reference impl.

О, какая милота. Гражданин раздававший мне ценные советы - наконец то сам изволил дойти до вики - и сам же донес насколько именно он БРЕД пытался мне сосватать! Поставив в 1 ряд функции с 30-кратной разницей в вычислительной сложности. Всего то ничего. Но за такой срыв покровов с самого себя все ж респекты.

> И если _никто_ не менял, то ... им станет лучше, да :)

Ну как бы эн % перфоманса никому еще не мешали. А если еще и -3.5 кило кода в вечно жиреющий от новых фич кернел - double win!

> Но это много говорит о людях которые не сделали единственное изменение в
> конфиге чтобы улучшить производительность НА ДВА ПОРЯДКА! 8-)

Не, это говорит - о вашем уровне экспертизы, как вы там советовали мне в 30 раз более тяжелую функцию как замену немодному CRC32. Эксперт, тоже мне.

Знаете чем мы отличаемся? Я в курсе что это разные уровни вычислетельной сложности и без похрда в ту вики ;)

Ответить | Правка | Наверх | Cообщить модератору

10. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (10), 28-Окт-24, 16:40 
А почему 6.13? У 6.12 уже окно закрыто?
Ответить | Правка | Наверх | Cообщить модератору

20. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (20), 28-Окт-24, 16:56 
давно, уже 6.12-rc5
Ответить | Правка | Наверх | Cообщить модератору

13. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (48), 28-Окт-24, 16:48 
>Код реализации CRC32C уменьшен примерно в 10 раз (с 4546 до 418 байт).

Там в Линуксе совсем долбанулись? Реализация любого CRC тривиальна и по памяти делается.

Ответить | Правка | Наверх | Cообщить модератору

19. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (19), 28-Окт-24, 16:54 
Оно еще и на ассемблере написано
Ответить | Правка | Наверх | Cообщить модератору

28. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (28), 28-Окт-24, 17:07 
И великолепно показывает, что даже на ассемблере можно написать какой-то "страх и ужас")
Зато как в соседней теме про tinyGO рассказывали "вы бы еще микроконтроллер на питоне писали, бубубу!", "вебассебли замедлит выполнение"..

А вот как оно вышло, Михалыч)

Ответить | Правка | Наверх | Cообщить модератору

51. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:58 
Ну так покажите ваши варианты CRC32 на питоне и игогошке которые порвут вон те? :)
Ответить | Правка | Наверх | Cообщить модератору

139. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 17:53 
Не порвут но там где CRC32 ещё применяется ... окажется что там они _тянут_ ... :)
У меня студень лет 5 назад на питоне сделал, ну да по сравнению с Си-шной тормозит, но для чего он делел оно _успевало_ :) БратЫ Ынежёнегры почесали что положено чесать, сделали смок лоад тест ... выжило 8-) Ну и забили :)
Ответить | Правка | Наверх | Cообщить модератору

140. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 17:54 
На игогошке - внезапно был быстрее :) Видимо там не ан-ролило. Теперь видимо Си-неый снова быстрее :)
Ответить | Правка | Наверх | Cообщить модератору

177. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 21:45 
> Не порвут но там где CRC32 ещё применяется ... окажется что там они _тянут_ ... :)

Тянут что? Питание из питальника? Можете посчитать blake2 для энтерпразйного SSD - посмотрим сколько проца это сожрет. Разложить btrfs на энтерпрайзный SSD - вероятно обычные будни обычного фэйсбука с его 2 млрд юзерей.

> У меня студень лет 5 назад на питоне сделал,

Тут такой уровень что даже комментировать неудобно.

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

135. Скрыто модератором  +/–
Сообщение от Имя (?), 29-Окт-24, 17:33 
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

49. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:57 
> Там в Линуксе совсем долбанулись? Реализация любого CRC тривиальна и по памяти делается.

И, конечно, ты порвешь по перфомансу хотя-бы вариант из Linux? А то когда какая-нибудь ФС на быстром SSD захочет чексумы блоков им например считать, или что там - скорости много не бывает.

В Linux был довольно навороченый вариант, с разворотами циклов от 1 до 127, джампом в нужный и .. и оказалось что нет никакого смысла гонять простыню 127 циклов когда разворот на 4 цикла дает тот же или даже более хороший результат. Получилось дохрена кода - без какого либо профита.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

54. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (48), 28-Окт-24, 18:05 
>И, конечно, ты порвешь по перфомансу хотя-бы вариант из Linux?

Нет, конечно. Если нужна супер-производительность для брутфорса, я GPU использую. Если нужна супер-производительность на CPU - то SIMD.

Ответить | Правка | Наверх | Cообщить модератору

56. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 18:09 
> Нет, конечно. Если нужна супер-производительность для брутфорса, я GPU использую.
> Если нужна супер-производительность на CPU - то SIMD.

Ух да, а теперь покажи переключения контекстов с этим всем? А 1000 раз в секунду как тебе? Обычные тики "десктопного" ядра линукс если что. Ты уверен что там оверхед от сохранений контекста не перевесит профит? :)

Ответить | Правка | Наверх | Cообщить модератору

123. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 15:45 
А как же tickless?
Ответить | Правка | Наверх | Cообщить модератору

124. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (124), 29-Окт-24, 15:55 
> А как же tickless?

Как, как... вы там бенчмаркать собрались - ненагруженную систему в вакууме чтоли? Если она не нагружена - то о чем бенч?! Ядро же не считает CRC32 чисто для прикола?! А если нагружена - так ядро нынче heavily threaded, и вообще :)

Так что размер контекста - некий аргумент. Чем он жирнее, тем хуже задачи переключать получается.

Ответить | Правка | Наверх | Cообщить модератору

145. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 18:28 
Я вам указываю что вероятно уже нет никаких 1000 переключений контекста в секунду.
А в ядре этот CRC32 вообще скорее всего для использования в дровах.
Ответить | Правка | Наверх | Cообщить модератору

155. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 19:26 
> Я вам указываю что вероятно уже нет никаких 1000 переключений контекста в секунду.

А я указываю что ядро Linux уже давно heavily threaded, даже само по себе. А также с всякими фоновыми воркерами и дефернутыми джобами. Чтобы лучше масштабироваться, шустрее работать и удобнее/проще программировать это все.

> А в ядре этот CRC32 вообще скорее всего для использования в дровах.

Дровах, всяких протоколах, чексумы ФС и проч. И это все тоже - heavily threaded нынче, если кто еще не понял. В том числе и потому что заняться счетом CRC или чем там сможет в ряде случаев _другое_ ядро нежели вон тот heavy lifting. В мире где у процов уже по 256 ядер - это аргумент.

Так что кернел не может игнорить размер контекста, большой контекст все нагибает. А сможет ли кто крутить GPU в разные стороны 1000 раз в секунду - я б вообще посмотрел на этот номер.

Ответить | Правка | Наверх | Cообщить модератору

162. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (162), 29-Окт-24, 19:48 
Crc32 or crc32c
Ответить | Правка | Наверх | Cообщить модератору

141. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 17:58 
> Получилось дохрена кода - без какого либо профита.

Ну просто на CRC32 всем ... А так то давно на всех площадках озвучивают что нынче основной метод оптимизации жто сделать так чтоб твой код влазил в кэш :)  Просто до ненужно вот только в 24 году руки дошли. Да никто и не заметит :)

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

14. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –3 +/–
Сообщение от Аноним (48), 28-Окт-24, 16:51 
>x86_64 CPUs can predict loops well, so it

is fine to just use a loop instead

То есть на пни болт положили?

Ответить | Правка | Наверх | Cообщить модератору

98. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +2 +/–
Сообщение от Аноним (98), 29-Окт-24, 05:19 
Какие, первые? Так давно уже.
А в 4м это есть из коробки.
Ответить | Правка | Наверх | Cообщить модератору

125. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (124), 29-Окт-24, 15:56 
> Какие, первые? Так давно уже.
> А в 4м это есть из коробки.

Да и 4-е лучше в эту коробку - вернуть уже, или как брелок использовать. Жрет много, считает мало, управление питанием никакое. Это отопитель воздуха со встроенной функцией счета был.

Ответить | Правка | Наверх | Cообщить модератору

17. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (48), 28-Окт-24, 16:52 
Также удивляет то, что написано на асме, вместо сишки. Что там такого, что Clang на -O3 не сможет выоптимизировать?
Ответить | Правка | Наверх | Cообщить модератору

52. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 18:02 
> Также удивляет то, что написано на асме, вместо сишки. Что там такого,
> что Clang на -O3 не сможет выоптимизировать?

Явный unroll - при том в изначальном варианте дико оверинженернутый, с unroll от 1 до 127 и вычисляемым джампом в нужный из. И тут вдруг оказалось что этот джамп + такие простыни не являются каким-то улучшением. И это известно наверное уже около 15-20 лет так то.

Unroll может как-то помочь на МК и малохольных ядрах типа (low end) in-order апликушников на ARM/RISCV. На всем остальном польза от него весьма варьируется и даже может быть вред.

Ответить | Правка | Наверх | Cообщить модератору

142. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 18:15 
> Явный unroll - при том в изначальном варианте дико оверинженернутый

Это для нонешних хм... программерофф он "дико оверинженернутый" :)
В те ремена это был стандартный метод оптимизации, это любой джун с закрытими глазами делел :) Ну можен не на 128 веток, но и не все ведро писали :)

Ответить | Правка | Наверх | Cообщить модератору

147. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 18:35 
> Это для нонешних хм... программерофф он "дико оверинженернутый" :)

Ну как старые програмизды написяли мы уже видим)
Проблема же не в оверинжениринге, а в том что это лабуда еще и тромознутая.

> В те ремена это был стандартный метод оптимизации, это любой джун с закрытими глазами делел :)

С таким же "качеством" или получше?

> Ну можен не на 128 веток, но и не все ведро писали :)

И слава богу)


Ответить | Правка | Наверх | Cообщить модератору

159. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 19:33 
> Ну как старые програмизды написяли мы уже видим)
> Проблема же не в оверинжениринге, а в том что это лабуда еще
> и тромознутая.

Такая оптимизация актуальна только для in-order CPU без спекулятивщины, и даже там вымывание кеша такой простыней может внести коррективы. Ибо если мы 100500 циклов ждали оперативу, дальнейшее улучшение счета на 5% мало что меняет. А чем жирнее кот тем менее вероятно что всегда будет только cache hit без ожидания RAM фиг знает сколько (DRAM даже от in-order ядер сильно отстает сейчас).

Ответить | Правка | Наверх | Cообщить модератору

158. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (-), 29-Окт-24, 19:28 
> Это для нонешних хм... программерофф он "дико оверинженернутый" :)

Вон то уже попахивало obsolete повадками - годике так в 2005 наверное. А тут, вот, нашлась какаха которая жрала почти 4 кило ради того чтобы все ... немного притормозить?! :))

А нашлась она поди потому что супер-скоростное IO появилось - и у народа стали появляться вопросы - мол, а чего счет примитивных чексум такой % проца то жрет? Ну вот видимо кто-то запустил профайлер и сделал выводы :)

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

167. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 20:23 
> А нашлась она поди потому что супер-скоростное IO появилось - и у народа стали появляться вопросы - мол, а чего счет примитивных чексум такой % проца то жрет? Ну вот видимо кто-то запустил профайлер и сделал выводы :)

Вот ППКС прям! :)
Держи плюса за трасе-дебаг-интерпрет :)

Ответить | Правка | Наверх | Cообщить модератору

18. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (48), 28-Окт-24, 16:53 
Ещё удивляет неиспользование SIMDа.
Ответить | Правка | Наверх | Cообщить модератору

24. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 17:02 
Вдруг ты будешь запускать ядро на каком-то умном унитазе, где SIMD нету? А?
У нас же одно ядро для всего, от микроконтроллера до суперкомпьютера.
Туда пихают дрова, блобы и все, чего не жалко.
Ответить | Правка | Наверх | Cообщить модератору

29. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (19), 28-Окт-24, 17:08 
Ерунду написал
Ответить | Правка | Наверх | Cообщить модератору

50. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (48), 28-Окт-24, 17:58 
CPUID и патчинг никто не отменял. Либа для CRC на сишке, которую я юзал (официальная реализация) умеет в такое. По реализации для каждого набора инструкций, и диспатч через CPUID.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

109. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –1 +/–
Сообщение от Аноним (109), 29-Окт-24, 10:02 
Точно, и пофиг, что ядро вырастет.
Ответить | Правка | Наверх | Cообщить модератору

117. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (115), 29-Окт-24, 13:45 
Оно и так вырасло на хедеры от амд и этого прироста хватило бы на реализацию под каждое семейство 86-х процессоров на асме явно не один раз.
Ответить | Правка | Наверх | Cообщить модератору

127. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (124), 29-Окт-24, 15:58 
> Оно и так вырасло на хедеры от амд и этого прироста хватило
> бы на реализацию под каждое семейство 86-х процессоров на асме явно
> не один раз.

При том на хидеры от амд - уже покушаются, с идеей децимировать спруту щупальца. Как раз за это.

Ответить | Правка | Наверх | Cообщить модератору

55. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 18:06 
> Ещё удивляет неиспользование SIMDа.

А сохранение контекста с дохрена регистров тебя не удивляет?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

85. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (85), 28-Окт-24, 21:41 
Не с "дохрена", а только с задействованных.
Ответить | Правка | Наверх | Cообщить модератору

95. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (-), 29-Окт-24, 03:15 
> Не с "дохрена", а только с задействованных.

А как ты вообше намерен информировать переключалку задач какие регистры задействованы - без огромного овеорхеда от этого, перевешивающего профит?

По примерно тем же причинам, насколько я помню, в ядре и плавучка забанена - чтобы немеряный state FPU не сохранять на каждый пшик.

Ответить | Правка | Наверх | Cообщить модератору

174. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (174), 29-Окт-24, 21:21 
Зачем информировать? Просто отключаем прерывания, сами сохраняем, и сами восстанавливаем, и включаем прерывания обратно. CRC - быстрая операция, подождут.
Ответить | Правка | Наверх | Cообщить модератору

178. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 21:53 
> Зачем информировать?

Затем что переключалка - в non-voluntary preempt приходит сама. Берет поток за шкирку и вытряхивает, освобождая место другому потоку. В тот момент времени когда шедулер посчитает это уместным по своим шедулерским соображениям. А такие точки как правило привязаны к хардварным таймерам и их прерываниям.

Ну а если шедулер не информировать - откуда он знает кто там какие регистры юзал, он весь контекст кантует для безусловного поддержания иллюзии что задачу никто никогда не прерывал, что бы она там не делала.

> Просто отключаем прерывания, сами сохраняем, и сами восстанавливаем,
> и включаем прерывания обратно.

Ох, вау, нечто типа кооперативной многозадачности - с запрещенными прерываниями? Хайтек уровня винды 3.11? Вместо честной многозадачки то? :)

> CRC - быстрая операция, подождут.

Быстрая операция по сравнению с чем? И для какого объема? И точно железо без прерываний столько подождет без нежелательных эффектов типа packet loss и проч? А конкретно ядро линя куда более продвинуто это все делает, опять же с тредингом и дефером тяжелых операций, так что bulk работы делает тушка не отвисающая в IRQ.

Ответить | Правка | Наверх | Cообщить модератору

180. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (180), 29-Окт-24, 23:53 
>Быстрая операция по сравнению с чем? И для какого объема?

Для сетевого пакета. Кто обрабатывает в ядре гигабайты, используя его механизмы "доверенной загрузки" для энфорсинга DRM - тот сам виноват, и на его нужды вообще можно забить.

>И точно железо без прерываний столько подождет без нежелательных эффектов типа packet loss и проч?

А железу то что? Оно знай себе в буфер кладёт, без всякого участия процессора. Разумеется, если кольцевой буффер заполнится, то будет потеря пакетов. Но это неизбежно даже при включённых прерываниях. Отключая прерывания на время вычисления и юзая SIMD мы просто торгуем часть гарантированной латентности на в обмен на негарантированную оную (но в большинстве случаев - такую же), зато с высоким throughput.

Ответить | Правка | Наверх | Cообщить модератору

183. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (183), 30-Окт-24, 03:02 
>>Быстрая операция по сравнению с чем? И для какого объема?
> Для сетевого пакета.

А в каких пакетах ядро CRC32 для сетевых пакетов оптом само вот именно CRC32 считает, чтобы такие извраты ради этого терпеть?

> Кто обрабатывает в ядре гигабайты, используя его механизмы "доверенной
> загрузки" для энфорсинга DRM - тот сам виноват, и на его
> нужды вообще можно забить.

Лично меня напрягает превращение ос в какую-то уродскую кооперативную многозадачку без IRQ во имя призрачного выигрыша в некой фигне - нужной хз кому и зачем. При чем тут пассажи про DRM я не понимаю. В каком месте CRC32 помогает или мешает DRM - фиг его знает, не улавливаю логическую цепочку.

> А железу то что? Оно знай себе в буфер кладёт, без всякого
> участия процессора.

А вон то для каких пакетов вообще? А то в эзернете как я помню сетевухи обычно сами считают CRC фрейма и дропают его если он какой-то не такой, накручивая соотв счетчики. В сетевых протоколах именно CRC32 именно в пакетах не особо частая штука. В TCP - чексумы но это не CRC32 а нечто более линейное насколько я помню.

> вычисления и юзая SIMD мы просто торгуем часть гарантированной латентности на
> в обмен на негарантированную оную (но в большинстве случаев - такую
> же), зато с высоким throughput.

Не понимаю для какого случая профит вообще наступить должен, зато догадываюсь что латентность профакается. Впрочем на серверах как раз порой юзают 100Hz тики если латенси меньше. Как раз чтобы радикаьлно снизить число переключений контекста. Это однако не значит что увеличить размер контекста офигенная идея.

Ответить | Правка | Наверх | Cообщить модератору

120. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 15:15 
crc32 всяких разных куча, а SIMD инструкция есть для 1-2 вариантов.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

143. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 18:18 
... кому было нужно - те и сделали. Так то вроде любой вариант на SIMD-ы ложится аккуратненько ...
Ответить | Правка | Наверх | Cообщить модератору

146. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 18:29 
А смысл?
Там приросту не так чтобы много получается.
Ответить | Правка | Наверх | Cообщить модератору

168. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 20:27 
Тут судить не берусь.

Оно ж как говорят ындейцы - фор вхум хау!(С) ... Ну разве что - "это красиво"(С) :)

Ответить | Правка | Наверх | Cообщить модератору

22. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –3 +/–
Сообщение от Аноним (-), 28-Окт-24, 17:01 
crc32.c был добавлен в 2.6 19 years ago
crc32c-pcl-intel-asm_64 12 years ago

Т.е все эти годы в ядре, жил код, который был замедленный в 10 раз?!
У миллионов людей по всему миру.
И ведь кто-то сидел, писал 128 развёрнутых циклов...

А потом эти "писаки" бухтят, что другой язык на 0.5% медленнее и на 10 минут дольше собирается *FACEPALM*

Ответить | Правка | Наверх | Cообщить модератору

30. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (30), 28-Окт-24, 17:09 
Айфоны замедляют. Чем linux хуже.
Ответить | Правка | Наверх | Cообщить модератору

33. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –2 +/–
Сообщение от Аноним (28), 28-Окт-24, 17:13 
> Айфоны замедляют. Чем linux хуже.

Линуск не хуже, линукс лучше!
Он был замедлен еще тогда, когда айфонов даже в проекте не было.

Ответить | Правка | Наверх | Cообщить модератору

84. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 28-Окт-24, 21:00 
> Т.е все эти годы в ядре, жил код, который был замедленный в 10 раз?!

Не в 10 разумеется.

> У миллионов людей по всему миру.
> И ведь кто-то сидел, писал 128 развёрнутых циклов...

Генератор внезапно. Руками фигачить привилегия тех кто програмить не умеет.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

34. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –3 +/–
Сообщение от Столлманы (?), 28-Окт-24, 17:14 
opensource тысячи глаз...
Ответить | Правка | Наверх | Cообщить модератору

110. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (110), 29-Окт-24, 10:25 
а какие претензии? кто-то обещал что они обязательно найдут? может да, а может нет, но шанс сильно больше чем у закрытого кода, это ж просто вероятность
Ответить | Правка | Наверх | Cообщить модератору

69. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –2 +/–
Сообщение от Аноним (69), 28-Окт-24, 19:51 
Я похоже тупой, но я перехожу по ссылке и вижу патч, но там удалено далеко 4000 строк кода. ("Код реализации CRC32C уменьшен примерно в 10 раз (с 4546 до 418 байт).").

Я смотрю не туда? Кто-нибудь скиньте ссылку на удаление большого кол-ва кода.

Или имеется ввиду, что в патче убрали макросы развёртывания и кол-во ассемблерных команд(опкодов) в результирующем бинарнике уменьшилось значительно как указано в статье?

Ответить | Правка | Наверх | Cообщить модератору

93. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (93), 29-Окт-24, 00:03 
> (с 4546 до 418 байт).").

даже если по букве на строку, то 4000 строк не наберется, должно было смутить
А вообще там по ссылке про сгенерированный бинарный код

Ответить | Правка | Наверх | Cообщить модератору

114. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от n00by (ok), 29-Окт-24, 13:14 
с 4546 до 418 байт - это про машинные инструкции, а не строки кода.
Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

73. Скрыто модератором  +/–
Сообщение от Пыпа (?), 28-Окт-24, 20:05 
Ответить | Правка | Наверх | Cообщить модератору

75. Скрыто модератором  +2 +/–
Сообщение от Аноним (75), 28-Окт-24, 20:11 
Ответить | Правка | Наверх | Cообщить модератору

82. Скрыто модератором  +/–
Сообщение от Аноним (-), 28-Окт-24, 20:56 
Ответить | Правка | Наверх | Cообщить модератору

132. Скрыто модератором  +/–
Сообщение от Аноним (129), 29-Окт-24, 16:25 
Ответить | Правка | Наверх | Cообщить модератору

83. Скрыто модератором  –1 +/–
Сообщение от Аноним (-), 28-Окт-24, 20:58 
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

88. Скрыто модератором  +/–
Сообщение от Аноним (88), 28-Окт-24, 23:09 
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

87. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +6 +/–
Сообщение от Аноним (87), 28-Окт-24, 22:48 
Ну и кто там топил за отключение защит от Spectre? Вот этот пример ясно показывает полезность защит. Без защит прирост от оптимизации кода каких-то 12%, а с включёнными - сразу аж 67%! Разница очевидна!
Ответить | Правка | Наверх | Cообщить модератору

89. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Анонимemail (89), 28-Окт-24, 23:28 
А разве он изначально не замедлен чтоб по таимингу не хакнули?
Ответить | Правка | Наверх | Cообщить модератору

102. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Rock (?), 29-Окт-24, 05:42 
О, наконец-то, обратили внимание, что кэш инструкций даже на самых современных процессорах не безразмерный, измеряется десятками килобайт и его промахи из-за непомерного разворачивания циклов слишком дорого обходятся в многозадачной среде.
Ответить | Правка | Наверх | Cообщить модератору

105. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  –2 +/–
Сообщение от Аноним (105), 29-Окт-24, 08:46 
Так циклы же и разворачивают чтобы "попасть" в кеш.
Ответить | Правка | Наверх | Cообщить модератору

107. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +4 +/–
Сообщение от а (?), 29-Окт-24, 09:13 
нет, циклы разворачивают, чтобы убрать условные переходы, которые могут останавливать конвеер из-за неправильного предсказания условия.
а маленький цикл на сотню байт гораздо вероятнее целиком поместится в кеш, чем его развернутая версия на десяток килобайт.
Ответить | Правка | Наверх | Cообщить модератору

113. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Аноним (-), 29-Окт-24, 13:07 
Спасибо Ubuntu, что я на свой Haswell не могу по человечески установить ванильное ядро как раньше, ибо отвалятся такие приблуды как  linux-modules и  linux-modules-extra, а с ними и сеть.
Ответить | Правка | Наверх | Cообщить модератору

121. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 15:17 
Странно что на асме, хотя это же линукс, который из за обилия всякого странного мог собиратся только gcc.

Для себя год назад закрыл тему с CRC32 любого вида на любой платформе: https://github.com/rozhuk-im/liblcb/blob/master/include/math...

Ответить | Правка | Наверх | Cообщить модератору

128. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 16:03 
> Для себя год назад закрыл тему с CRC32 любого вида на любой
> платформе: https://github.com/rozhuk-im/liblcb/blob/master/include/math...

А этому гражданину - пожизенную ссылку в XKCD # 927! И кстати как оно по перфомансу относително воооон того? А то какое-нибудь btrfs им как чексумой ФС пользуется и ваше типичное блеяние о том что и где там в очередном гениально коде не важно - решительно не катит в таких случаях.

Ответить | Правка | Наверх | Cообщить модератору

148. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 18:36 
Понятия не имею, такой простой код смысла бенчить нет.
Единственное там можно поизвращатся и подобрать порог перехода от маленьких таблиц к большим или вообще отказатся от маленьких или больших таблиц.

BTRFS - может смело юзать реализацию на С, но лучше бы им было юзать сразу ту версию CRC32 что есть в некоторых процах.
В целом CRC32 не является узким местом до достаточно больших значений, и скорее оно упрётся в чтение с диска чем в проц по CRC32, даже для топовых nvme.

Ответить | Правка | Наверх | Cообщить модератору

156. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (156), 29-Окт-24, 19:26 
Crc32 или crc32c
Ответить | Правка | Наверх | Cообщить модератору

170. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 20:31 
Просто CRC32 не существует, их там целый ворох и различаются они по постфиксу, вот crc32c уже весьма конкретное указание на алгоритм/полином.
Ответить | Правка | Наверх | Cообщить модератору

163. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 19:51 
> Понятия не имею, такой простой код смысла бенчить нет.

1) Я бы не назвал это простым кодом. Довольно оверинженернутая конструкция. И по суммарному code+rodata, видимо, несколько кило на вид.
2) Как и ожидалось, себе любимому сделаем скидочку, бенчить не будем, все такое.

> Единственное там можно поизвращатся и подобрать порог перехода от маленьких таблиц к
> большим или вообще отказатся от маленьких или больших таблиц.

На минуточку, вы в результате таскаете и то и другое? И суммарно у вас тоже так то - несколько кило барахла (code+rodata), видимо будет.

А когда таких каках в ядре более 9000 - ну вы понимаете что с ним случается. В этом смысле возможность выпилить почти 4 кило ничего не потеряв - очень даже.

> BTRFS - может смело юзать реализацию на С, но лучше бы им
> было юзать сразу ту версию CRC32 что есть в некоторых процах.

Btrfs (и все остальные юзеры crc32 в ядре) как я понимаю юзает наиболее шустрое что в ядре есть. Если есть хардварное, юзается. Если нету - ну, вот, на x86 - вот это вот.

> В целом CRC32 не является узким местом до достаточно больших значений,

Современные сторажи достигли ОЧЕНЬ больших значений.

> и скорее оно упрётся в чтение с диска чем в проц по
> CRC32, даже для топовых nvme.

Они таки стали _очень_ быстрые. А в целом -3.5 кило к весу кернела, +перфоманс, двойной epic win. Как говаривал дедушка Кнут, самый продуктивный день в его жизни программиста был когда он смог угрохать 1000 строк кода.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

164. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от _ (??), 29-Окт-24, 19:51 
> А то какое-нибудь btrfs им как чексумой ФС пользуется

Хмм ... ну да, написано у них в доке что дефаулт - CRC32, но можно поменять ... кто и в-правду бтр гоняет, что скажете, меняете на BLAKE2b или нет?

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

185. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 30-Окт-24, 03:17 
>> А то какое-нибудь btrfs им как чексумой ФС пользуется
> Хмм ... ну да, написано у них в доке что дефаулт -
> CRC32, но можно поменять ... кто и в-правду бтр гоняет, что
> скажете, меняете на BLAKE2b или нет?

Чтобы проц то в 30 раз тормознуть счетом чексум? Всенепременно. Для "обычных" нужд как то заметить гнилой шнурок, проц, планку памяти, девайс, контроллер и проч - CRC32 хватает, в общем то. Единичные битовые ошибки CRC32 вообще гарантировано ловит. Проблемы могут быть только если ожидается откровенная труха оптом, там конечно за энное число попыток - пробьет и пролезет наружу. Если это актуальное соображение, можно и blake2 конечно. Но это достаточно специфичная ситуация.

Ответить | Правка | Наверх | Cообщить модератору

161. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 19:37 
> Для себя год назад закрыл тему с CRC32

Очередной самописный велосипед?
Хотя... это было вполне ожидаемо.

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

149. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +1 +/–
Сообщение от Ivan_83 (ok), 29-Окт-24, 18:38 
Вообще то тот код был оптимизирован под тогдашнее железо и отлично работал и работает до сих пор.

Аргументация у вас как у настоящего растиста: обозвать код плохим без аргументации.

Ответить | Правка | Наверх | Cообщить модератору

181. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (-), 29-Окт-24, 23:55 
У тебя какое-то глубоко неверное понимание "растистов", то бишь нас. Я не буду гадать, как тебе удалось впасть в такие заблуждения, но если тебе интересно как, то ты как-нибудь сам разбирайся. Не надо ко мне с глупыми вопросами приставать.
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

154. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (156), 29-Окт-24, 19:25 
Crc32 и crc32c это разные причем crc32 аппаратно реализована в процах.

В прикладном коде часто используется crc32c?

Ответить | Правка | Наверх | Cообщить модератору

171. "В ядре Linux оптимизирована реализация алгоритма CRC32C"  +/–
Сообщение от Аноним (144), 29-Окт-24, 20:57 
Алгоритм тот же, разные полиномы. Аппаратно в x86 реализован как раз CRC32C.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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