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

"В ядре 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. Сообщение от Аноним (1), 28-Окт-24, 16:11	+14 +/–
> Код реализации CRC32C уменьшен примерно в 10 раз (с 4546 до 418 байт). Наконец-то правильный академический код добрался до Linux.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #103

2. Сообщение от swarus (ok), 28-Окт-24, 16:15	+12 +/–
на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4, #23, #36, #40, #67, #112, #129

3. Сообщение от нах. (?), 28-Окт-24, 16:16	–4 +/–
> на процессорах AMD Zen 2, 6.4% - Intel Emerald Rapids и 4.8% > Intel Haswell а у кого процессор немодный - идет найух. Не зря Линукса в консультанты интела взяли. Вот, работает человек над повышением продаж. P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #7, #9, #25, #32, #39

4. Сообщение от нах. (?), 28-Окт-24, 16:17	+3 +/–
Не исключено что на могущих, но имеющих чуть меньшую глубину очереди - тоже быстрее. Но мерять вам интел запретил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #31, #46

5. Сообщение от Аноним (5), 28-Окт-24, 16:21	+/–
Этим процам больше 5 лет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #15

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

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

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

13. Сообщение от Аноним (48), 28-Окт-24, 16:48	+/–
>Код реализации CRC32C уменьшен примерно в 10 раз (с 4546 до 418 байт). Там в Линуксе совсем долбанулись? Реализация любого CRC тривиальна и по памяти делается.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #49

14. Сообщение от Аноним (48), 28-Окт-24, 16:51	–3 +/–
>x86_64 CPUs can predict loops well, so it is fine to just use a loop instead То есть на пни болт положили?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98

15. Сообщение от Игорь (??), 28-Окт-24, 16:51	+3 +/–
> Этим процам больше 5 лет Ага, особенно Intel Emerald Rapids, которые вышли в декабре 2023г
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #42

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

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

19. Сообщение от Аноним (19), 28-Окт-24, 16:54	+/–
Оно еще и на ассемблере написано
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #28

20. Сообщение от Аноним (20), 28-Окт-24, 16:56	+/–
давно, уже 6.12-rc5
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

22. Сообщение от Аноним (-), 28-Окт-24, 17:01	–3 +/–
crc32.c был добавлен в 2.6 19 years ago crc32c-pcl-intel-asm_64 12 years ago Т.е все эти годы в ядре, жил код, который был замедленный в 10 раз?! У миллионов людей по всему миру. И ведь кто-то сидел, писал 128 развёрнутых циклов... А потом эти "писаки" бухтят, что другой язык на 0.5% медленнее и на 10 минут дольше собирается *FACEPALM*
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #84

23. Сообщение от Аноним (-), 28-Окт-24, 17:01	–2 +/–
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее Вот и сидите на старых процессорах со старым ядром. Хлам не должен замедлять прогресс, особенно когда речь идет о +66.8% прироста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #90, #137

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

25. Сообщение от Аноним (-), 28-Окт-24, 17:04	–7 +/–
AMD Zen 2 вышли в 2019 году. Сейчас их даже бомж в качестве подарка не примет! > P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах? Просто никому нет дела до всякого старья.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #37, #116, #119, #133

28. Сообщение от Аноним (28), 28-Окт-24, 17:07	+/–
И великолепно показывает, что даже на ассемблере можно написать какой-то "страх и ужас") Зато как в соседней теме про tinyGO рассказывали "вы бы еще микроконтроллер на питоне писали, бубубу!", "вебассебли замедлит выполнение".. А вот как оно вышло, Михалыч)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #51, #135

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

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

31. Сообщение от Аноним (31), 28-Окт-24, 17:09	+1 +/–
> "Но мерять вам интел запретил." Интел выкладывает весь мёд для повышения капитализации перед продажей Квалкому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #101

32. Сообщение от Аноним (32), 28-Окт-24, 17:11	–2 +/–
> я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах? Как будто другие процессоры кому-то интересны в бизнесе. IBM со своими сам справится, на китайские лонгсуны всем просто плевать (кроме китая, на который всем тоже плевать), а больше ничего особо так и нет. Огороженный Apple silicon? Так на них линукс ставят только энтузиасты, бизнес макось и так устраивает. Так что всё правильно сделали, неча усилия распылять. Кому очень надо — patches are welcome (если это не байКал хехехе).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #38

33. Сообщение от Аноним (28), 28-Окт-24, 17:13	–2 +/–
> Айфоны замедляют. Чем linux хуже. Линуск не хуже, линукс лучше! Он был замедлен еще тогда, когда айфонов даже в проекте не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

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

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

