LINUX.ORG.RU

Многоядерность не помогает.


0

2

У меня есть физический движек, считает столкновения шариков. И на одном ядре все работает медленно. Если задействуется 8 потоков (i7 4770) проц грузится на 30-50% но все равно не успевает все считать. Пишу на Qt

Вычисления делаю по таймеру

QTimer* timer = new QTimer(this);
    connect(timer,SIGNAL(timeout()),this,SLOT(my_update()));
    timer->start(16);
А в функции my_update() поставил таймер, что бы измерял через какие моменты она запускается. Если шариков мало все нормально, через 16 мс как и должно. Но когда я поставил 33 000 шариков вызов происходит примерно через 100 мс. Но напомню, потоми загруженные только на 30-50%


Кажется проблема в их рисовании.....

knotri
() автор топика

Твой движок не масштабируется // К.О.

А причин может быть дофига. Вангую слишком много блокировок.

tailgunner ★★★★★
()
Ответ на: комментарий от knotri

Что именно значит масштабируется?

Это значит «наращивание вычислительной мощности не приводит к увеличению производительности». Или ты ожидаешь ответа «Bar::baz в модуле foo.cpp сериализирует вычисления»?

П.С. асимптотика должна быть линейная.

И как, линейная она?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

да, просто она не совсем линейная, что то типа (N+K*N*N), где K весьма и весьма малое число.

Убрав рисование, для 16000 шариков получил вычисления за 16 мс

knotri
() автор топика
Ответ на: комментарий от knotri

Убрав рисование, для 16000 шариков получил вычисления за 16 мс

Ну вот ты и нашел узкое место, которому увеличение числа ядер не помогает.

tailgunner ★★★★★
()

Ищи узкое место. Например, как написали, синхронизация.

upd: А, уже нашёл.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от rezedent12


Ну так вынеси рисование в отдельные потоки.


+100500

рисование тормозит основной вычислительный процесс, поэтому только отдельный поток.

metawishmaster ★★★★★
()

ты думаешь, оно тебе магически раскидает вычисления по разным ядрам?

нет, не раскидает

как сам сделаешь, так и будет

stevejobs ★★★★☆
()
Ответ на: комментарий от metawishmaster

рисование тормозит основной вычислительный процесс, поэтому только отдельный поток.

Это не поможет, все равно рисование останется узким местом и будет все тормозить. Ну будут шарики считаться быстрее чем рисуются, кому от этого будет легче?

ТС-у: а зачем перерисовывать сцену каждые 16 мс? Какой радиус шарика? Сцена 2D или 3D (я так понял 2D)?

AIv ★★★★★
()
Ответ на: комментарий от knotri

Рисуй шарик в QPixmap (один раз вне paintEvent), а потом уже отрисовывай QPixmap с нужными координатами через QPainter.

kamre ★★★
()
Ответ на: комментарий от knotri

33 тысячи точек должно рисоваться быстро. Я не знаю как в кютях, если непосредственно в памяти цвета точек выставлять, это всяко не медленней чем расчет физики.

AIv ★★★★★
()
Ответ на: комментарий от anonymous

И че изменится? Мне кажется Qt так и поступает

knotri
() автор топика
Ответ на: комментарий от AIv

дык тред не должен отрисовавать в цикле «while(true) {paint();}», но в while(true) {paint(); usleep(relax);}"
причем в relax'e должло учитываться время занимаемое отрисовкой(dt) («relax = 40 - dt»). если хочется 25 кадров в секунду.
типа того

metawishmaster ★★★★★
()
Ответ на: комментарий от metawishmaster

Если рисовалка требует 0.1 секунды на отрисовку сцены, то как бы там цикл не был организован и как бы эту фигню в отдельный тред не выносили больше 10 фпс не будет. Можно канешна каждую отрисовку делать в отдельном треде и потом как то это дело собирать, но это изврат - проще научиться нормально (быстро) рисовать

AIv ★★★★★
()
Ответ на: комментарий от AIv

а тут рисовалка требует 0.1 секунды?
я бы посоветовал заюзать OpenGL - он быстрее отрендерит

metawishmaster ★★★★★
()
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: комментарий от knotri

А почему не используешь QGraphicsScene?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.