Вы не понимаете, это мы, гики, смотрим на устройство под техническим углом и не видим посредственность. А вот настоящие «видящие будущее» люди первого класса понимают, что главное в ноутбуке — это то, что он не бежевого цвета.
Знаете, по моему вы уже доказали, что вся дискуссия вам нужна только чтобы подтведить известную, как вам кажется, истину.
Я дискутирую из-за того, что Вы пришли и облили грязью вполне нормальный и достаточно широко используемый компилятор. Причем по сути отсутствие автоматического жонглирования ветками условий является единственным высказанным Вами валидным аргументом, да и то это решаемая проблема, хоть решение порой и ведет к усложнению кода. И я ведь не говорил, что мол MSVC всем голова, а Clang выкинуть на помойку — нет, это Вы пришли и затеяли холивар.
А свои галлюцинации про лужи, мушкетеров и что там у Вас еще — лучше оставьте при себе. Если же они обостряются, советую жаловаться специалисту, а не интернет-форуму.
Подумайте — были бы все эти заморочки нужны, если бы разработчики могли, как вы говорите, просто правильно указать все эти likely/unlikely.
Люди могут просто правильно работать с памятью, зачем managed-платформы/семантика владения как в Rust?
Люди могут просто не допускать логических ошибок, зачем тестирование?
Продолжать можно до бесконечности.
Вообще-то там это пишут только про вариант с PGO.
А про вариант без PGO там ни слова. Да и вообще там ни слова про то, что MSVC как-то хуже Clang'а, просто им Clang по инструментарию большие импонирует. Так что Вы пока что наедине со своим MSVC-хейтом.
Согласно вашей логике сравнивать время поездки на поезде и на самолёте некорректно, потому что один летает, другой ездит.
Да, поезд и самолет решают одну и ту же задачу. Но как они связанны между собой, кроме как тем, что и то и то — транспорт?
И MSVC (без PGO) делает это настолько плохо (вы собственно сами описали как), что likely/unlikely ему помогают как мёртвому припарки.
Во-первых, ну не выполняет MSVC такие оптимизации — поменяйте ветки местами и забудьте. Во-вторых, Ваш оптимальный Clang'овский код протухнет как только я решу вызывать эту функцию исключительно от нулевого аргумента. Так что если уж считать циклы, то все равно придется каждый такой момент самому продумать.
Еще можете в примере поменять int на int64_t и прочувствовать необъятную гениальность Clang'а.
PGO — это оптимизация на основе тестовых запусков, likely/unlikely — оптимизация на основе знаний программиста. Из общего тут только оптимизация.
Если вы используете MSVC, то вначале нужно перейти на нормальный компилятор (clang, например, как Google сделал), а потом уже начинать заботиться об микрооптимизациях. Уже хотя бы тот факт, что в MSVC нет поддержки ассемблера для x64 уже ставит крест на всех долях процента, которые вы можете выиграть с помощью микрооптимизаций класса likely/unlikely.
Громкое заявленьице, хорошо бы оно было нормально аргументировано. По Вашей ссылке пишут, что производительность Chrome с MSVC и Clang примерно одинакова; ассемблерные вставки в обычных ситуациях не нужны, их отсутствие в MSVC конечно удручает, но гораздо больше успокаивает тем, что всякие ассемблерные умники не испортят ими код. К тому же, не поддерживаются именно вставки, линковку с asm файлами никто не отменял.
там и код, вроде, не идиоты пишут, и каждый патч проходит через несколько ревьюеров. И всё равно портачат.
Steven Rostedt has been looking at the problem using the annotated branch profiler and found ten places «that really do not need to have an annotated branch, or the annotation is simply the opposite of what it should be».
10 мест на все ядро? Мда, похоже на проблему тысячелетия.
Likely/unlikey вообще никак к PGO не относятся. И я писал именно о сравнении кода с этими атрибутами и без — он может быть идентичным. Например, MSVC, насколько я знаю, всегда располагает if-ветку выше else — строите условие таким образом, что if-ветка является likely, и никакие атрибуты не нужны. С unlikely условием без else чуть сложнее — вроде как мне помогала изоляция ветки в функцию/лямбду.
Ну и по угадыванию — не согласен, человек разрабатывает алгоритм, и он в первую очередь сам понимает, какая ветка когда будет выполняться; а вот компилятор об алгоритме знает сильно меньше и действительно пытается угадать. Так что в очевидных случаях ставить эти атрибуты можно и нужно, а в неочевидных — да, лучше вообще их не ставить, так как даже если угадаешь — выигрыш будет незначительным.
Насколько я знаю, конкретно предсказание не улучшит никак, может лишь повлиять на исполняемый код — насколько я знаю, компилятор сделает такой условный jump, который не выполняется для likely-случая, и сразу после него поставит likely-ветвь выполнения. Таким образом, обычно переход не будет выполняться, и мы вроде как должны получить те самые «jne not-taken» тайминги с одного из графиков. Но вообще именно разницы между вариантом с likely/unlikely и без может и не быть, так как компилятор сам не дурак и вполне может генерировать идентичный код без них.
В итоге может возникнуть ситуация, что побеждает такой игрок, кто лучше запомнил, как ходить в первоначальных позициях.
Это нормальная ситуация, которая возникнет в любом варианте шахмат при условии того, что игроки остаточно профессионалы.
Хорош ли такой маневр в целом для игры? Думаю, да, очень хорош.
ИМХО в целом для игры это просто ужасно. Такая возможность превращает проходные и пешки, проведенные дальше пятой горизонтали в огромную опасность — думаете, кто-то вообще станет разменивать пешки и вскрывать игру в таких условиях?
Ну и если Вы придумали новый вариант шахмат, то первое что нужно сделать — реализовать свой набор шахмат в stockfish'е и убедиться что начальная позиция хоть немного сбалансированная (я вот не уверен), особенно учитывая, что статья публикуется на IT-ресурсе.
Верно, будет более чем в 4 раза быстрее. Потому как не просто в 4 раза меньше пикселей обрабатывается, но для каждого пикселя меньше придется семплов делать (так как радиус семплинга обычно примерно пропорционален размерам экрана).
Какие конкретно оптимизации? Я не знаю архитектур, в которых есть нативная поддержка 128-битных вычислений, но даже если такие и найдутся — что мешает ввести intrinsic-функции как в C++?
Плюс атомарная поддержка записи/сохранения без специальной магии
Эмм, атомарность чтения/записи памяти разного размера и выравнивания гарантируется архитектурой процессора. Что за гарантии тут предоставляет Rust?
Создать аналог движка — это сейчас практически непосильная задача, и во многом благодаря рекламной корпорации, которая уже многие годы содействует расширению и усложнению необходимого для поддержки функционала. Так что может Vivaldi и не зрят в корень проблемы, но как минимум жалобы идут в правильном направлении.
В C++ в принципе с массивами нулевой длины есть неудобства. Они вызывают варнинг, который мне всегда приходится отключать прагмой, когда объявляется такой массив. Насколько я понимаю, это из-за того, что в C++ объект не может иметь нулевой размер.
На счет size_t — ну так это правильный тип для размера в памяти, надо приведение — просто пару букв дописать. А вот sizeof(a)/sizeof(a[0]) выглядит архаично, так и не скажешь, дружит ли оно с выравниванием, ну и есть это:
Да, проверил в MSVC — размер std::array<int, 0> равен 4-ем байтам. С другой стороны, я знаю лишь один вариант использования массивов нулевой длины, и в этом случае std::array не подходит в принципе, нужен нативный массив.
В остальном — вообще на много чего нет гарантий. На то что компилятор не вставит Sleep(1000) после каждой инструкции — тоже гарантии нет. Но вообще он не вставляет.
А свои галлюцинации про лужи, мушкетеров и что там у Вас еще — лучше оставьте при себе. Если же они обостряются, советую жаловаться специалисту, а не интернет-форуму.
Люди могут просто не допускать логических ошибок, зачем тестирование?
Продолжать можно до бесконечности.
А про вариант без PGO там ни слова. Да и вообще там ни слова про то, что MSVC как-то хуже Clang'а, просто им Clang по инструментарию большие импонирует. Так что Вы пока что наедине со своим MSVC-хейтом.
Да, поезд и самолет решают одну и ту же задачу. Но как они связанны между собой, кроме как тем, что и то и то — транспорт?
Во-первых, ну не выполняет MSVC такие оптимизации — поменяйте ветки местами и забудьте. Во-вторых, Ваш оптимальный Clang'овский код протухнет как только я решу вызывать эту функцию исключительно от нулевого аргумента. Так что если уж считать циклы, то все равно придется каждый такой момент самому продумать.
Еще можете в примере поменять int на int64_t и прочувствовать необъятную гениальность Clang'а.
Громкое заявленьице, хорошо бы оно было нормально аргументировано. По Вашей ссылке пишут, что производительность Chrome с MSVC и Clang примерно одинакова; ассемблерные вставки в обычных ситуациях не нужны, их отсутствие в MSVC конечно удручает, но гораздо больше успокаивает тем, что всякие ассемблерные умники не испортят ими код. К тому же, не поддерживаются именно вставки, линковку с asm файлами никто не отменял.
10 мест на все ядро? Мда, похоже на проблему тысячелетия.
Ну и по угадыванию — не согласен, человек разрабатывает алгоритм, и он в первую очередь сам понимает, какая ветка когда будет выполняться; а вот компилятор об алгоритме знает сильно меньше и действительно пытается угадать. Так что в очевидных случаях ставить эти атрибуты можно и нужно, а в неочевидных — да, лучше вообще их не ставить, так как даже если угадаешь — выигрыш будет незначительным.
ИМХО в целом для игры это просто ужасно. Такая возможность превращает проходные и пешки, проведенные дальше пятой горизонтали в огромную опасность — думаете, кто-то вообще станет разменивать пешки и вскрывать игру в таких условиях?
Ну и если Вы придумали новый вариант шахмат, то первое что нужно сделать — реализовать свой набор шахмат в stockfish'е и убедиться что начальная позиция хоть немного сбалансированная (я вот не уверен), особенно учитывая, что статья публикуется на IT-ресурсе.
Эмм, атомарность чтения/записи памяти разного размера и выравнивания гарантируется архитектурой процессора. Что за гарантии тут предоставляет Rust?
На счет size_t — ну так это правильный тип для размера в памяти, надо приведение — просто пару букв дописать. А вот sizeof(a)/sizeof(a[0]) выглядит архаично, так и не скажешь, дружит ли оно с выравниванием, ну и есть это:
В остальном — вообще на много чего нет гарантий. На то что компилятор не вставит Sleep(1000) после каждой инструкции — тоже гарантии нет. Но вообще он не вставляет.
Еще имеете право ночью по бандитским районам гулять. Пойдете?