37. Сообщение от Abra (?), 28-Окт-24, 17:22	+13 +/–
подари мне, пожалуйста?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #41, #86

38. Сообщение от нах. (?), 28-Окт-24, 17:27	+1 +/–
> Как будто другие процессоры кому-то интересны в бизнесе. я и говорю - кто не успел купить последнего поколения - тот л-х педальный, и должен, собака, страдать! > Кому очень надо — patches are welcome не, это так не работает. Продажи интел не должны страдать от твоих косоруких патчей! Иди вон колор на колор поисправляй для начала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #43

39. Сообщение от Аноним (40), 28-Окт-24, 17:29	+1 +/–
> а у кого процессор немодный - идет найух. Что за проц такой?То что столь жесткий unroll циклов не имеет особого смысла на процах с OoO известно с середины нулевых, наверное. Почему до вон тех дошло только в 2024 - загадка, но хорошо что дошло, минус 3 с фигом кило мусора без каких либо потерь и даже вот с профитом. > Не зря Линукса в консультанты интела взяли. Вот, работает человек над повышением продаж. Повышением продаж ... чего? OoO с предсказаниями появился еще в первопнях по моему. > P.S. я правильно понимаю что они даже не почесались потестировать на каких-то других процессорах? На чем надо было crc32-intel тестировать? На первом пне? 486?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #78, #138

40. Сообщение от Аноним (40), 28-Окт-24, 17:31	+1 +/–
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее В случае x86 это не старый а очень старый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

41. Сообщение от Аноним (-), 28-Окт-24, 17:37	+/–
> подари мне, пожалуйста? С радость, но уже остались только Zen 4 и Zen 5. Придется подождать пару лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

42. Сообщение от Аноним (-), 28-Окт-24, 17:38	+/–
> Ага, особенно Intel Emerald Rapids, которые вышли в декабре 2023г Но профит есть и на Haswell который весьма немолодая штука уже. И вообще это оптимизация родом из середины нулевых, а то что всякие похонахи не отпустили тормоз с еще тех пор... а вот эти - уже отпустили! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

43. Сообщение от Аноним (-), 28-Окт-24, 17:38	+/–
> я и говорю - кто не успел купить последнего поколения - тот л-х педальный, и должен, собака, страдать! А что посидеть на старом ядре уже нельзя? Ну типа корона отвалится? На крайняк есть гентушники, они только рады ядро пересобирать. > Иди вон колор на колор поисправляй для начала. Не, сейчас гораздо популярнее проверять цвет пачпорта. Вот ссаными тряпками выгнали 11 штук и... ядро ускорилось! Надо провести серию экспериментов - выкидывать по 1 или пачкой, со скандалом или по тихому, говорить прямо "вы №№№№" или "ну вы же понимаете ситуацию"... В общем простора для исследований просто море.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #45, #71

45. Сообщение от Аноним (-), 28-Окт-24, 17:50	–1 +/–
> А что посидеть на старом ядре уже нельзя? Ну типа корона отвалится? > На крайняк есть гентушники, они только рады ядро пересобирать. Вы издеваетесь чтоли? Вон то дает эффект на почти всех более-менее не ископаемых процах умеющих OoO. Модуль для crc-intel патчили - так что всяким ARM и прочим RISCV где in-order еще бывает местами актуально ради мелкости ядер - это вообше пофиг. >> Иди вон колор на колор поисправляй для начала. > Не, сейчас гораздо популярнее проверять цвет пачпорта. > Вот ссаными тряпками выгнали 11 штук и... ядро ускорилось! Торвальдс очень понятно объяснил кой-кому что за ними накопился нехилый техдолг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от Аноним (-), 28-Окт-24, 17:51	+/–
> Не исключено что на могущих, но имеющих чуть меньшую глубину очереди - > тоже быстрее. Вон то должно быть так же или быстрее на почти всем отдаленно напоминающим современный проц, чуть ли не эпохи первопня, уже умевшего спекулятивщину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

48. Сообщение от Аноним (48), 28-Окт-24, 17:53	–3 +/–
Haswell - это не x86. Это haswell.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #57

49. Сообщение от Аноним (-), 28-Окт-24, 17:57	+1 +/–
> Там в Линуксе совсем долбанулись? Реализация любого CRC тривиальна и по памяти делается. И, конечно, ты порвешь по перфомансу хотя-бы вариант из Linux? А то когда какая-нибудь ФС на быстром SSD захочет чексумы блоков им например считать, или что там - скорости много не бывает. В Linux был довольно навороченый вариант, с разворотами циклов от 1 до 127, джампом в нужный и .. и оказалось что нет никакого смысла гонять простыню 127 циклов когда разворот на 4 цикла дает тот же или даже более хороший результат. Получилось дохрена кода - без какого либо профита.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #54, #141

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

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

