Работа с Open Sources

[alex312]

Вряд-ли вы с булетом сможете получить даже для 10К объектов кадр в секунду.

Именно Bullet и используется в Blender как движек физики.

[Old]

Вряд-ли вы с булетом сможете получить даже для 10К объектов кадр в секунду.

Именно Bullet и используется в Blender как движек физики.

Ну да.

[m_ax]

Я удивлен что...

А я вот что то совсем напротив, не удивлён  

Сначала собираются все "contact pair(s)", т.е. 2 объекта находятся на критическом расстоянии и, вероятно, должны оттолкнуться. Профайлер показывает что время жрется на сборку контактов и их resolving.

Ну так за это и отвечают те самые дифуры + гран. условия.. Или всё же отображалка? Или как? Я просто не специалист в этих вопросах..

От себя хочу добавить.. Есть задачи: сейчас сам одной занимаюсь - есть кластер, всего 80 атомов (80*3 = 240 степеней свободы) и считается конфигурация с наименьшей энергией очень и очень прилично по времени.. (ну в зависимосчти от параметров). Я понимаю, что это не совсем та механика, что в булете, но..  

[Igors]

Ну так за это и отвечают те самые дифуры + гран. условия.. Или всё же отображалка? Или как?

Ну что Вы тормозите на ровном месте? Отображалка ни при чем, забудьте про нее. И какая разница "дифуры" или нет? Если без дифуров ну никак низзя, то пусть они там будут - мне все равно 

Тут конечно кое-какие наметки имеются, правда совсем не густо. Простейшая задача: если объект улетел "куда-то далеко" его нужно удалить. Напр скатился с плоскости и продолжает падать под действием гравитации, и вот уже y = -1.0e+9. Отсечка таких объектов - простейшая оптимизация, но ее никто не отменял. Какие опции дать юзеру чтобы он мог удобно контролировать это "далеко"?

Вроде бы так: пусть юзер назначит "вмещающий объект" (часто кубик), все объекты за его границами автоматычно удаляются. Но такой объект неприятно виден (путается под ногами) в UI. Плюс Bullet поймет его как тело имеющее объем, и все что туда попало будет являться "пересечением". Придется расшивать стенки делая каждую объектом и.т.д. Как-то возни много, нет ли лучшего решения?

[Igors]

Ну вот, наступило дружное молчание Ладно, зайдем с др стороны. Ну хорошо, оставим без внимания мои потуги что-то оптимизировать конкретно, так сказать "алгоритмически". Примем песенку Верес'а "ну откуда же я могу это знать?" 

Но позвольте Вас спросить - а какой вообще главный (современный, магистральный и.т.п.) метод ускорения программ в наше время? Причем не так себе, отгрызть  5% на inline (типа крутой знаток asm), а принципиально, в разы и больше? Или Ваш код и так весьма крут и никаких ускорений не требует? 

[OFF]
Наверное Хокс в отпуске
[/OFF]

[Old]

Ну вот, наступило дружное молчание Ладно, зайдем с др стороны. Ну хорошо, оставим без внимания мои потуги что-то оптимизировать конкретно, так сказать "алгоритмически".

Просто эти потуги так наивны, что уже и не смешно.

Но позвольте Вас спросить - а какой вообще главный (современный, магистральный и.т.п.) метод ускорения программ в наше время?

А вы думаете такие методы существуют для любых программ?

Вы давно замеряли сколько времени сортируются 100K double на одном ядре?

[alex312]

Но позвольте Вас спросить - а какой вообще главный (современный, магистральный и.т.п.) метод ускорения программ в наше время? Причем не так себе, отгрызть  5% на inline (типа крутой знаток asm), а принципиально, в разы и больше? Или Ваш код и так весьма крут и никаких ускорений не требует? 

Если размышлять в контексте Bullet, то основной способ его ускорить  - это заюзать OpenCL (с использованием видеокарты или 2х)

[Igors]

Если размышлять в контексте Bullet, то основной способ его ускорить  - это заюзать OpenCL (с использованием видеокарты или 2х)

Я все ждал, когда же спросят типа

А это время (медленно) на скольких ядрах?

Не дождался Так вот на ОДНОМ. Формально multi-threading был, но как-то optional. Т.е. в числе демосов (2.76 потом 2.81) был и пример с multi, но остальные демки без него. И в комментах так осторожно "можете попробовать multi (класс) из фолдера Extras"

