Здравствуйте, netch80, Вы писали:
V>>Английским по-белому написано, что если ты установил буфер сокета в нулевой размер, то важно порождать более одной асинхронной перекрывающейся операции. V>>ИМХО, и без доки это должен подсказывать обычный здравый смысл, не? N>Ты отвечаешь на другой вопрос, не о смысле overlapped.
ХЗ, может быть.
Я когда впервые более-менее всерьёз на это смотрел в начале 2000-х, понял именно так, что можно посылать перекрывающиеся запросы к одному хендлу.
Например, тогда IOCP еще не было популярным на клиенте, прямо по доке на клиентской стороне рекомендовалось использовать completion routines, т.е. в APC-очередь потока, из которого инициируется асинхронная операция, пихались колбэки от завершённых overlapped-операций. Там тоже докой гарантируется очередность прихода колбэков в случае нескольких одновременных запросов к одному хендлу.
Кстате, до середины 2000-х дотнетный асинхронный сокетный ввод/вывод работал поверх completion routines в текущем контексте синхронизации, это уже потом переписали на completion ports + пул потоков.
N>Всё равно не понял. Ладно, не так важно сейчас, подумаю на совсем досуге.
А чего там понимать?
К сокету обычно привязана некая структура/объект через поле epoll_event::data.
Эту структуру ты выделил из памяти динамически или расположил в поле другого объекта.
Цикл опроса сокетов за раз выгребает энное кол-во экземпляров epoll_event, берёт поле data, преобразует к указателю на известный тип (свой тип у каждой такой библиотеки или в низкоуровневом аналогичном самописном коде), затем у этой структуры берёт адрес колбэка, берет из неё же параметр void * user_data и вызывает этот колбэк с параметрами epoll_event::events и user_data. Ну или вызывает виртуальный метод объекта, если такая структура является ООП объектом, в этом случае user_data не нужен.
Загвоздка заключается в том, что если даже из другого потока ты вызвал epoll_ctl с требованием преркащения обслуживания твоего хендла, или если ты вообще закрыл хендл, ты не можешь быть уверен, что в потоке опроса epoll событие уже не прочитано в массив событий, т.е. рано или поздно до него может дойти очередь и колбэк, таки, будет вызван.
В общем, такая обвязка должна гарантировать, что вызванный колбэк не будет дёргать уже удалённую память.
Тут каждый извращается как может.
Подход Boost.Asio мне не кажется самым эффективным, зато он достаточно "дебелый" для большинства сценариев, т.е. способов совершить ошибку меньше.
Но зато в каких-нить своих "вылизанных" фреймворках можно сделать чуть эффективнее, но тогда "обвязка" должна быть достаточно умной, чтобы уметь отслеживать жизненный цикл хендлов и связанных с ним объектов из произвольных взаимных сценариев, возникающих м/у потоками.
Здравствуйте, ·, Вы писали:
_>>>>Правильно. И раньше его можно применять, а можно было не применять. А сейчас выбора нет — оно просто недоступно. _>>·>Осталось обосновать, что такой выбор нужен для стандартного класса. _>>Ты вот всё время пытаешься сделать вид, что разница только в дефолтном поведение стандартного класса, но на самом деле разница совсем в другом. При старой схеме у тебя было дефолтное поведение ссылки и в одну строчку ты мог получить из него поведение копирования. А в современной схеме у тебя дефолтное поведение копирования, но получить из него поведение ссылки нет никакой возможности. ·>Всегда есть возможность сделать свою имплементацию с блекджекомsso и ссылками.
Свой вариант — это совсем не то. Там помимо того, что это надо самим писать, ещё и не передашь его ни в какие функции, требующие string. Старый вариант тем и был хорош, что по сути было доступно два поведение одного и того же класса. Лучше этого только вариант из плюсов, в котором для этих целей две отдельные сущности (и при этом весь остальной код (включая и сторонние библиотеки) рассчитан принимать и ту и другую).
_>>Именно эту разницу (отсутствие возможности выбора в современной схеме) я и критикую. Так то мне тоже кажется более логичным дефолтное поведение копирования для базовых строк. Однако это только в том случае, если при этом есть возможность получить ссылку. Если же такого нет, то лучше уж старая схема. Ну во всяком случае для профессионалов, а не для обезьянок... ·>Она не лучше, т.к. создаёт больше проблем, чем решает.
Единственная возможная проблема от такой схемы — пожелание наличия мозга у программиста... Но да, похоже в некоторых областях индустрии это действительно проблема. )))
·>Ты попробуй придумай хоть какой-то более-менее правдоподобный сценарий, когда новая схема создаст заметную проблему. И позапускай на старой и новой jdk, сравни скорость.
Скорость старого в любом случае будет выше на работе с подстроками. Однако это действительно вряд ли будет именно что ЗАМЕТНОЙ проблемой, на фоне так сказать общей унылой производительности.
·>И чтобы было совсем интересно — придумай так, чтобы оно не фиксилось таким же тривиальным образом.
Как ты себе представляешь "пофиксить" время, затрачиваемое на ненужное копирование строк? )
_>>В смысле зачем? Это в одну строчку убирает описываемую тобой проблему (с удержанием в памяти гигантского куска текста из-за пары букв). Ну а то, что это надо указывать руками, а не по дефолту — так это цена за возможность использования ещё и ссылок. ·>Поговорка есть такая. Умный находит решение проблемы, мудрый — проблему не создаёт.
В принципе если продолжить эту мысль, то и сами Java/C# не нужны в принципе, т.к. есть например Питон. )
_>>Premature optimization — это совсем другое, ты путаешь. В данном случае оптимизация вполне однозначная и для всех случаев (O(N) vs О(1)). ·>Ты как маленький... Никогда не встречался на практике, когда O(много) работает лучше O(мало)?
Да, такое вполне реально во многих случаях при малых значениях N. Поэтому в правильных тестах контейнеров и т.п. всегда приводят набор результатов для разных N.
Однако в обсуждаемом нами случае, это очевидно не актуально, т.к. копирование одного указателя и двух целочисленных значений очевидно всегда будет быстрее чем выделение нового буфера под строку и посимвольного копирования в него изначальной строки.
_>>Так какие могут быть проблемы при переходе от константной ссылки к копированию? ) Очевидно что никаких, кроме потери производительности естественно. ·>Потеря производтельности — тоже проблема, обычно.
Безусловно. Но в мире Java изначально (ещё при создание языка) пожертвовали ею ради безопасности. И продолжают эту традицию дальше во всех мелочах. Так что данное решение по изменению реализации было вполне себе в духе Java.
_>>Но с производительностью в Java и так всё настолько печально, что ещё небольшое ухудшение (ради спокойного сна обезьянок) точно никто не заметит. ))) ·>Ага-ага.
Именно так. Собственно только ради этого данный язык и создавался и именно за это (за возможность нанимать толпы дешёвых, взаимозаменяемых программистов) его очень любит крупный бизнес.
_>>·>Нет, это позазывает другое назначение этого класса. Есть другие типы контейнеров на случай, если тебе в каком-то случае станет важным алгоритмическая сложность. _>>Да? ))) Тогда может покажешь у каких контейнеров из документации Java указаны значения алгоритмической сложности? ·>Да много где, особенно в коллекциях. Первый попавшийся пример — ArrayList: "The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking)."
А, ну ОК, признаю что пропустил это место (смотрел на функции, а не на общее описание класса). Но это никак не отменяет моего вывода относительно отсутствия этих данных для string.
Здравствуйте, ·, Вы писали:
_>>Хы, ну ты же сам понимаешь, что у нас тут соревнование не людей, а компиляторов. Поэтому используя другой (упрощённый под конкретную задачу) алгоритм, ты не можешь говорить о качестве работы компилятора (в общем случае такое упрощение не сработает). Это если говорить именно о сравнение производительности. _>>Если же вернуться к совсем начальной теме (использование SIMD), то такой результат опять же ни о чём не говорит, потому как значения порядка 5 секунд характерны для максимально оптимизированного не SIMD кода (во всяком случае компилятор C++ с выключенной автовекторизацией выдаёт значения именно такого порядка). ·>Изначально тема была заявлена как: "А уж про неявное подключение SIMD даже к целочисленным групповым операциям и говорить нечего — сегодня никто так не умеет, кроме нейтивных технологий", а не про качество работы компилятора.
Ну это было не моё утверждение — я бы не стал так обще утверждать, т.к. не пробовал "всё на свете" (мало ли что там кто насоздавал). Однако если говорить про конкретные технологии (типа Java/C#/JS/Python и т.д.), то вполне можно утверждать, что пока не научились SIMD.
·>Выяснилось, что jvm умеет в simd, притом оставаясь в рамках safe/managed.
Это где такое выяснилось? Во всяком случае явно не на обсуждаемом нами моём тесте.
·>Но таки да, умеет не очень хорошо, к сожалению, и даёт заметное преимущество только в каких-то простых случаях.
До идеального SIMD кода и gcc/icc пока не доросли. В отличие от скалярного кода, в котором даже профи руками уже вряд ли напишет оптимальнее чем компилятор. Думаю что со временем такое будет и с SIMD, но пока ещё работать и работать...
Здравствуйте, vdimas, Вы писали:
V>>>Значит, там не требуется посадить на один порт несколько независимых приложений. _>>Ээээ что? Вообще то это как раз самая основная деятельность nginx. Его собственно обычно и конфигурируют в стиле: _>>- для такого-то хоста и такого-то Url: oтдать статику из такой-то папки V>Это не есть "приложение". _>>- для такого-то хоста и другого Url: перенаправить запрос (через WSGI или FastCGI или что-то подобное) такому-то локальному приложению V>И это не есть "приложение", это ф-ии роутера.
Какая разница через роутер или нет, если в результате по факту на одном порту (скажем 80-ом) работают сразу несколько разных приложений, включая и сам nginx (раздающий статику)?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>то из этого возможно сделать только один непротиворечивый вывод: видимо саму Windows предпочитают не использовать для высоконагруженных серверов. НС>Ну это говорит только о твоей способности делать выводы. А в реальности изначально nginx под винду не было. А когда появился — сам же автор писал что там тупой экспериментальный порт с линукса и на винде оно быстро работать не будет.
Это ты пытаешься объяснить почему ngnix медленнее работает на винде (если предположить что это твоё утверждение верно). А я говорю о совсем другом:
если он действительно медленнее и при этом винда подходила бы для использования в нагруженных системах, то очевидно что данные в общей статистике были бы совсем другие (народ в индустрии же не дебилы). Но там у нас на первом месте nginx, причём с большим отрывом, так что или твоё утверждение не верно или же сама винда не используется для подобных задач.
Здравствуйте, ·, Вы писали:
I>>Пример неудачный. Если твоя функция выполняется то за секунду, то за час, то за день, в зависимости от погоды, то по твоим слова всё в порядке — беспокоиться не надо. Ну раз гарантии только госстрах даёт. ·>Для этого делают перф-тесты и покрывают условия эксплуатации и нефункциональные требования. В чём твой тезис-то?
А читать ты не умеешь ?
·>Ты хочешь сказать, что запилив что-то c sso ты сможешь гарантировать, что твоя функция не будет выполняться за день? Даже если твой облачный сервак уйдёт в suspend или, банально, придёт терабайт данных?
При чем здесь ССО ? Ты отказаваешь от гарантий но зачем то предлагаешь писать тесты. Если нету гарантий — какие могут быть тесты ?
На самом деле гарантии нужны всегда, а не только в реалтайме.
В обычном приложении ты обеспечиваешь гарантии, что софтина выполняет функциональные и нефункциональные требования. И в требованиях, например, нагрузка с которой справляется приложение.
Вся разница с реалтаймом — в нефункциональных появляется требование навроде времени отклика.
Здравствуйте, alex_public, Вы писали:
_>>>Ты вот всё время пытаешься сделать вид, что разница только в дефолтном поведение стандартного класса, но на самом деле разница совсем в другом. При старой схеме у тебя было дефолтное поведение ссылки и в одну строчку ты мог получить из него поведение копирования. А в современной схеме у тебя дефолтное поведение копирования, но получить из него поведение ссылки нет никакой возможности. _>·>Всегда есть возможность сделать свою имплементацию с блекджекомsso и ссылками. _>Свой вариант — это совсем не то. Там помимо того, что это надо самим писать, ещё и не передашь его ни в какие функции, требующие string. Старый вариант тем и был хорош, что по сути было доступно два поведение одного и того же класса. Лучше этого только вариант из плюсов, в котором для этих целей две отдельные сущности (и при этом весь остальной код (включая и сторонние библиотеки) рассчитан принимать и ту и другую).
Ты просто воспринимаешь String как универсальный всемогутер. Это класс общего назначения, применяемый много для чего самой jdk. И с практической точки зрения гораздо выгоднее когда он работает, пусть даже чуть медленнее (ты кстати, это ещё никак не доказал), чем падает с ООМ. Те места, где поведение такого класса вызывает проблемы с производительностью — всегда можно найти и подпилить. С практической точки зрения гораздо выгоднее и безопаснее ускорять работающую программу, чем чинить падующую.
_>>>Именно эту разницу (отсутствие возможности выбора в современной схеме) я и критикую. Так то мне тоже кажется более логичным дефолтное поведение копирования для базовых строк. Однако это только в том случае, если при этом есть возможность получить ссылку. Если же такого нет, то лучше уж старая схема. Ну во всяком случае для профессионалов, а не для обезьянок... _>·>Она не лучше, т.к. создаёт больше проблем, чем решает. _>Единственная возможная проблема от такой схемы — пожелание наличия мозга у программиста... Но да, похоже в некоторых областях индустрии это действительно проблема. )))
Не пожелание мозга, а необходимость на пустом месте напрягать мозги.
_>·>Ты попробуй придумай хоть какой-то более-менее правдоподобный сценарий, когда новая схема создаст заметную проблему. И позапускай на старой и новой jdk, сравни скорость. _>Скорость старого в любом случае будет выше на работе с подстроками.
Строгли белив, короче.
Ты не учитываешь много нюансов. Например, такие подстроки могут переползать между тредами убегая из TLAB, начать удерживать куски памяти слишком долго и всё это дело уползёт в медленный Old Generation. А если ещё вспомнить какие-нибудь нежданчики типа копирования между numa и прочая locality... В итоге, в одном месте вроде как заоптимизировали, зато потом это вылилось в тормоза в другом месте. В итоге сумма оказалась отрицательной. Ты как первый раз...
_>·>И чтобы было совсем интересно — придумай так, чтобы оно не фиксилось таким же тривиальным образом. _>Как ты себе представляешь "пофиксить" время, затрачиваемое на ненужное копирование строк? )
Убрать ненужное копирование строк, например. Или использовать StringBuilder.
_>>>В смысле зачем? Это в одну строчку убирает описываемую тобой проблему (с удержанием в памяти гигантского куска текста из-за пары букв). Ну а то, что это надо указывать руками, а не по дефолту — так это цена за возможность использования ещё и ссылок. _>·>Поговорка есть такая. Умный находит решение проблемы, мудрый — проблему не создаёт. _>В принципе если продолжить эту мысль, то и сами Java/C# не нужны в принципе, т.к. есть например Питон. )
Ы?
_>>>Premature optimization — это совсем другое, ты путаешь. В данном случае оптимизация вполне однозначная и для всех случаев (O(N) vs О(1)). _>·>Ты как маленький... Никогда не встречался на практике, когда O(много) работает лучше O(мало)? _>Да, такое вполне реально во многих случаях при малых значениях N. Поэтому в правильных тестах контейнеров и т.п. всегда приводят набор результатов для разных N.
Хорошо, но уже лучше. Теперь если подумать, действительно ли это хорошя идея иметь String для больших значений N? Ведь даже в Плюсах ты задумаешься о вменяемости такого кода, скорее всего возьмёшь std::vector или типа того.
_>Однако в обсуждаемом нами случае, это очевидно не актуально, т.к. копирование одного указателя и двух целочисленных значений очевидно всегда будет быстрее чем выделение нового буфера под строку и посимвольного копирования в него изначальной строки.
Стронгли белив. Кстати, буферы копируются не посимвольно.
_>>>Так какие могут быть проблемы при переходе от константной ссылки к копированию? ) Очевидно что никаких, кроме потери производительности естественно. _>·>Потеря производтельности — тоже проблема, обычно. _>Безусловно. Но в мире Java изначально (ещё при создание языка) пожертвовали ею ради безопасности. И продолжают эту традицию дальше во всех мелочах. Так что данное решение по изменению реализации было вполне себе в духе Java.
В данном случае это лишь твой стронгли белив, что пожертвовали.
_>>>Но с производительностью в Java и так всё настолько печально, что ещё небольшое ухудшение (ради спокойного сна обезьянок) точно никто не заметит. ))) _>·>Ага-ага. _>Именно так. Собственно только ради этого данный язык и создавался и именно за это (за возможность нанимать толпы дешёвых, взаимозаменяемых программистов) его очень любит крупный бизнес.
Даже если это и так, то не понимаю, почему ты так говоришь, как будто это что-то плохое.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>- для такого-то хоста и другого Url: перенаправить запрос (через WSGI или FastCGI или что-то подобное) такому-то локальному приложению V>>И это не есть "приложение", это ф-ии роутера. _>Какая разница через роутер или нет
Разница в эффективности.
Де-факто сетка в линухах и так медленная, а тут еще лишние пересылки.
Здравствуйте, Ikemefula, Вы писали:
I>·>Ты хочешь сказать, что запилив что-то c sso ты сможешь гарантировать, что твоя функция не будет выполняться за день? Даже если твой облачный сервак уйдёт в suspend или, банально, придёт терабайт данных? I>При чем здесь ССО ? Ты отказаваешь от гарантий но зачем то предлагаешь писать тесты. Если нету гарантий — какие могут быть тесты ? I>На самом деле гарантии нужны всегда, а не только в реалтайме. I>В обычном приложении ты обеспечиваешь гарантии, что софтина выполняет функциональные и нефункциональные требования. И в требованиях, например, нагрузка с которой справляется приложение. I>Вся разница с реалтаймом — в нефункциональных появляется требование навроде времени отклика.
Верно. "в приложении", "нефункциональные требования". Ты просто контекст потерял. Обсуждение было вот:
V>1. Нет у тебя никаких гарантий, что GC разместит рядом в памяти ключи и значения из одной хеш-таблицы.
У — Логика. "может быть быстрее" != "гарантированно всегда быстрее".
А вообще, за гарантиями — к госстраху. А какие гарантии, что твоё "более правильное решение" [примечание: тут имеется в виду ССО] даст прирост производительности?
Тут у меня потребовали гарантии увеличения производительности от одной из техник gc, хотя ССО "даёт гарантии" ничем не лучше. Ты точно уверен, что твои возражения и нравоучения всё ещё по теме? Или мы опять будем обсуждать "your misunderstanding of what I think"?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>(заметь, уплотнены x, а не y, как по ссылке) V>>·>По ссылке уплотняется ArrayList, а точнее, если посмотришь его устройство — Object[]. Т.е. точно так же будет уплотнятся и твой x[]. V>>Ты действительно не понял, в каких случаях для map выгодно использовать простой массив? ·>Я не понял к чему ты это всё рассказываешь.
К тому, что ты даёшь ссылки на буллшит.
·>Чем простой массив для map проще массива в hash-table или в ArrayList с т.з. уплотнения?
У-у-у, как всё запущено. ))
·>Ты просто споришь сам с собой, отвечая на вопросы, которые тебе никто не задавал и выдаёшь информацию вообще не в тему.
Ты вообще кто такой, чтобы единолично ставить вопросы или задавать тему?
Или, тем более, модерировать, насколько в русле будет ответ оппонента?
Ничего там не жмёт?
И что ты не понял здесь:
озвучивая свои заблуждения вслух, вы сами формулируете проблематику — "раскрыть внутренее устройство алгоритмов и/или структур данных".
Ты запостил сюда чушь.
Тебе объясняют, в чём именно там чушь.
Причём, объясняют вполне вежливо, доходчиво, с аргументами.
Потому что, если включить объективность, то достаточно было просто напомнить, что уплотнение происходит при уборке 2-го поколения, а уборка второго поколения может не вызываться часами даже на серверной стороне. После этого посмотреть на тебя как на неразумное дитя: "Не, ну видели? Видели?", покрутить пальцем у виска и забыть о существовании какого-то невмеяемого юноши, который носится со своим невежеством по всем форумам как с писанной торбой и пристаёт ко взрослым дядькам с очередной какой-то херней, не имеющей отношения к реальной жизни.
Нет же. Тебя терпеливо выслушивают, терпеливо пишут ответы.
Поправляют, подсказывают.
И только ты тут холерично реагируешь: "я этого не справшивал, а вот этого тоже не надо было мне рассказывать" и т.д. и т.п.
Ты вообще кто такой, чтобы решать, что тебе ДОЛЖНЫ отвечать оппоненты? ))
Тебе отвечают ликбезом на провалы.
Говори спасибо и молча переваривай.
Переваришь — приходи за новой порцией.
Здравствуйте, vdimas, Вы писали:
V>·>Ты просто споришь сам с собой, отвечая на вопросы, которые тебе никто не задавал и выдаёшь информацию вообще не в тему. V>Ты вообще кто такой, чтобы единолично ставить вопросы или задавать тему?
Если ты хочешь обсуждать поставленные в теме вопросы, обсуждай. Если ты хочешь ставить новые — иди в другую тему. А заниматься софизмом, отвечая свои же вопросы потоком тривиальщины в попытках сойти за умного — это ведёт к непониманию.
V>И что ты не понял здесь: V>
V>озвучивая свои заблуждения вслух, вы сами формулируете проблематику — "раскрыть внутренее устройство алгоритмов и/или структур данных".
Т.е. ты сам придумал вопрос, сам ответил. Я тебе не мешаю?
V>Потому что, если включить объективность,
Вот наконец-то что-то касающееся темы обсуждения. Непонятно почему это было нельзя сказать сразу? Тебе не лень было набирать все те портянки фуфла? Мой тебе совет — не отключай объективность.
V>то достаточно было просто напомнить, что уплотнение происходит при уборке 2-го поколения,
В той статье Шипилёва это и говорится, что мол, после срабатывания GC результаты другие. О поколениях вообще разговора у нас не было. Если ты это забыл или не прочитал... я-то тут причём? А в телепатию я не умею, уж извини.
Но в общем случае всякое бывает. Во-первых, это зависит от типа GC и настроек. Во-вторых, даже для "обычного" GC уплотнение произойдёт уже при копированиях в Eden/Survivors, ещё до 2го поколения.
Вот тут более детальное описание что и когда происходит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Хы, ну ты же сам понимаешь, что у нас тут соревнование не людей, а компиляторов. Поэтому используя другой (упрощённый под конкретную задачу) алгоритм, ты не можешь говорить о качестве работы компилятора (в общем случае такое упрощение не сработает). Это если говорить именно о сравнение производительности. _>>>Если же вернуться к совсем начальной теме (использование SIMD), то такой результат опять же ни о чём не говорит, потому как значения порядка 5 секунд характерны для максимально оптимизированного не SIMD кода (во всяком случае компилятор C++ с выключенной автовекторизацией выдаёт значения именно такого порядка). _>·>Изначально тема была заявлена как: "А уж про неявное подключение SIMD даже к целочисленным групповым операциям и говорить нечего — сегодня никто так не умеет, кроме нейтивных технологий", а не про качество работы компилятора. _>Ну это было не моё утверждение — я бы не стал так обще утверждать, т.к. не пробовал "всё на свете" (мало ли что там кто насоздавал). Однако если говорить про конкретные технологии (типа Java/C#/JS/Python и т.д.), то вполне можно утверждать, что пока не научились SIMD.
Java таки чуть-чуть научилась. Кому-то повезло(?) и оно дало преимущество в реальном коде.
Вот тут микробенчмарки... непонятно насколько полезны в реальности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали: A>>- мой вариант C#: 4,6с _>Похоже на правду, хотя и чуть подправленный у тебя там алгоритм (оригинальный будет всё же порядка 5 секунд). Ну и надо отмечать, что это unsafe код, а safe вариант работает больше 10 секунд.
Что ты к unsafe привязался? Safe-вариант C++ работает больше 20 секунд, если таковым считать отладочный билд с разными проверками. A>>- похожий C# в Unity: 2,6с _>А вот тут у тебя уже совсем другой алгоритм (более простой для SIMD оптимизации). И если запустить его аналог на C++ (см. предыдущее сообщение), то будут совсем другие результаты (и на моей машине и на твоей).
Алгоритм там везде один и тот же: перебрать все ячейки и каждую неравную FFFFFF заменить на среднее значение восьми её соседей. Идея сравнивать, как себя ведёт одинаковый до буквы код в разных языках, мне непонятна. Есть входные данные и есть представление, как должны выглядеть выходные. Берёшь в руки конкретный язык с его инструментами и с их помощью трансформируешь.
Вот · на Яве подошёл к проблеме кардинальнее, принципиально изменив порядок действий. И честно говоря, правильно сделал. Задача любой программы ― трансформировать одни данные в другие данные. Если программа работает правильно и быстро, каким образом она этого достигает, никого парить не должно. Можно лишь завидовать.
По оптимизациям, там в результате какая-то длиннющая лапша из SSE и AVX. Ни малейшего представления, что вообще происходит. Но если исходный код цикла немного помассировать, можно получить ещё два варианта: простейший тупой на «обычных» регистрах (буквально десяток операций) и ещё один, по сути как предыдущий, но на SSE-регистрах. Эти два варианта отличались от лучшего на несколько десятых секунды и признаков векторизации в них не замечено. (Если конечно мне показывали правильный дизасм). _>Для gcc и clang любых версий и под любыми ОС правильными опциями для подобных тестов будут: -std=c++17 -march=native -O3.
Core i5-2500K @4,5ГГц / DDR3 1333 МГц
-gcc: 6,0c
H:\Users\Alex\Desktop\CPP>g++ --version
g++ (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
— msvc: 5,2с (компилировал в Студии, Favor Speed (/Ox), какие были остальные ключи — не поручусь)
— icc: 4,6с
Интеловский сегодня скачал на посмотреть. Он сам интегрировался в Студию, код компилировался там же с ключом -O3; между -O1 и -O3 разница была явно заметна в пользу -O3. За остальные не поручусь. Разных тонких настроек там до чёрта, и хз надо их трогать или нет. _>Ну пока что из принципиальных различий я вижу замену if'а на некий math.select — это было обязательно делать? Неужели такая базовая операция как if запрещена? Или это ты сделал не вынужденно, а для нечестной оптимизации (см. ниже)?
Чего не честный-то? Я не понимаю логику. Если у тебя в С++ ?: работает быстрее if, зачем искусственно замедлять собственный код? Не всё ли равно, с какой скоростью в каком-то условном Коболе будет работать оператор ?: и есть ли он там вообще. Мне лично плевать. Надо сделать быстрее ― берёшь и делаешь быстрее, без оглядки на посторонних.
Конкретно math.select — интринзик, если может, мапится в blendvps или типа того, если не может, то
/// <summary>Returns b if c is true, a otherwise.</summary>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static int select(int a, int b, bool c) { return c ? b : a; }
_>Ну и главное по этому твоему коду (который HPC#): это другой алгоритм (более толерантный к SIMD) и если ты хочешь использовать его именно в таком виде (тот if в моём тесте там совсем не просто так был, а как одна из сильно напрягающих SIMD оптимзиацию конструкций), то тогда уж надо и у других языков поменять.
Я обеими руками за то, чтобы на всех языках писать так, как наиболее эффективно писать в этих языках. Если вариант на C++ можно сделать в несколько раз быстрее, его надо сделать в несколько раз быстрее. Будет сравнение не сферических коней, а настоящего кода, и по нему можно будет ориентироваться.
Кстати, у меня замена if на ?: дала нулевой эффект. Проверил на всех четырёх компиляторах. Если и есть изменения, то в сотых долях секунды.
А, не, это я дебил. Воткнул ?: внутрь if. Перепроверил:
— gcc: 2,6 вместо 6,0
— clang: 6,1 вместо 6,0
— msvc: 5,4 вместо 5,2
— icc: 4,6 ― без изменений
На всякий случай код
#include <iostream>
#include <vector>
#include <chrono>
using namespace std;
constexpr int COUNT=1000;
int Test(vector<int32_t>& image, int height)
{
auto start=chrono::high_resolution_clock::now();
auto buf=image;
const int width=image.size()/height;
for(int n=0; n<COUNT; n++){
for(int y=1; y<height-1; y++){
const auto s=image.data()+y*width;
const auto d=buf.data()+y*width;
for(int x=1; x<width-1; x++)
{
int sum = (s[-width+x]+s[x-1]+s[-width+x-1]+s[-width+x+1]+s[width+x-1]+s[width+x]+s[x+1]+s[width+x+1])>>3;
d[x] = s[x]!=0xffffff ? sum : d[x];
}
}
for(int y=1; y<height-1; y++){
const auto s=buf.data()+y*width;
const auto d=image.data()+y*width;
for(int x=1; x<width-1; x++)
{
int sum = (s[-width+x]+s[x-1]+s[-width+x-1]+s[-width+x+1]+s[width+x-1]+s[width+x]+s[x+1]+s[width+x+1])>>3;
d[x] = s[x]!=0xffffff ? sum : d[x];
}
}
}
return chrono::duration_cast<chrono::milliseconds>(chrono::high_resolution_clock::now()-start).count();
}
int main()
{
constexpr int width=1600, height=900;
vector<int32_t> image(width*height);
//начальная инициализация для получения такой же забавной картинки, как и в браузереfor(int i=0; i<width; i++) image[i]=0xffffff;
for(int i=0; i<width; i++) image[(height-1)*width+i]=0xffffff;
for(int i=0; i<height; i++) image[width*i]=0xffffff;
for(int i=0; i<height; i++) image[width*i+width-1]=0xffffff;
for(int i=width/2-100; i<width/2+100; i++) image[width*height/2+i]=0xffffff;
for(int i=height/2-100; i<height/2+100; i++) image[width*i+width/2]=0xffffff;
cout<<"Calculation time:\t"<<Test(image, height)/1000.0<<"s.\timage[12345]="<<image[12345]<<endl;
return 0;
}
_>Кроме этого, я вижу что работа идёт с некими NativeArray, а не стандартными .net массивами. Хотя это естественно не минус, но код всё же явно требует ручного портирования, а не просто некой перекомпиляции.
NativeArray ― это struct-обёртка над памятью, типа Span<T>/Memory<T>, но со встроенными защитными механизмами раннего отлова потенциальных race conditions. Например, если в одном потоке такой массив помечен атрибутом только для чтения, а в другом разрешён для записи, и если потоки не были правильно формально синхронизированы, то NativeArray гарантирует, что код мгновенно упадёт с объяснением, в каком месте проблема, в чём заключается и как исправить. Даже если потоки разошлись по времени и в данный момент проблемы как бы нет; достаточно лишь теоретической вероятности гонки. Или, допустим, потоки могут читать/писать в один и тот же массив, но каждый только в свою область; если поток по ошибке заденет чужую, то сразу стоп машина и красный флаг. Реально полезная штука.
В принципе, числодробилка может принимать на вход обычные управляемые массивы; если хочет, делать себе поверх них NativeArray<T>, безопасно работать с ними во множестве потоков, а результаты будут отображаться в исходные массивы. Пока не пробовал, но по идее можно работать и со Span<T>/Memory<T>, так даже универсальнее, чем только с массивами, но менее безопасно, чем с NativeArray<T>.
Здравствуйте, ·, Вы писали:
V>>·>Ты просто споришь сам с собой, отвечая на вопросы, которые тебе никто не задавал и выдаёшь информацию вообще не в тему. V>>Ты вообще кто такой, чтобы единолично ставить вопросы или задавать тему? ·>Если ты хочешь обсуждать поставленные в теме вопросы, обсуждай. Если ты хочешь ставить новые — иди в другую тему. А заниматься софизмом, отвечая свои же вопросы потоком тривиальщины в попытках сойти за умного — это ведёт к непониманию.
Это если голову не включать.
Например, часто массивы используются как indexed map, в этом смысле "уплотнение" по ссылке, скорее всего, всё ухудшит в сравнении с исходной последовательностью создания объектов при наполнении такого массива.
Я всё время забываю, что ты не воспринимаешь и половины даваемой тебе тривиальнейшей информации. ))
Приходится на пальцах.
Простой пример — в массиве содержатся отображения горизонтальной таблицы парсера или лексера после минимизации, т.е. отображения терминалов на некие объекты — нетерминалы.
Для лексера x = char, y = nterm.
Наиболее выгодно с т.з. хитов в память расположить y таким образом, чтобы сначала шли наиболее часто встречающиеся нетерминалы, потом всё реже и т.д., т.е. отсортировать в памяти согласно некоему прикладному знанию о характере обрабатываемых данных.
Но GC такой информацией не обладает, т.е. тупо отсортирует y согласно x, т.е. просто по алфавиту в этом примере.
ИМХО, тут даже объяснять особо ничего не надо, если голова на месте.
Как только тебе начинают рассказывать о некоей фиче, которая "сама" что-то делает, не обладая инфой о прикладном характере происходящего, так сразу должна включаться как минимум осторожность в рассуждениях.
Я же вижу строго обратное.
Т.е., "играя" инфой, умалчивая одни аспекты и выпячивая другие, ты ведешь де-факто некорректный спор.
Сознательно вводишь коллег в заблуждение.
Приходится за тобой прибирать, бо многие коллеги (и я в том числе) ходят сюда за пополнением своей технической эрудиции.
Ты же гонишь сплошное недостоверное фуфло.
V>>озвучивая свои заблуждения вслух, вы сами формулируете проблематику — "раскрыть внутренее устройство алгоритмов и/или структур данных". ·>Т.е. ты сам придумал вопрос, сам ответил.
Э, нет, "вопрос" придумал ты, ввиду недостаточности выдаваемой инфы о происходящем.
Независимо от того, по незнанию ли ты выдаёшь неполную инфу, или преднамеренно с целью спекуляций, раскрыть подробности происходящего будет полезным делом.
А вот юлить, бегать, оправдываться — бесполезным.
V>>Потому что, если включить объективность, ·>Вот наконец-то что-то касающееся темы обсуждения. Непонятно почему это было нельзя сказать сразу?
Ты пока на первый аргумент так и не смог адекватно ответить, а уже просишь следующих. ))
Это как с той "разметкой памяти", ты 10 постов не мог воткнуть в суть исходного вопроса, что тебе уже читатели замечания стали делать.
Не понял вопроса или аргумента — переспроси, а не возражай своим непониманием.
Ты же всё-равно тут аноним, "реноме" пострадает не сильно.
V>>то достаточно было просто напомнить, что уплотнение происходит при уборке 2-го поколения, ·>В той статье Шипилёва это и говорится, что мол, после срабатывания GC результаты другие.
У GC несколько этапов "срабатывания".
В фазе перемещения объектов stop world есть всегда, независимо того, какая конкретная стратегия GC используется.
У навороченных просто длительность одного stop world меньше, за счёт того, что самих их гораздо больше и общая производительность падает.
·>О поколениях вообще разговора у нас не было. Если ты это забыл или не прочитал... я-то тут причём? А в телепатию я не умею, уж извини.
Походу ты плохо понимаешь логику современных разработок, которые долгоиграющие и которые "на виду", как грится.
Ведущие разработчики таких проектов ОБЯЗАНЫ вести блоги.
Более того, если ты не умеешь вести "интересные" блоги, шанс попасть в ведущие разработчики/руководители подобных проектов резко ниже.
Такова се ля ви.
Чувак в основном занят написанием тестовых фреймворков.
(офигенно интересная работа, угу )
Периодически получает какие-то там результаты и добровольно-принудительно пишет обо всём этом "интересные" статьи.
И тут такой ты, натыкаешься на подобную добровольную принудиловку и показываешь реакции вчерашнего слепого щеночка, только что увидевшего солнце — рот открыл и застыл в немом удивлении. ))
Пффф...
Отключать критичность, таки, не следует, когда речь об инженерии.
·>Но в общем случае всякое бывает. Во-первых, это зависит от типа GC и настроек. Во-вторых, даже для "обычного" GC уплотнение произойдёт уже при копированиях в Eden/Survivors, ещё до 2го поколения. ·>Вот тут более детальное описание что и когда происходит.
Бггг...
It’s an old joke from the time when Java was new and slow compared to other languages. Over time, Java became a lot faster.
По отношению к самой себе тогдашней.
Но и конкуренты стали намного быстрее.
В общем, автор сразу задал верный стиль, "взбодрил", такскаать.
Сразу начал с той чуши, которой сто лет в обед и которую я примерно раз в три года проверяю и получаю примерно те же относительные результаты.
Fortunately, in many cases, it can be tweaked and optimized to improve performance.
И это в той подветке, где обсуждается невозможность управления трюком, о котором рассказано в предыдущей твоей ссылке.
Эдак тебя колбасит...
Ты сам хоть свои ссылки читаешь? ))
И вишенка на торте:
Let’s try another experiment. Let’s run an application that is only creating short-lived objects in multiple threads.
...
We can see that this time, the old generation received objects right after the first minor garbage collection.
...
The young generation garbage collector had no choice but to push these objects to the old generation. This is bad because the objects that got pushed to the old generation were prematurely aged and can only be cleaned up by old generation’s major garbage collection which usually takes more time.
О чём я тебе несколько раз уже напоминал только в одной этом обсуждении, что стоит начать "бесконечно" производить объекты в разных потоках, и объекты улетают во 2-е поколение сходу. Этим страдает дотнет. Как видишь, этим страдает и джава тоже.
А дальше начинается и вовсе детсад:
How to prevent premature aging of short-lived objects? There are several ways.
И рассказываются способы, как тюнить GC.
Страна непуганых идиотов.
Или професиональных лжецов — на выбор.
Я склоняюсь ко второму.
Потому что стоит накатить "оттюненые" параметры GC на другое железо — с другим кол-вом ядер, другим кол-вом кеша 0-го и 1-го уровней в проце, другой длиной линейки кеша (а она "пляшет" от 64 байт то 512 байт) и всем, что прежде натюнили, можно смело подтереться.
А если еще какие-нить приложения на том же железе работают, или не работают, или имеют апериодическую нагрузку, то и вовсе это был булшит с самого что ни на есть начала.
Здравый смыл и простая инженерная честность видит такие вещи сходу.
И только профессиональные лжецы с умным видом кидают ссылки на такую же ложь и высокомерно (как им самим кажется) изрекают: "пойдите ознакомьтесь".
Это же палево, не?
А вдруг, действительно, ознакомятся?
Здравствуйте, alex_public, Вы писали: _>Да геймдев — это вообще отдельный мирок в сообществе C++, который характеризуется весьма сомнительными особенностями (любовь к VS, любовь к велосипедам и ещё много чего), которые в других областях оставили в прошлом ещё десятилетие назад. На эту тему недавно было большое обсуждение. Точнее был некий коллективный вопль из мира геймдева и потом разбор его ошибочности во многих местах. Например тут https://habr.com/ru/post/435036/ можно увидеть довольно адекватное мнение — рекомендую к прочтению.
Прочитал. Противоположную сторону уже читал раньше. Я не сильно глубоко в теме, так просто наблюдаю. Мои несерьёзные впечатления:
Скрытый текст
― Чуваки! у нас тут, кажется, проблема.
― Ваша проблема не наша про... Вы вообще кто?
Проблема: дико тормозящие отладочные билды, отсутствие нормальных инструментов отладки.
Решение: вы там зажрались на Windows; привыкайте писать сразу без ошибок и тестировать-тестировать-тестировать; нет отладки — нет проблемы отладки.
Проблема: очень долгая компиляция и с каждой версией всё дольше
Решение: залить деньгами и нанять ещё людей, разве ж это проблема?
Проблема: остальной инструментарий надо собирать по сусекам из говна и палок (ну образно).
Решение: уж какой есть! пользуйтесь тем что есть или лепите сами из спичек и желудей, все так делают.
Проблема: стандартные библиотеки громоздки, скорость пляшет между разными реализациями, легче написать собственный велосипед, чем из-за какой-то ерунды тянуть в проект десятки тысяч строк ненужного никому кода (смотри проблему долгой компиляции).
Решение: нет, всё нормально, вы преувеличиваете (также смотри решение проблемы долгой компиляции).
Резюме:
1. Не нравится — не пользуйтесь, пишите как деды писали. Только у вас всё равно не получится. Ха-ха.
2. Не нравится — заявите о себе. Что? где? в интернете? Ну вы, блин, даёте! Головой подумайте, где интернет, а где С++. Вам надо подъехать в офис нашего комитета и написать заявление на имя начальника нашего комитета, затем регулярно посещать собрания нашего комитета на протяжении периода, установленного уставом нашего комитета, и тогда наш комитет возможно изучит вероятность рассмотрения вашего заявления. Обязательно возможно изучит. Всё равно вы полезным ничем не заняты, только в игрушки играете.
Здравствуйте, ·, Вы писали: ·>Ансейф это возможность машинной проверки инвариантов, например, выход за границы массива или системы типов. Если ты используешь ансейф, то у тебя эта проверка пропадает. Скажем, ты решил написать unsafe quicksort, чтобы range check не мешался. Сделал "mid = (lo + hi) / 2" — поклялся на библии, что range check не нужен и... Оппа!
Вы как-то однобоко понимаете unsafe. Это во-первых.
Во-вторых, проверка никуда не пропадает. Вот в этом коде проверок границ массива ровно столько же, сколько и без unsafe:
var a = new int[100];
var s = 0;
var r = new Random(42);
unsafe
{
for(var i=0;i<99;i++)
s+= a[r.Next(100)];
}
unsafe всего лишь разрешает использовать определённые конструкции, которые без unsafe запрещены.
S>>Далее, важно учитывать, что ансейф — это по-прежнему управляемый код. И джит его "видит", и вполне себе оптимизирует. То есть если в джите есть автовекторизация (а в дотнете её пока нет), то она будет работать как для операций с массивами, так и для операций с указателями. ·>С другой стороны — операции с указателями сложнее и поэтому их труднее оптимизировать.
·>Погоди... Оно же тоже юзермод. Мы вроде кернелмод vs юзермод сравниваем. Я верю, что можно сделать http-сервер быстрее nginx, но не верю, что для этого необходим кернелмод.
Ну так я и говорю — что по вашей ссылке изложена история, когда кернелмодный TUX проиграл юзермодному nginx, который ещё и не самый быстрый юзермодный http сервер.
Какие выводы мы должны из этого сделать?
По вашей ссылке делается вывод "кернел-мод перформансу не помогает". Я высказыаю гипотезу "кернел мода сама по себе перформанса не добавляет; ей надо уметь пользоваться".
Строго так же, как ансейф.
S>>В винде тоже. Там, где это оправдано. ·>Чем оправдывается http в кернелмоде?
Возможностью отдавать данные, не выходя в юзермод. Юзермодные драйвера пишут там, где всё равно присутствует переключение контекста — и чем больше работы мы выносим из кернелмоды в юзермод, тем больше мы получаем гибкости и надёжности.
S>>Ну и что? Это же всё ортогонально кернелмодности драйвера. Вон, в линухах нашли в прошлом году уязвимость в libSSL. ·>Это меняет степень риска. Даже прав рута может быть недостаточно для того, чтобы установить хакнутый kernel module, если secure boot работает. Если через публичный, видимый всему интернету порт http можешь выполнять любой код с правами ядра — это совсем другая история.
Я недостаточно квалифицирован для конструктивного продолжения данной ветки. В любом случае в мир смотрит какой-то кернелмодный драйвер. Уберёте http.sys — найдут дыру в tcpip.sys, делов-то.
S>>первое что нагуглилось. ·>Это практически неэксплуатируемо в реальном production-окружении. Это надо чтобы оно тянуло пекеджы без ssl и ещё и mitm суметь организовать. А вот как защитить 80-й порт веб-сервера?
Ну при этом по обоим CVE винды есть ровно 0 использований. То есть парни работают, дыры латают.
S>>>>Архитектура дотнета позволяет нам сделать этот вызов, просто запинив строку и передав указатель на первый символ. S>>·>Круто. Но, повторю вопрос — накой оно в коре? Откуда FindFirstFileW на линухах? S>>А что, линуховые C-style API устроены как-то иначе? ·>Конечно. Как минимум там нет usc2 обычно, как правило utf-8. Или скажем, readdir требует стркутуру DIR, в которой имя внутри char[256] — копировать придётся в любом случае.
Ну тогда да, неоправдано. Ошибки молодости, чож. ·>Нет, важна не частота и "лишние" затраты, а общее влияние на производительность. ·>И memory footprint тоже сам по себе не обладает абсолютной ценностью. Тут же компромисс — удобный простой дешевый в разработке поддержании код vs цена планки памяти.
Совершенно верно. Поэтому нам важна возможность писать hi-performance код на "основном" языке, без перепрыгиваний между C#/C++/asm вставками, не переписывая при этом половину стандартной библиотеки, и не перемешивая "прикладной" код с кодом "фреймворка".
S>>Но как-то затруднительно. ·>Вот у vdimas проси
, ему не затруднительно, из него так и прёт, даже когда никто не просит.
·>А _насколько_ дорого? Ведь он скорее всего будет branch predicted и на фоне остальных полезных действий в итоге затеряется. Это должно очень не повезти с задачей, чтобы эффект range check был больше десятка процентов. Зато avx позволяет ускорять в разы.
Ну вот на моём CPU почему-то branch prediction нихрена не помогает. Код C4-фильтрации 2d массива интов при убирании проверок границ ускоряется примерно в 2.7 раза; а вот добавление avx не помогает.
Не исключаю, что я его просто не сумел правильно приготовить — так и не дошли руки подключиться и посмотреть реальный ассемблер, который там генерируется.
S>>Если мы напишем парсер, скажем, json на современной яве — сможет ли он выиграть от применения avx512? Сможет ли JDK автоматически свернуть "обычный" java-код в avx512? Будет ли этот java-код всё ещё оптимальным для случая альтернативной архитектуры проца, или всё же лучше его подпилить руками так, чтобы он шустро работал и на intel, и везде? ·>Да, современные jvm умеют сворачивать код в avx512, правда плохо и слабо предсказуемо. И, уверен, при достаточном опыте и удаче можно сделать json-парсер, использующий такие оптимизации.
Ну, либо пойти в дотнет, и нарулить код на Vector<byte>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали: _>Может моя фраза на нормальном русском языке показалась какой-то сложной? ) Попробую тогда переформулировать тоже самое более математически — может так зайдёт? ) И так очевидные факты:
_>1. любой ?: можно записать через if _>2. любой if нельзя записать через ?: (более того, даже для тех случаев, когда это возможно в теории, оптимизатор не факт что заметит это) _>3. операция ?: записывается в одну ассемблерную инструкцию (без всяких прыжков по коду, характерных для ветвлений) как для скалярного кода, так и для векторного. Однако если для скалярного случая не всё так однозначно (ветвление на процессорах Intel выполняется быстрее, а вот на AMD наоборот), то для векторного ветвление означает ужас ужас ужас. )))
Ваше рассуждение №3 означают, что оптимизатор С++ конвертирует прямо C++ syntax tree в ассемблерные инструкции, что меня очень сильно удивляет. Не говоря уже о том, что я настолько давно не занимался ассемблером, что не могу сходу вспомнить, о какой инструкции для ?: идёт речь.
Я ожидал, что компилятор всё же делает какую-то трассировку значений; при трассировке у нас все присваивания в d[x] приобретают форму ?:, а уже потом мы смотрим, какой код для этого породить.
Там же много всего — и common subexpression evaluation, и loop invariant, и прочее.
В любом случае, большое спасибо за подробные пояснения. Буду иметь в виду
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Может моя фраза на нормальном русском языке показалась какой-то сложной? ) Попробую тогда переформулировать тоже самое более математически — может так зайдёт? ) И так очевидные факты: _>1. любой ?: можно записать через if _>2. любой if нельзя записать через ?: (более того, даже для тех случаев, когда это возможно в теории, оптимизатор не факт что заметит это)
SSA сейчас используется в: GCC, Clang, MSVC начиная с 2015 (если не врут)...
Берём два примера кода, просим выхлоп в текстовой форме LLVM.
int f(int a, int b, int c) {
return a ? b : c;
}
int f2(int a, int b, int c) {
if (a) {
return b;
}
else {
return c;
}
}
clang -S -emit-llvm -O tbr1.c, и видим (шапку и хвост файла — срезал):
Разумеется, если бы под if было бы что-то более сложное, то он бы так не сэкономил. Но дело в том, что phi, получаемая в SSA при слиянии потоков команд, по любому объединяет все изменяемые переменные, так что тут такой select получается естественным образом.
Это к тому, что "оптимизатор может не заметить". Ему в принципе при SSA невозможно это не заметить, хотя можно сломать, если он решит, что при слиянии можно обойтись без модификации одной стороны.
f2 полностью совпадает с этим, естественно
_>3. операция ?: записывается в одну ассемблерную инструкцию (без всяких прыжков по коду, характерных для ветвлений) как для скалярного кода, так и для векторного. Однако если для скалярного случая не всё так однозначно (ветвление на процессорах Intel выполняется быстрее, а вот на AMD наоборот), то для векторного ветвление означает ужас ужас ужас. )))
Где "ужас ужас ужас"? Просто надо разделять две ситуации:
1. Если ветвление производится для выбора значений векторной операции одинаково для всех в обработанной группе. Например, ты через AVX2 (256 бит) обрабатываешь 4 double (64 бита), но условие для всех одинаково.
Тогда подходят обычные команды. И от того, что вокруг векторных операций возникают ветвления — сами эти операции ничуть не искажает. Ну да, надо учесть, что операции дороже (там, где дороже — как AVX2 на многих моделях делается как 2*128 последовательно).
2. Если ветвление в таком векторе делается раздельно для каждого значения.
Тогда, да, его заменяют на генерацию масок по условиям и слияние двух результатов по этим маскам.
Вот тут может оказаться, что операции очень дорогие, настолько, что оптимизатор не согласен их делать для обоих вариантов, или есть какие-то нежелательные побочные эффекты.
Если он эти эффекты не может выделить, он выключает векторизацию.
Вот намеренно простой пример, как такое условие и перегон по маске выполняется.
Здравствуйте, alex_public, Вы писали:
_>если он действительно медленнее и при этом винда подходила бы для использования в нагруженных системах, то очевидно что данные в общей статистике были бы совсем другие
Или LB на винде не делают, предпочитают микролинукс. Тупо из-за цены.
В чём твой тезис-то?
)
