| |
| |
| |
| 4.8, Rev (ok), 19:24, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
 А ещё замедлило и дженерик x86:
-mtune=generic -march=x86-64-v3
| | |
| |
| 5.21, Аноним (21), 21:07, 24/06/2026 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> А ещё замедлило и дженерик x86
Какое необычное нововведение от инженера интела!
| | |
| |
| 6.24, Аноним (3), 21:10, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
А вы представитель сообщества и уже предложили свои изменения ?
Думали комментарием отделаться, нет уж идите пишите!
| | |
|
|
|
| |
| |
| 5.22, Аноним (21), 21:08, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
... на 30% медленнее при сборке с опциями "-march=generic -mtune=znver5"
| | |
| |
| 6.29, Аноним (6), 23:02, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Читайте внимательнее. Ускорило intel и amd в одном тесте + замедлило intel и amd в другом.
| | |
| |
| 7.48, Аноним (21), 15:58, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ускорило на 12, замедлило на 30 :) В среднем - ухудшило результаты.
| | |
|
|
|
| 4.7, Аноним (3), 19:23, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Повышение для CPU Intel Granite Rapids/Xeon 6 на 12.7%
Повышение на 12.1% при включении в оптимизаций на CPU AMD Zen5
| | |
| |
| 5.9, Аноним (2), 19:39, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
это для теста 544.nab_r, прочитайте про тест Hint в третьем абзаце
| | |
|
|
| 3.10, Аноним (10), 19:48, 24/06/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
Да, автор изначального комментария не прочитал текст полностью, но я в голосину проорал с его комментария
| | |
| |
| 4.14, Аноним (14), 20:37, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Автор читал оригинальную переписку. Проблема обнаружилась на AMD, где представитель компании ответил, что они OK с этим.
| | |
| |
| 5.36, Аноним (36), 08:02, 25/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну с одной стороны - это даже по-корпоратски логично.
С другой - а где представители амд с ихними фиксами?
| | |
|
|
| 3.19, Аноним (21), 21:06, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> на 30% медленнее при сборке с опциями "-march=generic -mtune=znver5" | | |
|
|
| 1.13, хрю (?), 20:33, 24/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>struct processor_costs i386_cost = { /* 386 specific costs */
>struct processor_costs i486_cost = { /* 486 specific costs */
>struct processor_costs pentium_cost = {
Внушает +)))
| | |
| |
| 2.17, Аноним (17), 20:56, 24/06/2026 [^] [^^] [^^^] [ответить] | +4 +/– |  Да не, там еще и высокоуровневые оптимизации есть, правда на диалекте лиспа CO... большой текст свёрнут, показать | | |
| |
| 3.54, didok (?), 21:03, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Хорошее чувство юмора назвать препроцессорный ад диалектом Самого-Самого.
| | |
|
|
| 1.23, Bottle (?), 21:09, 24/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
То есть аппаратура стала настолько сложной, что в ней неспособны досконально разобраться даже штатные инженеры?
Как мы должны читать эту новость?
| | |
| |
| 2.25, Ivan_83 (ok), 21:35, 24/06/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Проблема в том что процессоры сильно разные, и что на одном даёт ускорение на другом приводит в замедлению.
В итоге авторы софта если совсем упарываются то могут кучу оптимизированных версий кода иметь под разные процы, а авторы компиляторов стараются делать как в среднем лучше.
| | |
| |
| 3.27, Аноним (21), 22:13, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> стараются делать как в среднем лучше
В итоге видим бенчи, в которых интел - быстрые, а амд - медленные.
| | |
| |
| 4.30, Ivan_83 (ok), 23:59, 24/06/2026 [^] [^^] [^^^] [ответить]
| +4 +/– |
Ага, особенно эпичной была история с бенчами на проце VIA, который позволял выдавать что угодно в CPUID, в итоге один и тот же бенч когда проц был "интол" работа быстрее, а когда "амудэ" то медленее.
Но всё конечно ради потребителей было сделано, ибо оптимизированный код был протестирован только на интелах, поэтому для остальных выполнялся generic код...
| | |
|
| 3.51, Аноним (51), 17:39, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Так там и интеловские процы разные и опции под каждый проц. А в итоге не хотят писать опции под каждый проц и добавляют "+3" при развёртывании макроса (хз, может там и не макрос, но не суть).
ИМХО, следующая новость будет о том, что надо ввести ещё один макрос, в котором это "+3" будет учтено для правильных случаев/архитектур.
| | |
|
| 2.26, Аноним (21), 22:11, 24/06/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> неспособны досконально разобраться даже штатные инженеры
Да, эта тенденция возникла достаточно давно уже.
| | |
| 2.32, Аноним (32), 00:04, 25/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> То есть аппаратура стала настолько сложной, что в ней неспособны досконально разобраться даже штатные инженеры?
Именно так. Последние сто лет значительная часть всех индустриальных процессов слишком сложна, чтобы в ней мог досконально разобраться один человек. Включая такие совершенно обыденые вещи как, например, очистка и доставка питьевой воды в городе-миллионнике.
| | |
| 2.53, mickvav (?), 20:31, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Там как бы нет мотивации на то, чтобы разбираться всерьез, с одной стороны, и есть мотивация не особо афишировать доступ к документам, позволяющим реально разобраться - с другой.
| | |
|
| 1.28, Tron is Whistling (?), 22:37, 24/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> имеется только одна условная конструкция, преобразуемая GCC в представление на базе CMOV. Данная конструкция выполняется достаточно редко (в 3%) и её оптимизация не влияет на производительность. При этом изменение режима генерации кода привело к побочному эффекту, замедлившему выполнение более часто выполняемого кода
Если проще: ускорение одной конструкции, характерной для одного теста, привело к замедлению всех остальных, и вылезет где попало. Вот такие "оптимизации" надо выпиливать не глядя.
| | |
| |
| 2.55, Аноним (55), 22:17, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Мне пока 12900К за глаза хватает. Вот память не вовремя поднялась в цене. Ее бы на 8000 Мгц заменить стоило бы. Приходится на 64 гигах торчать,а память тоже помогает в быстродействии.
| | |
|
| 1.38, Аноним (38), 09:09, 25/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А если "включить" голову и, невзирая на боль, подумать, то можно уяснить, что регресия наблюдается в тестах на скорость компиляции исходных кодов, что не отменяет результирующего прогресса в скорости выволнения сгенерированного кода. Это вполне логично. Если мы запускаем, например, архиватор с максимальной степенью компресии, то в скорости сжатия у нас будет регрессия, а в уменьшении размера полученного архива - прогрессия. Но и код мы компиоируем не для скорости этой компиляции, а для скорости работы этого кода, так же как и сжатие архивов мы делаем для уменьшения размера этих архивов.
| | |
| |
| 2.50, Аноним (55), 17:30, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Гентушники не согласятся. Сколько будет браузер компилироваться с зависимостями имеет значение. Это из ядра можно выкинуть лишнее, а из браузера браузерный движок не выкинешь. Собирать два часа или собирать три часа это все же разница.
| | |
| |
| 3.56, Аноним (38), 14:24, 26/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Но собирают не для того чтобы собрать за два часа, а для того чтобы потом хорошо (быстро) работало...
| | |
| |
| 4.58, Аноним (58), 18:55, 26/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Быстро работать оно будет уже с низким потреблением вероятно, если нужна реакция, а не общая производительность. Это ведь тоже важно, а то можно на малых ядрах код собирать, чтобы меньше электричества тратить. И да, такой вариант вполне адекватный. Большие ядра в работе, а малые компилируют. Это ведь не значит что компилировать пусть с половиной скорости это так уж важно. А то можно дойти до фермы на каких-нибудь атомах, которые будут код собирать на малых частотах и роутер превратится в сборочный сервер.
| | |
|
|
|
| 1.39, Аноним (39), 10:52, 25/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А, неважно! Главное, что задачки в системе закрываются и работа работается.
| | |
| |
| 2.41, Аноним (41), 11:09, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Конечно неважно. Иначе мы бы всегда имели топовое оборудование, сделанное в текущем году, а не сидели на 10 летнем старье и в х. не дули.
| | |
|
| 1.43, Аноним (43), 11:56, 25/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> тест "Hint" стал выполняться у одного из разработчиков GCC на 30% медленнее
> в коде теста Hint ... конструкция выполняется достаточно редко (в 3%) и её оптимизация не влияет на производительность.
> При этом изменение режима генерации кода привело к побочному эффекту, замедлившему выполнение более часто выполняемого кода.
Вывод неправильный? Наоборот, замедлился редко выполняемый код? И, надо полагать, ускорился часто выполняемый. Значит фикс всё-таки хороший?
| | |
| |
| 2.57, Халявщик не корпораст (?), 15:33, 26/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
 - поэтому вопросов быть не должно?
Там же однострочное улучшение.... Ну конкуренция и всё такое. А если бы он вторую строчку туда всунул бы(но он просто не захотел, ведь иженер), то это было бы не конкурентноспособная оптимизация. Ну такое там всё свободное и не свободное. Конкуренция - движуха прогресса в истроии эволюции человечества, какая абизьяна съест больше бананов за ограниченное время от той и выхлоп в окружающую среду будет больше. Ну и всё такое.
| | |
|
|