52. Сообщение от Аноним (-), 28-Окт-24, 18:02	+/–
> Также удивляет то, что написано на асме, вместо сишки. Что там такого, > что Clang на -O3 не сможет выоптимизировать? Явный unroll - при том в изначальном варианте дико оверинженернутый, с unroll от 1 до 127 и вычисляемым джампом в нужный из. И тут вдруг оказалось что этот джамп + такие простыни не являются каким-то улучшением. И это известно наверное уже около 15-20 лет так то. Unroll может как-то помочь на МК и малохольных ядрах типа (low end) in-order апликушников на ARM/RISCV. На всем остальном польза от него весьма варьируется и даже может быть вред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #142

54. Сообщение от Аноним (48), 28-Окт-24, 18:05	+/–
>И, конечно, ты порвешь по перфомансу хотя-бы вариант из Linux? Нет, конечно. Если нужна супер-производительность для брутфорса, я GPU использую. Если нужна супер-производительность на CPU - то SIMD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #56

55. Сообщение от Аноним (-), 28-Окт-24, 18:06	+/–
> Ещё удивляет неиспользование SIMDа. А сохранение контекста с дохрена регистров тебя не удивляет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #85

56. Сообщение от Аноним (-), 28-Окт-24, 18:09	+/–
> Нет, конечно. Если нужна супер-производительность для брутфорса, я GPU использую. > Если нужна супер-производительность на CPU - то SIMD. Ух да, а теперь покажи переключения контекстов с этим всем? А 1000 раз в секунду как тебе? Обычные тики "десктопного" ядра линукс если что. Ты уверен что там оверхед от сохранений контекста не перевесит профит? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #123

57. Сообщение от Аноним (-), 28-Окт-24, 18:10	+/–
> Haswell - это не x86. Это haswell. Haswell это микроархитектура одного из x86(-64) процессоров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

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

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

71. Сообщение от нах. (?), 28-Окт-24, 19:59	+1 +/–
> А что посидеть на старом ядре уже нельзя? ну типа без исправлений багов? Можно, разрешаю. > В общем простора для исследований просто море. угу, а через недельку расстрелять всех рыжих. И, пожалуй, велосипедистов. Вдруг ведро ускорится. Причем на вычислении crc32, который придумали когда компьютеры были большие, и специально для того чтоб его было несложно вычислять на любом калькуляторе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

73. Сообщение от Пыпа (?), 28-Окт-24, 20:05    Скрыто ботом-модератором	+/–
А тем временем «Власти России предложили создать свое Linux-сообщество — после того, как 11 российских программистов отстранили от разработки ядра Linux» @ медуза.ио и другие
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #83, #88

75. Сообщение от Аноним (75), 28-Окт-24, 20:11	+2 +/–
И правильно! У нас есть крутые специалисты, Рогозин, например. Он недавно заставил УАЗ улучшить сборку! Так что думаю с каким-то линуксом справится как два пальца
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #82

78. Сообщение от Аноним (78), 28-Окт-24, 20:39	+/–
> На чем надо было crc32-intel тестировать? На первом пне? 486? На первых atom, они как раз без OoO. С другой стороны, они и 15 лет назад в момент своего выхода были непойми для чего созданы, учитывая, что на них тормозило абсолютно всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #81

81. Сообщение от Аноним (-), 28-Окт-24, 20:55	+/–
> На первых atom, они как раз без OoO. С другой стороны, они > и 15 лет назад в момент своего выхода были непойми для > чего созданы, учитывая, что на них тормозило абсолютно всё. Это наверное единственные x86 которые могут быть как-то затронуты. И то - ждем когда их владельцы забенчат это. Ну, если им оно надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

82. Сообщение от Аноним (-), 28-Окт-24, 20:56	+/–
> И правильно! > У нас есть крутые специалисты, Рогозин, например. > Он недавно заставил УАЗ улучшить сборку! А как насчет запустить на орбиту вокруг Солнца, догонять родстер? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #132

83. Сообщение от Аноним (-), 28-Окт-24, 20:58	–1 +/–
> А тем временем «Власти России предложили создать свое Linux-сообщество — после > того, как 11 российских программистов отстранили от разработки ядра Linux» > @ медуза.ио и другие Ща вам тут старший програмист из альта мастер класс даст как ядро писать. Правда сишку он не знает кажется, но кого такие мелочи останавливали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

