| |
| |
| |
| 4.8, Rev (ok), 19:24, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
А ещё замедлило и дженерик x86:
-mtune=generic -march=x86-64-v3
| | |
| |
| 5.21, Аноним (21), 21:07, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> А ещё замедлило и дженерик x86
Какое необычное нововведение от инженера интела!
| | |
| |
| 6.24, Аноним (3), 21:10, 24/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
А вы представитель сообщества и уже предложили свои изменения ?
Думали комментарием отделаться, нет уж идите пишите!
| | |
|
|
|
| |
| |
| 5.22, Аноним (21), 21:08, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
... на 30% медленнее при сборке с опциями "-march=generic -mtune=znver5"
| | |
| |
| 6.29, Аноним (6), 23:02, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Читайте внимательнее. Ускорило intel и amd в одном тесте + замедлило intel и amd в другом.
| | |
|
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Да, автор изначального комментария не прочитал текст полностью, но я в голосину проорал с его комментария
| | |
| |
| 4.14, Аноним (14), 20:37, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Автор читал оригинальную переписку. Проблема обнаружилась на AMD, где представитель компании ответил, что они OK с этим.
| | |
|
| 3.19, Аноним (21), 21:06, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> на 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 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Внушает +)))
Да не, там еще и высокоуровневые оптимизации есть, правда на диалекте лиспа:
[CODE]
/* Optimize (X + (X >> (prec - 1))) ^ (X >> (prec - 1)) into abs (X). */
(simplify
(bit_xor:c (plus:c @0 (rshift@2 @0 INTEGER_CST@1)) @2)
(if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& !TYPE_UNSIGNED (TREE_TYPE (@0))
&& wi::to_widest (@1) == element_precision (TREE_TYPE (@0)) - 1)
(abs @0)))
[/CODE]
и высокоуровневое описание железок на нем же:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gcn/gcn.md
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm.md
и промежуточные представления типа GIMPLE и RTL с оптимизацией там же.
Вот на этом фоне особенно з̵а̵б̵а̵в̵л̵я̵ю̵т̵ внушают классические опеннетные разглагольствования на тему "сишечка потому и быстрая, потому что простая и любой настоящий ш̵о̵т̵л̵а̵н̵д̵е̵ц̵ погроммист может предсказать геренируемый машинный код!" 😀
| | |
|
| 1.23, Bottle (?), 21:09, 24/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
То есть аппаратура стала настолько сложной, что в ней неспособны досконально разобраться даже штатные инженеры?
Как мы должны читать эту новость?
| | |
| |
| 2.25, Ivan_83 (ok), 21:35, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Проблема в том что процессоры сильно разные, и что на одном даёт ускорение на другом приводит в замедлению.
В итоге авторы софта если совсем упарываются то могут кучу оптимизированных версий кода иметь под разные процы, а авторы компиляторов стараются делать как в среднем лучше.
| | |
| |
| 3.27, Аноним (21), 22:13, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> стараются делать как в среднем лучше
В итоге видим бенчи, в которых интел - быстрые, а амд - медленные.
| | |
| |
| 4.30, Ivan_83 (ok), 23:59, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ага, особенно эпичной была история с бенчами на проце VIA, который позволял выдавать что угодно в CPUID, в итоге один и тот же бенч когда проц был "интол" работа быстрее, а когда "амудэ" то медленее.
Но всё конечно ради потребителей было сделано, ибо оптимизированный код был протестирован только на интелах, поэтому для остальных выполнялся generic код...
| | |
|
|
| 2.26, Аноним (21), 22:11, 24/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> неспособны досконально разобраться даже штатные инженеры
Да, эта тенденция возникла достаточно давно уже.
| | |
| 2.32, Аноним (32), 00:04, 25/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> То есть аппаратура стала настолько сложной, что в ней неспособны досконально разобраться даже штатные инженеры?
Именно так. Последние сто лет значительная часть всех индустриальных процессов слишком сложна, чтобы в ней мог досконально разобраться один человек. Включая такие совершенно обыденые вещи как, например, очистка и доставка питьевой воды в городе-миллионнике.
| | |
|
| 1.28, Tron is Whistling (?), 22:37, 24/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> имеется только одна условная конструкция, преобразуемая GCC в представление на базе CMOV. Данная конструкция выполняется достаточно редко (в 3%) и её оптимизация не влияет на производительность. При этом изменение режима генерации кода привело к побочному эффекту, замедлившему выполнение более часто выполняемого кода
Если проще: ускорение одной конструкции, характерной для одного теста, привело к замедлению всех остальных, и вылезет где попало. Вот такие "оптимизации" надо выпиливать не глядя.
| | |
|