Но в последнем билде (2.83.4) никаких multi уже нет, вместо этого, да, OpenCL. Видимо это становится стандартом для приличного софта. Однако портирование на OpenCL - дело совсем непростое, а проект никто не финансирует (ну это я так понял). Результат (за примерно 2 года работы): пока OpenCL реализация работает только на двух "high-end" картах. Когда на остальных (и будет ли) хз. И у меня незавидный выбор

- все-таки задействовать старый код multi который уже снесен и который штатным-то и не был. Покопавшись в архивах стало понятно почему: он неустойчив, его надо доводить до ума

- бросаться самому доводить OpenCL. С моим нулевым опытом в этой области выглядит нереально

- ничего не делать (часто самое мудрое решение) в смысле аппаратного ускорения, сидеть на 1 ядре. Уповать что в конце-концов Эрвин доделает. Но так меня будут бить за провальную скорость, и, возможно, ногами

Жду Ваших умных советов 

[Old]

- все-таки задействовать старый код multi который уже снесен и который штатным-то и не был. Покопавшись в архивах стало понятно почему: он неустойчив, его надо доводить до ума

А разве это сможет решить ваши проблемы?
Если у вас скорость начинает проваливаться после 300 чайников на сцене. Даже задействовав еще 7 ядер вы сможете обработать 100K?

Но так меня будут бить за провальную скорость, и, возможно, ногами

Вы бы попросили заказчика побить вас за скорости интернет соединений, уже давно хочется скачивать контент со скоростью 100 гигабайт в секунду... Может вы броситесь сюда и доведете здесь.

[Bepec]

Алгоритмически, можно оптимизировать проведя все типы всех расчетов всех объектов заранее. Тогда останется только отображение. Но даже так, 100к объектов в реалтайме не получится

[Igors]

Алгоритмически, можно оптимизировать проведя все типы всех расчетов всех объектов заранее. Тогда останется только отображение. Но даже так, 100к объектов в реалтайме не получится

Скорость отображения меня сейчас не волнует. Для этого есть OpenGL который напр умеет рендеоить "инстансами", возможно 100K объектов (несложных конечно) даже будет и realtime (юзер же платил за карту сотни баксов). Но даже если нет, я просто выведу в мувик - вот и все.

Проблема - фаза расчета (симуляция). Как правило требуется десятки (и больше) раз что-то переустановить и опять "симулячить". Если каждый заход будет час-два - сильно не поработаешь, не хватит рабочего времени.

[Igors]

Да, и вот еще о чем хотелось бы поговорить: а что значит "спец" в данном случае? Какими знаниями/умениями должен обладать такой спец? И я вот затрудняюсь ответить. Примерный ход мысли

Qt - ну здесь оно вообще никаким боком
std/boost - да в общем тоже. Может в бусте и есть что-то с похожими именами, но шансы это задействовать призрачны. (Во блин, учил-учил, а оно не пригодилось  )

физика...  казалось бы это все объясняет, типа

Ага, вот в чем дело! Я ж не физик, я программист! Вот пущай физик этим и занимается и "дает мне формулы" - а я уж их реализую

Увы, привлечение людей "от науки" малоэффективно. Да. физик расскажет массу интересных вещей, причем Вы с удивлением обнаружите что многое и сами это знали из школьного курса (хотя бы масса, сила, ускорение). Но никаких решений он не предложит, в алгоритмах и (тем более) реализациях разбираться не будет, не говоря уж об аппаратном ускорении.

Математика(и)... грубо говоря это примитивная попытка заморочить яйца "дифурами". То есть вот есть "дифуры" - они все и делают. И вообще вся природа вокруг нас - это все дифуры. Ну и опять песенка та же - мол, есть "некто" дающий дифуры/формулы, а программист только их реализует.

Так кем же он должен быть, этот легендарный "спец" - или это просто миф, таких нету 

[Racheengel]

А давайте чуть "сменим декорации" - предположим тормозит QGraphicsScene c 500K QGraphicsItem, не думаю что такое предположение слишком уж смело/фантастично.

Именно такая проблема как-то раз у нас и возникла. Пришлось отказаться от QGraphicsScene. Сделали свою имплементацию (грубо говоря, свой редактор айтемов) и проблема решилась