84. Сообщение от Аноним (-), 28-Окт-24, 21:00	+/–
> Т.е все эти годы в ядре, жил код, который был замедленный в 10 раз?! Не в 10 разумеется. > У миллионов людей по всему миру. > И ведь кто-то сидел, писал 128 развёрнутых циклов... Генератор внезапно. Руками фигачить привилегия тех кто програмить не умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

85. Сообщение от Аноним (85), 28-Окт-24, 21:41	+/–
Не с "дохрена", а только с задействованных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #95, #187

86. Сообщение от COBA (?), 28-Окт-24, 21:54	+/–
Куда слать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

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

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

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

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

92. Сообщение от _kp (ok), 28-Окт-24, 23:51	+/–
Ну, у меня ноут на i5-3210. Конечно не основной, но для 3д печати, интернета и ютубов в гараже - и он годен! На последнем Ubuntu, KDE, и не жужжит. А производительность, понятие относительное. Вот, Windows планшеты совсем недавно этого старичка по производительности обошли, а Андроид планшеты до сих пор клячи, и ничего, народ радуется флагманам. А по сравнению с упомянутым i5, и Haswell конфетка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #94

93. Сообщение от Аноним (93), 29-Окт-24, 00:03	+/–
> (с 4546 до 418 байт)."). даже если по букве на строку, то 4000 строк не наберется, должно было смутить А вообще там по ссылке про сгенерированный бинарный код
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

94. Сообщение от Аноним (-), 29-Окт-24, 03:08	+1 +/–
> Ну, у меня ноут на i5-3210. Я думаю что OoO механика уже и на нем была - в примерно том же виде. Это знание появилось в середине нулевых, когда до народа стало доходить что порой излишний unroll даже все портит, вымывая кеш жирным кодом лишний раз и ничего нового не давая т.к. команду бранча параллельно обсчитали и оверхеда и так особо не было, оно так только для in-order без спекулятивщины и предсказаний. А в x86 это все уже есть очень давно. Ну вот кроме некоторых атомов разве что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

95. Сообщение от Аноним (-), 29-Окт-24, 03:15	+1 +/–
> Не с "дохрена", а только с задействованных. А как ты вообше намерен информировать переключалку задач какие регистры задействованы - без огромного овеорхеда от этого, перевешивающего профит? По примерно тем же причинам, насколько я помню, в ядре и плавучка забанена - чтобы немеряный state FPU не сохранять на каждый пшик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #174

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

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

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

101. Сообщение от Аноним (101), 29-Окт-24, 05:39	+/–
https://3dnews.ru/1101603/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #106, #197

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

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

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

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

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

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

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

111. Сообщение от Аноним (101), 29-Окт-24, 12:30	+/–
>процессорами последних поколений По факту, проблемы были замечены у k-процессоров 13 и 14-го поколения. https://3dnews.ru/1112050/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #173, #179

112. Сообщение от n00by (ok), 29-Окт-24, 13:06	+1 +/–
> на старых процессорах не могущих в предсказание-предвыполнение старый код быстрее То есть процессор неспособен заблаговременно выбрать адрес из таблицы переходов, но исполняться волшебным образом будет быстрее. И это без учёта загрязнения кеша и задержек  из-за чтения ОЗУ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

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

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

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

