Как стать автором
Обновить
67
0
Гордый Хохол @Nomad1

Погромист игоръ

Отправить сообщение
У нас вообще NextCloud работает как оболочка для Amazon S3 — интерфейс проще, права настраиваются, можно приложение для синхронизации поставить, есть прямые ссылки. Под эту нагрузку вполне хватает бесплатного инстанса Amazon EC2, выходит хороший довесок к облачному хранилищу. До этого был Google Cloud Storage для хранилища, вот там не все хорошо со скоростью и интеграцией.
А если вообще на локальный диск его направлять, то можно о коммерческих облаках и не задумываться, если, конечно, с бекапами вопрос продуман.
А я бы пользовался таким. Мне не страшно клеймо идиота или программиста на костылях, я согласен с мыслью, что алгоритмы и оптимизации могут развиваться быстрее, чем я их изучу.
Напишу где-нибудь (x*x*3 — x*x*x*2), а мне анализатор сразу «вы изобрели smoothstep, может не делать велосипед, а взять библиотечную функцию?»
Ясное дело, в голову приходят только примеры, которые я знаю как оптимизировать. Но наверняка есть еще сотня таких, о которых не в курсе.
Окей, отставим в сторону автоматическую замену кода будущим поколениям. Но даже полу-автоматический режим может быть весьма полезен — представьте, если анализатор скажет «вы пытаетесь перебрать коллекцию из 1000500 элементов в один поток, может стоит тут распараллелить или убрать прямой перебор?». Буквально, только PVS Studio движется в подобном направлении. Огромного количества медленных мест можно избежать, если IDE будет проводить глубокий анализ, а не примитивные советы вроде «результат функции нигде не используется». И технологии для этого уже есть, просто задачи такой нет.
Никакой оптимизатор не знает с какой целью создан код, а без знания цели можно только оптимизировать очевидные вещи, которые хоть и помогают иногда, но всё же не далеко не всегда.
Сейчас DLSS умеет достраивать изображение в игре в реалтайме, повышая разрешение почти в два раза. Неужели рано или поздно оптимизатор не сможет понять, что конкретно в этом примере — умножение матриц, которое можно сделать с помощью AVX?
Аналогично с распараллеливанием — OpenMP и GCC уже два десятка лет обрабатывают #pragma omp parallel for, но аж в трех языках программирования и только с прямым указанием, что этот цикл можно параллелить.
Мое сообщение говорит о том, что код с .Net Framework не запустится на .Net Core. Разные CLI.
А почему никто не говорит, что надо улучшать компиляторы? Если работа высокоуровневого программиста — перемножать матрицы в 4 строки и двигаться дальше, то почему он должен каждый раз нырять в низкоуровневые дебри? Описанный код вполне может быть ускорен, распараллелен и векторизован умным анализатором, JIT, AI компилятором и чем-либо еще. Если мы хотим сохранить разделение на уровни абстракции, а не смешивать все слои в попытках оптимизировать все перед релизом, то сами инструменты должны эволюционировать каждый год. Но никто из разработчиков ОС/языков/компиляторов не хвастается, что с новым апдейтом Windows или MacOS стала быстрее запускать программы, а код для Python 3.8 с апдейтом до 3.9 станет автоматом подключать numpy, прогонять нужный кусок на автоматических тестах и в итоге его заменять на быструю версию. Даже в случае явной эволюции .Net Framework -> .Net Core нельзя запустить старый код и получить прирост производительности за счет RyuJIT и других вкусностей.
Как водится, я написал не сильно вчитавшись в код, а народ еще и заплюсовал. Якорь в корму мне за менторский тон и поспешность!
У автора Vector2Int.DistanceEstimate считает точное диагональное расстояние до точки (0,0), это значит, что два весовых коэффициента (уже пройденный путь и тот, который надо пройти) имеют 1в1 одинаковую размерность и, по-сути для пути без препятствий показывают точное расстояние от старта до точки и точки до цели:
double traverseDistance = parent.TraverseDistance + cost;
double heuristicDistance = (position - target).DistanceEstimate();


