Вопрос

Я написал многопоточную программу, которая выполняет некоторые тяжелые вычисления на процессоре с множеством операций с плавающей запятой.Точнее, это программа, которая покадрово сравнивает последовательности анимации.Т.е.он сравнивает данные кадра анимации A со всеми кадрами анимации B для всех кадров анимации A.Я выполняю эту интенсивную операцию для разных анимаций параллельно, поэтому программа может работать над парой A-B, парой B-C и парой C-A параллельно.Программа использует QtConcurrent и функцию «карта», которая отображает контейнер с движениями на функцию.QtConcurrent управляет для меня пулом потоков, я работаю над четырехъядерным процессором Intel, поэтому он порождает 4 потока.

Проблема в том, что мой процесс разрушает мой процессор.Использование постоянно на 100%, и я фактически получаю «синий экран смерти», если запускаю свою программу с достаточно большим набором движений (ошибка страницы в невыгружаемой области).Я подозреваю, что это потому, что мой компьютер разогнан.Однако может ли это быть из-за того, как я написал свою программу?Некоторые очень интенсивные инструменты тестирования, которые я использовал для проверки стабильности моей машины, ни разу не привели к сбою моего компьютера.Есть ли способ контролировать, как моя программа использует мой процессор для снижения нагрузки?Или, возможно, я неправильно понимаю свою проблему?

Это было полезно?

Решение

Здесь есть несколько отличных ответов.

Я бы только добавил, с точки зрения того, что было сделано много настроек производительности, если только каждый поток не был агрессивно оптимизирован, скорее всего, у него есть много места для сокращения цикла.

Чтобы провести аналогию с автогонкой на длинные дистанции, есть два способа выиграть:

<Ол>
  • Заставь машину ехать быстрее
  • Делайте меньше остановок и обходов
  • По моему опыту, большинство программ, написанных в первый раз, весьма далеки от того, чтобы идти по самому прямому пути, особенно , поскольку программное обеспечение становится большим.

    Чтобы найти потраченные впустую циклы в своей программе, как сказал Кеннет Кокран, никогда не догадывайтесь Если вы что-то исправили, не доказав, что это проблема, вы инвестируете в предположение.

    Популярный способ найти проблемы с производительностью - использовать профилировщики.

    Однако я часто этим занимаюсь, и мой метод таков: http: //www.wikihow.com/Optimize-Your-Program%27s-Performance

    Другие советы

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

    Это также может быть довольно странная ошибка памяти, когда вы повреждаете свою оперативную память таким образом, что Windows (я полагаю, что ОС, из-за BSOD) не может больше восстановиться (очень маловероятно, но кто знает).

    Еще одна возможность, о которой я могу подумать, это то, что у вас есть какая-то ошибка в реализации потоков, которая убивает окна.

    Но сначала я бы посмотрел на проблему с разгоном ...

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

    Вы также можете посмотреть опции, используя ваш графический процессор, чтобы уменьшить часть нагрузки при обработке. Современные графические процессоры значительно более эффективны для большинства видов преобразования видео, чем процессоры аналогичных поколений.

      

    Я подозреваю, что это потому, что мой компьютер разогнан.

    Это определенно возможно. Попробуйте на некоторое время установить его на нормальную скорость.

      

    Может ли это быть из-за того, как я кодировал свою программу?

    Программа, работающая в пользовательском режиме, вряд ли вызовет BSOD.

    Я бы сказал, что вы не используете 3-ядерную машину (или 4 при 100% загрузке), и распараллеливание будет активно снижать вашу производительность, если вы используете больше потоков, чем ядер.Сделайте только один поток на ядро ​​ЦП, и что бы вы ни делали, никогда не допускайте одновременного доступа к данным разных потоков.Алгоритмы блокировки кэша в большинстве многоядерных процессоров абсолютно снизят вашу производительность.В этом случае в N-ядерном процессоре, обрабатывающем L-кадровую анимацию, я бы использовал поток 1 для кадров 0-(L/N), поток 2 для кадров (L/N)-(2*L/N), . ..нить Н на шпангоутах ((Н-1)*Л/Н)-Л.Выполняйте различные комбинации (AB, BC, C-A) последовательно, чтобы не перегружать свой кеш, а также должно быть проще кодировать.

    В качестве примечания?Настоящий вычисление так должен использовать 100% процессор, это означает, что он работает так быстро, как только может.

    Разгон является наиболее вероятной причиной нестабильности. При использовании любого алгоритма с интенсивным использованием ЦП будет происходить некоторое перегрузка ЦП. Разгон не выдерживает, я бы нашел хороший профилировщик производительности, чтобы найти узкие места в производительности. Никогда не угадай, где проблема. Вы могли бы потратить месяцы на оптимизацию чего-либо, что не оказывает реального влияния на производительность, а худшая производительность может даже снизиться.

    Слишком просто обвинять аппаратное обеспечение. Я бы посоветовал вам попробовать запустить вашу программу в другой системе и посмотреть, как это получится с теми же данными.

    Возможно, у вас есть ошибка.

    Ознакомьтесь с использованием операций SIMD. Я думаю, что вы хотели бы SSE в этом случае. Они часто являются лучшим первым шагом, чем распараллеливание, поскольку их легче получить правильно и они обеспечивают довольно значительный импульс для большинства типов операций линейной алгебры.

    Как только вы получите его с помощью SIMD, посмотрите на распараллеливание. Звучит так, будто вы также грохочете процессор, так что вы, возможно, могли бы сделать несколько снов вместо ожиданий, возможно, занятых, и убедиться, что вы правильно очищаете или повторно используете потоки.

    Из-за отсутствия кода ошибки BSOD (полезного для поиска) вам немного сложнее помочь с этим.

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

    Сон(1);сократит загрузку процессора вдвое.Я столкнулся с той же проблемой, работая с алгоритмом, интенсивно использующим процессор.

    Если ваш процессор имеет два или более ядер, вы можете зайти в диспетчер задач и перейти к процессам, щелкнуть правой кнопкой мыши на имени программы, щелкнуть Set affinity и настроить программу на использование меньшего количества ядер.

    Тогда потребуется больше времени для выполнения запрашиваемых вами действий, но это приведет к ЗНАЧИТЕЛЬНО уменьшению использования ЦП.

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

    Что ж, если вы создаете несколько потоков, каждый из которых выполняет тяжелые операции с плавающей запятой, то определенно ваша загрузка ЦП достигнет 100%.

    Было бы лучше, если бы вы могли немного поспать в каждом потоке, чтобы у другого процесса был шанс. Вы также можете попытаться уменьшить приоритет потоков.

    Если на платформе Windows, после некоторой работы включите один вызов функции, чтобы сообщить процессору, что вы хотите сделать процессор для других процессов. Сделайте вызов функции сна следующим образом:

    Slepp (0);

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top