116. Сообщение от Аноним (115), 29-Окт-24, 13:41    Скрыто ботом-модератором	+/–
>Сейчас их даже бомж в качестве подарка не примет! А я почему-то аж купил 2300g. Хотел 2500ge купить, а продавец не продал(((
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #118

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

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

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

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

121. Сообщение от Ivan_83 (ok), 29-Окт-24, 15:17	+/–
Странно что на асме, хотя это же линукс, который из за обилия всякого странного мог собиратся только gcc. Для себя год назад закрыл тему с CRC32 любого вида на любой платформе: https://github.com/rozhuk-im/liblcb/blob/master/include/math...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #128, #161, #181

123. Сообщение от Ivan_83 (ok), 29-Окт-24, 15:45	+/–
А как же tickless?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #124

124. Сообщение от Аноним (124), 29-Окт-24, 15:55	+/–
> А как же tickless? Как, как... вы там бенчмаркать собрались - ненагруженную систему в вакууме чтоли? Если она не нагружена - то о чем бенч?! Ядро же не считает CRC32 чисто для прикола?! А если нагружена - так ядро нынче heavily threaded, и вообще :) Так что размер контекста - некий аргумент. Чем он жирнее, тем хуже задачи переключать получается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #145

125. Сообщение от Аноним (124), 29-Окт-24, 15:56	+/–
> Какие, первые? Так давно уже. > А в 4м это есть из коробки. Да и 4-е лучше в эту коробку - вернуть уже, или как брелок использовать. Жрет много, считает мало, управление питанием никакое. Это отопитель воздуха со встроенной функцией счета был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

127. Сообщение от Аноним (124), 29-Окт-24, 15:58	+/–
> Оно и так вырасло на хедеры от амд и этого прироста хватило > бы на реализацию под каждое семейство 86-х процессоров на асме явно > не один раз. При том на хидеры от амд - уже покушаются, с идеей децимировать спруту щупальца. Как раз за это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

128. Сообщение от Аноним (-), 29-Окт-24, 16:03	+/–
> Для себя год назад закрыл тему с CRC32 любого вида на любой > платформе: https://github.com/rozhuk-im/liblcb/blob/master/include/math... А этому гражданину - пожизенную ссылку в XKCD # 927! И кстати как оно по перфомансу относително воооон того? А то какое-нибудь btrfs им как чексумой ФС пользуется и ваше типичное блеяние о том что и где там в очередном гениально коде не важно - решительно не катит в таких случаях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #148, #164

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

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

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

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

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

137. Сообщение от _ (??), 29-Окт-24, 17:37	+/–
> особенно когда речь идет о +66.8% прироста. Да, но - прироста _только_ в расчёте CRC32 сумм. ... А теперь ты берёшь и смотришь _где_оно_ещё_осталось_?!?! ;-) И понимаешь что это громогласный анонс об установке на паравоз новейшей карбид-вольфрамовой турбины 8-о Повышает экономичность паровоза серии "овца" аж на "+66.8%"!!! Ну что - "запануемо"?!? ;-) PS: Тут вон - всё что меньше sha256 списывают ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #144, #151

138. Сообщение от _ (??), 29-Окт-24, 17:49	–1 +/–
> Почему до вон тех дошло только в 2024 - загадка Загадка?! :) Да ладно! Просто прикинь кому оно нынче надо это CRC32. Ты бы ещё на драйвер для флоппи пожаловался :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #153

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

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

141. Сообщение от _ (??), 29-Окт-24, 17:58	+/–
> Получилось дохрена кода - без какого либо профита. Ну просто на CRC32 всем ... А так то давно на всех площадках озвучивают что нынче основной метод оптимизации жто сделать так чтоб твой код влазил в кэш :)  Просто до ненужно вот только в 24 году руки дошли. Да никто и не заметит :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

142. Сообщение от _ (??), 29-Окт-24, 18:15	+/–
> Явный unroll - при том в изначальном варианте дико оверинженернутый Это для нонешних хм... программерофф он "дико оверинженернутый" :) В те ремена это был стандартный метод оптимизации, это любой джун с закрытими глазами делел :) Ну можен не на 128 веток, но и не все ведро писали :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #147, #158

143. Сообщение от _ (??), 29-Окт-24, 18:18	+/–
... кому было нужно - те и сделали. Так то вроде любой вариант на SIMD-ы ложится аккуратненько ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #146

144. Сообщение от Аноним (144), 29-Окт-24, 18:21	+/–
> А теперь ты берёшь и смотришь _где_оно_ещё_осталось_?!?! Во всех современных файловых системах, например. > Тут вон - всё что меньше sha256 списывают ... Слышал звон, да не знаешь где он. SHA1 спысывают *для задач криптографии*.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

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

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

147. Сообщение от Аноним (-), 29-Окт-24, 18:35	+/–
> Это для нонешних хм... программерофф он "дико оверинженернутый" :) Ну как старые програмизды написяли мы уже видим) Проблема же не в оверинжениринге, а в том что это лабуда еще и тромознутая. > В те ремена это был стандартный метод оптимизации, это любой джун с закрытими глазами делел :) С таким же "качеством" или получше? > Ну можен не на 128 веток, но и не все ведро писали :) И слава богу)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #159

148. Сообщение от Ivan_83 (ok), 29-Окт-24, 18:36	+/–
Понятия не имею, такой простой код смысла бенчить нет. Единственное там можно поизвращатся и подобрать порог перехода от маленьких таблиц к большим или вообще отказатся от маленьких или больших таблиц. BTRFS - может смело юзать реализацию на С, но лучше бы им было юзать сразу ту версию CRC32 что есть в некоторых процах. В целом CRC32 не является узким местом до достаточно больших значений, и скорее оно упрётся в чтение с диска чем в проц по CRC32, даже для топовых nvme.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #156, #163

149. Сообщение от Ivan_83 (ok), 29-Окт-24, 18:38	+1 +/–
Вообще то тот код был оптимизирован под тогдашнее железо и отлично работал и работает до сих пор. Аргументация у вас как у настоящего растиста: обозвать код плохим без аргументации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

