У тебя неправильно поставлен вопрос. Ты тегируешь вопрос OpenCV. Машинное зрение.
Это определение на фото или на видео каких-то известных системе шаблонов.
А фактически задаешь вопрос который идет в тему игровой логики.
Тоесть машинного зрения у нас уже нету а у нас есть совершенно другая проблема
которую невозможно решить потому что просто у нас нет на руках куска кода
или алгоритма.
Я использую WSL иногда для Apache Spark. Но производительность - крайне низкая.
Поэтому я-бы не рекомендовал WSL в тех задачах где важны ресурсы и скорость.
Фасеты технически могут быть реализованы как partitions. В отличие от первых,
фасеты могут частично перекрываться поэтому количество partitions очень резко
растет. Например для 3х фасетов может быть 7 partitions из за сочетаний всех со всеми.
Поэтому имеет смысле не создавть сотни фасетов.
Сама раскладка бизнес-атрибутов по partitions - это чисто вопрос UX и performance
в каких-то частных случаях. Например вы смотрите на веб сайт и пытаетесь понять
что пользователь ищет чаще. В каких категориях и с какими атрибутами.
Это процесс увлекательный и бесконечный. Общих советов тут нет.
1) Надо попробовать успеть до того как "игра вылетит" собрать некоторые сведенья из ProcessMonitor. Что там видно? Какие показатели зашкаливают.
2) Если разработка идет на DirectX API, то возможно там есть какие-то средства профилирования
памяти. Сколько выделено? Что там лежит? Текстуры? Почему они не убираются например когда
не нужны?
historydev, никаких ТГ. Это публичное место где обсуждают технические вопросы.
Если у тебя NDA или какая-то бизнес тайна - то это все мимо кассы сам понимаешь.
historydev, смоделируй полет всех объектов без дерева.
У тебя при этом будет расчет гравитации для всех со всеми. Тоесть для 100 объектов
будет 10 000 взаимодействий. При этом надо придумать границу отсутствия взаимодействия.
И потом сделай модель такого-же мира но с квадра-деревом. Если правильно выбрана эта
граница то расчет будет более быстрый. Дерево отбросит ненужные взаимодействия
и будет не 10 тыщ а меньше.
Adamos, я не говорил - два раза. Я просто акцентировал на том что
при данной постановке С++ будет лишним затруднением в разработке.
Да и ошибок с памятью всегда есть шанс наделать больше в С++
приложении.
Идея портировать С++ на мобилки - это в принципе плохая идея.
Главное преимущество С++ - выскокая скорость на нагрузках - для UI
приложения не имеет никакого значения. И UI выгоднее писать на
- Android/Kotlin
- IOS/Swift
Поскольку ты - писатель на С++. То у тебя есть коробочные инструменты - профилировщики.
Они показывают обычно 1-2 функции в коде, которые создают являются CPU consumers.
Делай профилирование и приходи с фрагментом проблемного кода.
Твоя постановка - нагрузить CPU - это полная чепуха. Представь что ты своему водителю
поставил задачу "жечь побольше бензина". Это примерно такого же уровня полезности совет.
Навскидку можно сказать что у тебя (предположительно!) идет неэффективное использование кешей памяти. Но
я не хочу быть гадалкой. Надо смотреть код.
Тоесть заменить например a на y как принято в математике.
Потом придумать правильный подход к тестированию. Вот ты написала какой-то код.
Как мы проверим что он вообще правильный? Как проверить что определенный интеграл
правильный?
Нужны какие-то простейшие модульные тесты на константах которые точно правильные.
Суть подготовки в том что ты берешь олимпиадные задачи и каждый день (в СБ и ВС) с утра начинаешь
решать. Как спорстмен. У тебя - режим жизни. И в будни и в выходные.
Сначала долго. Потом быстрее и быстрее. Решение этих задач это навык. И он приобретается.
Там - обычное программирование и оно использует достаточно простые алгоритмы и структуры
данных. Но оно содержит в условиях
- ограничения (например все числа от 0 до 99999)
- время работы алгоримта не должно превышать допустим 30 секунд.
- обычно условие содержит пример в виде
Input:
Output:
И в условии всегда есть некая подсказка чтоб упростить решение. Очень часто может
применяться динамическое программирование и рекурсия. Но в этом нет никакой
олимпиадной магии. Это и есть ОБЫЧНОЕ программирование.
Просто есть лимит времени.
И код - обычно говнокод. Нет тестов. Нет рефакторинга. Нет генериков. Ты пишешь
бегом-бегом как на хакатоне. Все пишешь сплошной main функецией. Как бог даст.
Это определение на фото или на видео каких-то известных системе шаблонов.
А фактически задаешь вопрос который идет в тему игровой логики.
Тоесть машинного зрения у нас уже нету а у нас есть совершенно другая проблема
которую невозможно решить потому что просто у нас нет на руках куска кода
или алгоритма.