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

"В ядре 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.dev/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 +/–
	Сообщение от Аноним (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ообщить модератору

	192. "В ядре Linux ускорен алгоритм CRC32C"	+/–
	Сообщение от Аноним (-), 30-Окт-24, 21:02
	> Так что трясти какими–то там показателями за прошлый год, как минимум, странно. Интел и их фанаты пытаются трясти какими-то закупленными машинами. Которые пока там еще запустят и отладят. И еще вопрос сколько там реальных нанометров получится. Сейчас вообще пошла гнилая мода. Нанометры у интела - такие же как и ватты! Т.е. - свои собственные. И то что они называли N-нанометровым процессом означало вовсе не то что вы могли подумать. А реально нанометров - больше. Видимо с китайцев пример взяли, там тоже - если китайские ватты и миллиамперчасы меньше номинала, то нанометры - больше. Вон они рассказывают про якобы 8, своими силами. На поверку, 8 это только точность совмещения слоев. А реально фичи соответствуют примерно 55 нм и это сильно более другой коленкор. Теперь китайские нанометры докатились и до интела...
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	197. "В ядре Linux ускорен алгоритм CRC32C"	+/–
	Сообщение от Аноним (-), 31-Окт-24, 06:34
	> https://3dnews.ru/1101603/ А вот еще интелу подарочки, Тик! TSMC решил отменить скидки https://3dnews.ru/1113231/intel-poka-s-trudom-udayotsya-real... Ток! https://www.phoronix.com/review/google-axion-c4a - а вот гугол видимо не очень понимают зачем им поставщик который их фродит в параметрах и делает процы которые через полгода дохнут. Зато это находит теплое понимание у фирмы ARM. А что, Интел, незамениымх на этом глобусе не бывает. Думали, нельзя обойтись без фирмы Интел? Экие наивные господа. Моторола тоже так думала. И где ее процы теперь? Да еще откровенные затыкания рта кастометрам на явно дефективные серии процов, вот, как-то все заметили. Или как быстро и эффективно слить бренд.
	Ответить | Правка | К родителю #101 | Наверх | 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ообщить модератору

	188. "В ядре Linux ускорен алгоритм CRC32C"	+/–
	Сообщение от _ (??), 30-Окт-24, 17:01
	> Но CRC32 куда быстрее считается. А вот в официальной доке BTRFS пишут что на _два_порядка_ медленнее :) Они конечно тоже ещё ты Ынженегры, но всё=же в бесконечность раз грамотнее тебя о Анонимус :-р ;-D
	Ответить | Правка | Наверх | Cообщить модератору

	193. "В ядре Linux ускорен алгоритм CRC32C"	+/–
	Сообщение от Аноним (-), 30-Окт-24, 21:09
	>> Но CRC32 куда быстрее считается. > А вот в официальной доке BTRFS пишут что на _два_порядка_ медленнее :) > Они конечно тоже ещё ты Ынженегры, но всё=же в бесконечность раз грамотнее > тебя о Анонимус :-р ;-D О как, дедуля не только облажался на публику, насоветовав в 30 раз более тормозное алго как "инновации", но еще и тролить пытается. Столь же "успешно" как и с советами алго. Ибо медленнее - Blake2. Примерно в 30 раз относительно CRC32. И если б дедуля сравнил сорц того и другого то догадался бы почему. Но можно на это забить и вместо этого блестать экспертизой на публику. С такими учителями - мне понятнее почему в рф образование там где оно, увы, находится. И эти люди будут мне расскзывать где инжeнеepов линчyют.. Дедуля, читай вику еще раз. Алгоритмист из тебя - хуже чем из твоего ученика-питониста. И это е...й стыд. Или просто вали на пенсию и не позорься, тебе только на завалинке сидеть осталось.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В ядре Linux ускорен алгоритм CRC32C"	+1 +/–
	Сообщение от Аноним (-), 28-Окт-24, 17:19
	> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее Это каких? 486 чтоли? Они пропатчили x86 реализацию, и если x86 такое не умеет - это что? У вас x86 древнее Haswell?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	48. "В ядре Linux ускорен алгоритм CRC32C"	–3 +/–
	Сообщение от Аноним (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ообщить модератору

	196. "В ядре Linux ускорен алгоритм CRC32C"	+/–
	Сообщение от Аноним (196), 30-Окт-24, 23:19
	> Чего там на страрых? Cortex-A53 же in-order. И их ещё полно, где > используется. И в сетевых девайсах тоже, ага, CRC32. На них модуль crc32c-pcl-intel немножечко не загружают/используют. Почему-то. Может быть, потому что интеловый асм Cortex A никогда не умел, например? :))
	Ответить | Правка | Наверх | 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"	–7 +/–
	Сообщение от Аноним (-), 28-Окт-24, 17:04
	AMD Zen 2 вышли в 2019 году. Сейчас их даже бомж в качестве подарка не примет! > P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах? Просто никому нет дела до всякого старья.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	37. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+13 +/–
	Сообщение от 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
	>Сейчас их даже бомж в качестве подарка не примет! А я почему-то аж купил 2300g. Хотел 2500ge купить, а продавец не продал(((
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	118. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Окт-24, 13:47
	>>Сейчас их даже бомж в качестве подарка не примет! > А я почему-то аж купил 2300g. Хотел 2500ge купить, а продавец не продал((( Ну так ты для себя любимого покупал! На себе можно и сэкономить))
	Ответить | Правка | Наверх | 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"	–1 +/–
	Сообщение от _ (??), 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ообщить модератору

	189. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	–1 +/–
	Сообщение от _ (??), 30-Окт-24, 17:06
	Обос**сля? :) Написанное не осилил? :) Ну я конечно могу на русский и даже на твой перевести что там написано - но это уже за деньги :)
	Ответить | Правка | Наверх | Cообщить модератору

	194. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
	Сообщение от Аноним (-), 30-Окт-24, 21:18
	> Обос**сля? :) Написанное не осилил? :) > Ну я конечно могу на русский и даже на твой перевести что > там написано - но это уже за деньги :) Дедуля, в отличие от тебя - я в состоянии те исходники еще и читать, и люблю алгоримику, именно поэтому я в курсе во сколько именно ты мне стрындел. Но за раскопку фактов в вике своим ходом - безусловно, спасибо. Там английским по белому сказано что Blake2 в 34 раза медленнее чем CRC32C. Ибо CRC32C делает блок 4К за примерно 470 тактов проца, а Blake2b - за 14500, что примерно в 34 раза медленнее. Видишь, для тех кто уже в режими "старый что малый" я могу и перевести даже ;)
	Ответить | Правка | Наверх | 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ообщить модератору

	190. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
	Сообщение от _ (??), 30-Окт-24, 17:17
	Я btrfs не юзаю, у меня нет эксабайт фоточек с котиками, которые все потерять не жалко :) У меня в кровавом(С), потеря одной единственной транзакции может стоить компании зарплаты целого отдела за год ... поэтому и орг-выводы делаются моментально и жестко :) Поэтому на моих сториджах чексумится всё, и там НЕ CRC32*-family :) Да даже у всех 3 мэйжор облаков - НЕ оно. PS: Ещё раз для тугих: CRC32* в ядре _должны_ быть, пока даже _обязанны_. Но их важность нынче сильно меньше, и то, что вопиющую неоптимальность заметили только через 20 лет - прямо об этом и говорит :)
	Ответить | Правка | Наверх | Cообщить модератору

	195. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
	Сообщение от Аноним (-), 30-Окт-24, 21:32
	> Я btrfs не юзаю, у меня нет эксабайт фоточек с котиками, которые > все потерять не жалко :) Судя по вашим знаниям в алгоритмах - вашей экспертизе грош цена в базарный день. Хотя подогнать мне цитату btrfs'ной вики, с пруфом моей точки зрения было совершенно эпично, вот все бы так. > У меня в кровавом(С), потеря одной единственной транзакции может стоить компании зарплаты > целого отдела за год ... поэтому и орг-выводы делаются моментально и жестко :) Не понимаю как вас там еще держат с такими знаниями. Это либо госпомойка, либо нечто наподобие. И лично я все выводы после вашего спича уже сделал, и вы сами помогли сделать это моментально и жестко своим вопиющим ламерством в алгоритмике :) > Поэтому на моих сториджах чексумится всё, и там НЕ CRC32*-family :) Да > даже у всех 3 мэйжор облаков - НЕ оно. У разных систем - разные задачи. У ZFS по дефолту вообще флетчеровские суммы, насколько я помню. Чуть попроще CRC, но чуть быстрее считается. У bcachefs - xxhash (коего btrfs умеет). Ну так, глядя на то что другие юзают по дефолту. > _обязанны_. Но их важность нынче сильно меньше, и то, что вопиющую > неоптимальность заметили только через 20 лет - прямо об этом и говорит :) Ты мне тут рассказывал как я должен везде перейти на в 34 раза более тяжелое алго. Зачем-то. Без обоснований. Хотя для тела с учеником-питонистом это уровень и есть.
	Ответить | Правка | Наверх | 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ообщить модератору

	187. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
	Сообщение от Аноним (144), 30-Окт-24, 14:12
	> Не с "дохрена", а только с задействованных. А "незадействованных" не существует. Если какие-то регистры не используются тобой, то наверняка они используются тем, кто тебя вызвал. Ну и, естественно, тем потоком, на который тебя поменяет планировщик.
	Ответить | Правка | К родителю #85 | Наверх | 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
А тем временем «Власти России предложили создать свое Linux-сообщество — после того, как 11 российских программистов отстранили от разработки ядра Linux» @ медуза.ио и другие
Ответить | Правка | Наверх | 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
	> А тем временем «Власти России предложили создать свое Linux-сообщество — после > того, как 11 российских программистов отстранили от разработки ядра Linux» > @ медуза.ио и другие Ща вам тут старший програмист из альта мастер класс даст как ядро писать. Правда сишку он не знает кажется, но кого такие мелочи останавливали?
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	88. Скрыто модератором	+/–
	Сообщение от Аноним (88), 28-Окт-24, 23:09
	> Власти России предложили создать свое Linux-сообщество На что только не пойдут, лишь бы своего ничего не создавать...
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

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

89. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
Сообщение от Аноним (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"	+2 +/–
Сообщение от Аноним (-), 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ообщить модератору

186. "В ядре Linux оптимизирована реализация алгоритма CRC32C"	+/–
Сообщение от InuYasha (??), 30-Окт-24, 10:47
В 2000 году AMD рекомендовала unroll-ить все мелкие и заранее известные циклы. Времена меняются. Эх.. :(
Ответить | Правка | Наверх | Cообщить модератору

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

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

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