151. Сообщение от Аноним (-), 29-Окт-24, 19:15	+/–
>> особенно когда речь идет о +66.8% прироста. > Да, но - прироста _только_ в расчёте CRC32 сумм. ... А теперь > ты берёшь и смотришь _где_оно_ещё_осталось_?!?! ;-) В чертовой куче протоколов, форматов файлов, ФС и проч - как чексумы для обнаружения разрушения данных. > PS: Тут вон - всё что меньше sha256 списывают ... Вот ща буду на уберскоростном SSD считать sha256 для проверки целостности блоков файлов в ФС. И все упрется - в счет SHA256. Оно мне такое надо? Как криптографически стойкое CRC32 не котировалось никогда - элементарно подгоняется до оригинала целенаправленной заменой 32 бит в другом месте потока. Но вероятность самопроизвольного возникновения такой замены от разрушения данных, при редких разрушениях - скромная. С другой стороны всего 4 байта внагрузку, относительно шустро считается и хорощие свойства детекта битовых ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #172

153. Сообщение от Аноним (-), 29-Окт-24, 19:20	–1 +/–
> Загадка?! :) Да ладно! Просто прикинь кому оно нынче надо это CRC32. > Ты бы ещё на драйвер для флоппи пожаловался :) На минуточку дефолтовый чексум в btrfs. Обслуживающем всего-то пару миллиардов хомяков фэйсбука. Для обнаружений кривого хардвара - вполне хватает. А вы можете SHA256 считать пытаясь угнаться за энтерпрайзным SSD конечно. Или заякорить перфоманс всего IO счетом SHA256.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #165

154. Сообщение от Аноним (156), 29-Окт-24, 19:25	+/–
Crc32 и crc32c это разные причем crc32 аппаратно реализована в процах. В прикладном коде часто используется crc32c?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #171

155. Сообщение от Аноним (-), 29-Окт-24, 19:26	+/–
> Я вам указываю что вероятно уже нет никаких 1000 переключений контекста в секунду. А я указываю что ядро Linux уже давно heavily threaded, даже само по себе. А также с всякими фоновыми воркерами и дефернутыми джобами. Чтобы лучше масштабироваться, шустрее работать и удобнее/проще программировать это все. > А в ядре этот CRC32 вообще скорее всего для использования в дровах. Дровах, всяких протоколах, чексумы ФС и проч. И это все тоже - heavily threaded нынче, если кто еще не понял. В том числе и потому что заняться счетом CRC или чем там сможет в ряде случаев _другое_ ядро нежели вон тот heavy lifting. В мире где у процов уже по 256 ядер - это аргумент. Так что кернел не может игнорить размер контекста, большой контекст все нагибает. А сможет ли кто крутить GPU в разные стороны 1000 раз в секунду - я б вообще посмотрел на этот номер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #162

156. Сообщение от Аноним (156), 29-Окт-24, 19:26	+/–
Crc32 или crc32c
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #170

158. Сообщение от Аноним (-), 29-Окт-24, 19:28	+1 +/–
> Это для нонешних хм... программерофф он "дико оверинженернутый" :) Вон то уже попахивало obsolete повадками - годике так в 2005 наверное. А тут, вот, нашлась какаха которая жрала почти 4 кило ради того чтобы все ... немного притормозить?! :)) А нашлась она поди потому что супер-скоростное IO появилось - и у народа стали появляться вопросы - мол, а чего счет примитивных чексум такой % проца то жрет? Ну вот видимо кто-то запустил профайлер и сделал выводы :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #167

159. Сообщение от Аноним (-), 29-Окт-24, 19:33	+/–
> Ну как старые програмизды написяли мы уже видим) > Проблема же не в оверинжениринге, а в том что это лабуда еще > и тромознутая. Такая оптимизация актуальна только для in-order CPU без спекулятивщины, и даже там вымывание кеша такой простыней может внести коррективы. Ибо если мы 100500 циклов ждали оперативу, дальнейшее улучшение счета на 5% мало что меняет. А чем жирнее кот тем менее вероятно что всегда будет только cache hit без ожидания RAM фиг знает сколько (DRAM даже от in-order ядер сильно отстает сейчас).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

161. Сообщение от Аноним (-), 29-Окт-24, 19:37	+/–
> Для себя год назад закрыл тему с CRC32 Очередной самописный велосипед? Хотя... это было вполне ожидаемо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #149

162. Сообщение от Аноним (162), 29-Окт-24, 19:48	+/–
Crc32 or crc32c
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

163. Сообщение от Аноним (-), 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 строк кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