Это превращает алгоритм в точный A*, без намека на «жадность». Путь получается гарантированно кратчайшим по расстоянию и недостаток у него лишь один — излишняя геометричность:
Скрытый текст
image

Еще раз по пунктам, как это работает: в каждой точке алгоритм оценивает следующий шаг, сортируя возможные шаги по приблизительному расстоянию до цели heuristicDistance. Когда происходит возврат назад из финальной точки к конечной (разворачивание всех точек пути), используется traverseDistance. Т.к. эти значения считаются по одинаковому принципу, то обратный путь будет гарантировано кратчайшим.
Единственное, что надо проверить, так это заменяет ли автор уже в найденных точках значение traverseDistance, если к ним нашелся более короткий путь. Update: заменяет, это как раз последняя строка кода в листинге в статье.

P.S. На счет массивов и хешсетов. Я бы использовал вообще все коллекции другие. Но это уже детали. Правильно сделать сначала так, а потом уже оптимизировать по мере надобности. Если собственное бинарное дерево решило вопросы производительности, значит в задаче автора этого достаточно.
P.P.S. Навигация по навмешу это та же самая навигация по графу с эвристикой и для нее A* подходит идеально. В моем текущем проекте ноды графа это места, куда можно доехать, зажав комбинацию клавиш «влево», «вправо» и «акселератор» на разные промежутки времени, двигаясь по кривой Корню с учетом ускорения, текущей линейной и угловой скорости, вязкости среды. Визуально эти точки образуют сложное облако, ничуть не похожее на сетку или навмеш.
Эти 30-40% (точнее 37% в 2020м для владельцев-физлиц по таксу 1446) засчитываются в уплаченные налоги и частично вернутся как tax refund. Только вот все участники должны получить ITIN и стать налогоплательщиками США для этого.
Ну или таки оптимизировать.
В целом ок. Реализация не блещет, но это хорошая заготовка.
То, что вы называете «DistanceEstimate» это эвристическая функция — ядро алгоритма А*. Обычно для него используется Манхеттенское расстояние между точками, иногда Евклидово. Правда, обычно считается расстояние до соседней ноды, а не до конечной, а уже сумма этих расстояний для выбрных нод дает длину пути. Когда вы в эвристике делаете расчет расстояния сразу до конечной точки, вы превращаете алгоритм в «жадный», который стремится в первую очередь выбирать ноды, которые как можно ближе к последней точке. И в момент прихода к последней точке вы алгоритм останавливаете, поэтому путь будет де-факто не кратчайшим.
Чуток моих замшелых исследований по эвристике тут.
Это заявка не на победу, а на стойкую мигрень :) И становится понятно, почему сейчас предпочитают сделать мобильную версию, а потом уже ее как-нибудь натянуть как сову на глобус на десктоп.
С вероятностью больше 99% не ломанётся. Но если не репортить, то вероятность 100%, что никто ничего не сделает.

Сделал игру для десктопа. Скоро релиз, все условно ок. Начал прощупывать мобильную версию — запустил, посмотрел, привязал масштабирование UI. А потом глянул на конкурентов и стало видно, что я безнадежно отстал — десктопный интерфейс по пикселям на телефоне помещается, а по логике, размеру и тач возможностям — никак. И простых путей тут нет, это как два разных полотна, где в одном видны мельчайшие детали в стиле реализма, а в другом жирные импрессионистские мазки фокусируют внимание на самом важном. И мобильный "импрессионизм" имеет больший охват и потенциал, чем ретро-реализм, к которому мы так привычны.

Если ошибка не в игре, а в том, как d3dx9_31.dll считает матрицы в некоторых случаях без 3dnow!, почему бы не зарепортить ее в Microsoft?
Ваша задача в теории* хорошо ложится на хранимые процедуры — все данные изначально лежат в базе, можно создать очередь задач и СУБД сама решит как их выполнять, в каком потоке, на каком ядре или ноде кластера, сама разберется с блокировками.

