Я не нашел это таким важным, кроме как обмениваться идеями, и я работаю в критических областях производительности (трассировка лучей, обработка изображений и сеток, системы частиц, физические движки и т. Д.), И мне пришлось разрабатывать множество собственных алгоритмов и структур данных. при работе в НИОКР. В этих областях часто очень эффективные структуры данных и алгоритмы могут привести к появлению совершенно новых передовых продуктов, в то время как вчерашние алгоритмы делают существующие продукты устаревшими, поэтому всегда нужно стремиться делать что-то более эффективно. Однако, как предостережение, я никогда не публиковал никаких статей по разработанным мной алгоритмам. Все они были частными. Если бы я это сделал, мне понадобилась бы помощь математика, чтобы сформулировать доказательства и так далее.
Тем не менее, по моему мнению, объем вычислительной работы за итерацию часто представляет более непосредственный интерес, чем масштабируемость алгоритма, если алгоритм действительно плохо масштабируется. Если кто-то придумает передовую технику для трассировки лучей, меня больше интересуют вычислительные техники, такие как представление и доступ к данным, а не алгоритмическая сложность, потому что разумная масштабируемость уже дана в этом конкурентном и инновационном сценарии. Вы не можете быть конкурентоспособными, придумывая алгоритмы, которые не масштабируются.
Конечно, если вы сравниваете квадратичную сложность с линейной, это огромная разница. Но большинство людей в моей области достаточно компетентны, чтобы избегать применения алгоритма квадратичной сложности на эпических входах. Так что масштабируемость часто подразумевается, и более значимые и интересные вопросы становятся такими: «Использовали ли вы GPGPU? SIMD? Работает ли он параллельно? Как вы представляли данные? Вы реорганизовали их для моделей доступа к кешу? Как сколько памяти это займет? Может ли он надежно справиться с этим делом? Вы откладываете определенную обработку или делаете все это за один раз? "
Даже линейный алгоритм может превзойти алгоритм линейного времени, если первый обращается к памяти по более оптимальному шаблону, например, или лучше подходит для многопоточности и / или SIMD. Иногда даже линейный алгоритм может превзойти логарифмический алгоритм по этим причинам, и, естественно, алгоритмы с линейным временем превосходят логарифмические по малым входам.
Поэтому для меня важнее то, что некоторые люди могут назвать «микрооптимизацией», такими как представления данных (макеты памяти, шаблоны доступа с разделением горячих / холодных полей и т. Д.), Многопоточность, SIMD и иногда GPGPU. В области, где каждый уже достаточно компетентен, чтобы использовать достойные и передовые алгоритмы для всего с постоянно публикуемыми новыми статьями, ваше конкурентное преимущество в победе над алгоритмическими волшебниками заключается не столько в улучшении алгоритмической сложности, сколько в более прямой вычислительная эффективность.
В моей области доминируют блестящие математики, но не всегда те, кто знает вычислительную стоимость того, что они делают, или множество низкоуровневых приемов для ускорения кода. Как правило, это мое преимущество перед ними в разработке более быстрых и надежных алгоритмов и структур данных, несмотря на то, что я гораздо менее изощренный. Я играю с тем, что нравится аппаратному обеспечению, с битами и байтами и делаю каждую итерацию работы намного дешевле, даже если я выполняю на несколько итераций больше работы, чем действительно сложный алгоритм - работа в моем случае значительно дешевле. Код, который я пишу, также намного проще. Если люди думают, что микрооптимизированные версии простых алгоритмов и структур данных трудно понять и поддерживать,
В качестве базового примера я предложил простую структуру сетки, которая в итоге превзошла KD-дерево в нашей компании по обнаружению столкновений и удалению избыточных точек. Моя глупая грубая сетка была гораздо менее изощренной алгоритмически, и я намного тупее математически и алгоритмически, чем парень, который реализовал KD-дерево с его новым способом нахождения средней точки, но я просто настроил использование памяти моей сеткой и шаблоны доступа и этого было достаточно, чтобы превзойти что-то более сложное.
Еще одно преимущество, которое позволяет мне выживать в области, где доминируют люди, намного умнее меня, - это просто понимание того, как работает пользователь, поскольку я использую программное обеспечение, которое разрабатываю таким же образом. Это дает мне идеи для алгоритмов, которые действительно очень быстро соответствуют интересам пользователей. Как основной пример, большинство людей пытаются ускорить такие вещи, как обнаружение столкновений, используя пространственную индексацию. Почти пару десятилетий назад я сделал простое наблюдение за формированием карьеры для органических моделей: например, если персонаж кладет руки на лицо, структура пространственной индексации должна разделять узлы и делать дорогие обновления, если персонаж затем убрал руку с лица. Если вместо этого вы разбиваете на основе данных подключения, а не позиции вершин, вы можете получить стабильную иерархическую структуру, которая обновляется очень быстро и не нуждается в разделении или перебалансировке дерева (нужно только обновлять ограничивающие рамки в каждом кадре анимации) ... что-то вроде этого - алгоритмы, не имеющие большого математического опыта мог бы придумать, если бы они просто поняли основную концепцию, но те, которые ускользали от математиков, поскольку они не думали о вещах так близко к тому, как работают пользователи, и слишком много думали только о свойствах геометрии, а не о том, как геометрия был широко использован. Я достаточно хорошо лажу, опираясь больше на общие вычислительные и пользовательские знания, чем на алгоритмическое волшебство. Так или иначе, я действительно не нашел это настолько важным, чтобы сосредоточиться на алгоритмической сложности.