164. Сообщение от _ (??), 29-Окт-24, 19:51	+/–
> А то какое-нибудь btrfs им как чексумой ФС пользуется Хмм ... ну да, написано у них в доке что дефаулт - CRC32, но можно поменять ... кто и в-правду бтр гоняет, что скажете, меняете на BLAKE2b или нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #185

165. Сообщение от _ (??), 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ообщить модератору
Родитель: #153 Ответы: #176

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

168. Сообщение от _ (??), 29-Окт-24, 20:27	+/–
Тут судить не берусь. Оно ж как говорят ындейцы - фор вхум хау!(С) ... Ну разве что - "это красиво"(С) :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

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

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

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

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

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

175. Сообщение от Аноним (-), 29-Окт-24, 21:26	+/–
> А то, для чего ты хочешь его пользовать ... так уже миллион > лет есть да хоть blacke* ! Чего есть? Если это чукотское название Blake2 и проч, оно производительное только по меркам криптографических чексум типа SHA256, где и правда оно дает ему мастеркласс. Но CRC32 куда быстрее считается. Криптографии надо достаточно раундов для сильной диффузии, чтобы нельзя было инверсию сделать, упрощенными вычислениями. CRC32 не имеет таких ограничений, и - вот - легко костылится в старое значение 4 байтами "поправки". > , раз уж ты любитель прогресса, то будь последователен, как минимум! :) Как максимум XXHASH какой сравнивать можно. И то основной аргумент за него - 64 бита. Так что вероятность ложняка на битых данных - ниже. Но он тоже не является криптографически стойким, и таки - медленнее CRC32 (в среднем считается 1.4x slower примерно). > Основная фишка CRC32 - что оно реализуется даже на контроллере стиральной машинки Основная фишка CRC32 - что он достаточно быстрый с 1 стороны и неплохо ловит определенные классы ошибок с другой. И никаких особых прорывов в теориях CS на тему hamming distance, полиномов и тому подобного - с тех пор не происходило, внезапно. Так что это все ваши личные бредни. А CRC32 сейчас довольно много где в ходу до сих пор. По моему зипархивы до сих пор его по дефолту юзают для проверки целостности файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #188

176. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #165 Ответы: #189

177. Сообщение от Аноним (-), 29-Окт-24, 21:45	+/–
> Не порвут но там где CRC32 ещё применяется ... окажется что там они _тянут_ ... :) Тянут что? Питание из питальника? Можете посчитать blake2 для энтерпразйного SSD - посмотрим сколько проца это сожрет. Разложить btrfs на энтерпрайзный SSD - вероятно обычные будни обычного фэйсбука с его 2 млрд юзерей. > У меня студень лет 5 назад на питоне сделал, Тут такой уровень что даже комментировать неудобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #190

178. Сообщение от Аноним (-), 29-Окт-24, 21:53	+/–
> Зачем информировать? Затем что переключалка - в non-voluntary preempt приходит сама. Берет поток за шкирку и вытряхивает, освобождая место другому потоку. В тот момент времени когда шедулер посчитает это уместным по своим шедулерским соображениям. А такие точки как правило привязаны к хардварным таймерам и их прерываниям. Ну а если шедулер не информировать - откуда он знает кто там какие регистры юзал, он весь контекст кантует для безусловного поддержания иллюзии что задачу никто никогда не прерывал, что бы она там не делала. > Просто отключаем прерывания, сами сохраняем, и сами восстанавливаем, > и включаем прерывания обратно. Ох, вау, нечто типа кооперативной многозадачности - с запрещенными прерываниями? Хайтек уровня винды 3.11? Вместо честной многозадачки то? :) > CRC - быстрая операция, подождут. Быстрая операция по сравнению с чем? И для какого объема? И точно железо без прерываний столько подождет без нежелательных эффектов типа packet loss и проч? А конкретно ядро линя куда более продвинуто это все делает, опять же с тредингом и дефером тяжелых операций, так что bulk работы делает тушка не отвисающая в IRQ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #180

179. Сообщение от Аноним (179), 29-Окт-24, 22:15	+1 +/–
Да. Но публичный скандал разразился после. Примерно в июле текущего года. До этого были отдельные разрозненные сообщения что «как–то оно слишком плохо всё, думал лучше будет». Intel удавалось морозиться, кормить отдельных пользователей завтраками (у п*арщиков это называется crisis–management) и обещаниями исправления микрокода. После того как замалчивать проблему стало более невозможно, всё покатилось как снежный ком — протраченный контракт на чипы для PS6, оглушительное падение стоимости акций, массовые увольнения, сброс активов и сворачивания проектов. Так что трясти какими–то там показателями за прошлый год, как минимум, странно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #182, #192