Скрытый текст
* К сожалению, теория от практики существенно отличается и мы 15 лет назад в похожей ситуации обнаружили вагон и маленькую тележку проблем:
— сама СУБД должна быть достаточно продвинутая, с хорошим языком запросов (T-SQL, PL/SQL), ей должно быть выделено достаточно ресурсов для выполнения ХП. При этом надо надеяться, что процедуры таки выполняться именно параллельно, а не по одной в одном потоке, блокируя все намертво;
— в общем случае набор правил быстрее и удобнее всего писать прямо в виде кода процедуры (или нескольких). За пару месяцев эта процедура (или сотня процедур) становятся страшным монстром, в котором мало кто разбирается, а покрыть это все тестами совсем не просто;
— заказчик не может сам писать правила и должен все время дёргать программиста. Если же таки заказчику нужен интерфейс и логика для работы с правилами, то мы падаем в бездонную кроличью нору, разрабатывая либо собственный интерпретатор правил в хранимой процедуре, либо компилируя правила в SQL код, который потом включается в процедуру. Оба варианта съедают жуткое количество времени на разработку и отладку.

В итоге мы сидели над этими хранимками долгие месяцы и мечтали все переписать на людский язык программирования, пока проект благополучно не закрылся :)

Понимаете в чем проблема, singular they нормально использовать или не использовать по своим соображениям. Ненормально форсированно переходить на него в какой-то судорожной попытке что-то изменить. Особенно в коде, а не просто во внутренней переписке.

P.S. Минусы не от меня, я наоборот рад дискуссии и ссылке.
he/him/his — в they, them, their;
этот мир определенно еб*нулся.
Пользуюсь уникальным по своим параметрам монитором LG UltraFine™ 4K, но не новым 24", а старым на 21.5". Он работает по USB-C, а не Thunderbolt, имеет нативное разрешение 4096 x 2304 (218 ppi) и кучу других особенностей, вроде яркости в 500 нит. Есть и недостатки, конечно, например, маленькие и хрипящие динамики. Плюс никакие переходники вас не спасут, если у вас нет на видеокарте USB-C разъема. Я специально выбирал себе модель 2060 FE, чтобы там был порт VirtlualLink. На Маке и Intel NUC работает из коробки. Еще есть кое-какие танцы с бубном и платой за $64, чтобы заработало с любой видеокартой, но это того не стоит.
В целом, пользуюсь второй год и доволен как слон — яркий и четкий монитор, занимает немного места на столе. Жалко, что следующая версия на 24" оказалась менее удачной — меньше разрешение при таком же размере, меньше яркость, негативные отзывы про качество, поддержка только Thunderbolt 3.
А свою основную функцию маска выполняет? Какой класс фильтрации? Удобно ли дышать?
P.S. Все уже придумано до нас

Интересно, вот пройдет еще 10 лет. Как можно будет посмотреть Масяню из архива? Искать сконвертированные в видео версии? Заморозить образ с Windows 7 и установленным плеером?
Личный пример: в ходе разных работ было много классных решений, которые стоило бы подарить сообществу, но я не веду блог, не пишу твиты, а для github и хабра код почти всегда в состоянии «еще чуть подпилить надо». В итоге стал забывать. Как бы и код есть, но вспомнить логику уже тяжело. И комменты не помогают, приходится заново изучать всю тему и восстанавливать цепочку рассуждений. Лучше бы вел минибложек, как у автора, авось кому-то и пригодилось бы.
Для примера
Рендеринг цветного растрового изображения с произвольным зумом на GPU. Вариант развития SDF карт, но с поддержкой 256 цветов и опционального бордюра между кластерами.
Вроде как и тема для статьи хорошая, но пылится уже много лет в черновиках и понемногу теряет актуальность и стирается из памяти.


Информация

В рейтинге
Не участвует
Откуда
Украина
Дата рождения
Зарегистрирован
Активность