180. Сообщение от Аноним (180), 29-Окт-24, 23:53	+/–
>Быстрая операция по сравнению с чем? И для какого объема? Для сетевого пакета. Кто обрабатывает в ядре гигабайты, используя его механизмы "доверенной загрузки" для энфорсинга DRM - тот сам виноват, и на его нужды вообще можно забить. >И точно железо без прерываний столько подождет без нежелательных эффектов типа packet loss и проч? А железу то что? Оно знай себе в буфер кладёт, без всякого участия процессора. Разумеется, если кольцевой буффер заполнится, то будет потеря пакетов. Но это неизбежно даже при включённых прерываниях. Отключая прерывания на время вычисления и юзая SIMD мы просто торгуем часть гарантированной латентности на в обмен на негарантированную оную (но в большинстве случаев - такую же), зато с высоким throughput.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #183

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

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

183. Сообщение от Аноним (183), 30-Окт-24, 03:02	+/–
>>Быстрая операция по сравнению с чем? И для какого объема? > Для сетевого пакета. А в каких пакетах ядро CRC32 для сетевых пакетов оптом само вот именно CRC32 считает, чтобы такие извраты ради этого терпеть? > Кто обрабатывает в ядре гигабайты, используя его механизмы "доверенной > загрузки" для энфорсинга DRM - тот сам виноват, и на его > нужды вообще можно забить. Лично меня напрягает превращение ос в какую-то уродскую кооперативную многозадачку без IRQ во имя призрачного выигрыша в некой фигне - нужной хз кому и зачем. При чем тут пассажи про DRM я не понимаю. В каком месте CRC32 помогает или мешает DRM - фиг его знает, не улавливаю логическую цепочку. > А железу то что? Оно знай себе в буфер кладёт, без всякого > участия процессора. А вон то для каких пакетов вообще? А то в эзернете как я помню сетевухи обычно сами считают CRC фрейма и дропают его если он какой-то не такой, накручивая соотв счетчики. В сетевых протоколах именно CRC32 именно в пакетах не особо частая штука. В TCP - чексумы но это не CRC32 а нечто более линейное насколько я помню. > вычисления и юзая SIMD мы просто торгуем часть гарантированной латентности на > в обмен на негарантированную оную (но в большинстве случаев - такую > же), зато с высоким throughput. Не понимаю для какого случая профит вообще наступить должен, зато догадываюсь что латентность профакается. Впрочем на серверах как раз порой юзают 100Hz тики если латенси меньше. Как раз чтобы радикаьлно снизить число переключений контекста. Это однако не значит что увеличить размер контекста офигенная идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

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

185. Сообщение от Аноним (-), 30-Окт-24, 03:17	+/–
>> А то какое-нибудь btrfs им как чексумой ФС пользуется > Хмм ... ну да, написано у них в доке что дефаулт - > CRC32, но можно поменять ... кто и в-правду бтр гоняет, что > скажете, меняете на BLAKE2b или нет? Чтобы проц то в 30 раз тормознуть счетом чексум? Всенепременно. Для "обычных" нужд как то заметить гнилой шнурок, проц, планку памяти, девайс, контроллер и проч - CRC32 хватает, в общем то. Единичные битовые ошибки CRC32 вообще гарантировано ловит. Проблемы могут быть только если ожидается откровенная труха оптом, там конечно за энное число попыток - пробьет и пролезет наружу. Если это актуальное соображение, можно и blake2 конечно. Но это достаточно специфичная ситуация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

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

187. Сообщение от Аноним (144), 30-Окт-24, 14:12	+/–
> Не с "дохрена", а только с задействованных. А "незадействованных" не существует. Если какие-то регистры не используются тобой, то наверняка они используются тем, кто тебя вызвал. Ну и, естественно, тем потоком, на который тебя поменяет планировщик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

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

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

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

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

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

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

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

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

196. Сообщение от Аноним (196), 30-Окт-24, 23:19	+/–
> Чего там на страрых? Cortex-A53 же in-order. И их ещё полно, где > используется. И в сетевых девайсах тоже, ага, CRC32. На них модуль crc32c-pcl-intel немножечко не загружают/используют. Почему-то. Может быть, потому что интеловый асм Cortex A никогда не умел, например? :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

197. Сообщение от Аноним (-), 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. А что, Интел, незамениымх на этом глобусе не бывает. Думали, нельзя обойтись без фирмы Интел? Экие наивные господа. Моторола тоже так думала. И где ее процы теперь? Да еще откровенные затыкания рта кастометрам на явно дефективные серии процов, вот, как-то все заметили. Или как быстро и эффективно слить бренд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

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

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