Минимальный размер для части работы, которая будет успешно выполнена в другом потоке? - PullRequest
2 голосов
/ 13 октября 2010

У меня система с низкой задержкой, которая принимает UDP-сообщения.В зависимости от сообщения система отвечает отправкой от 0 до 5 сообщений.Выяснение каждого возможного ответа занимает 50 мкс (микросекунд), поэтому, если нам нужно отправить 5 ответов, потребуется 250 мкс.

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

Если у меня 5 потоков, ожидающих сигнала для выполнения50 нас работы, и они не борются много, будет ли общее время до того, как все 5 будут сделаны, будет больше или меньше 250 нас?

Ответы [ 3 ]

1 голос
/ 13 октября 2010

Передача данных из одного потока в другой выполняется очень быстро, 1-4 раза, если поток уже работает на ядре. (а не сон / ожидание / выход). Если ваш поток должен пробудиться, это может занять 15 минут, но задача также займет больше времени, так как кэш, вероятно, будет иметь множество ошибок. Это означает, что задача может занять в 2-3 раза больше времени.

1 голос
/ 13 октября 2010

Это 50us для вычисления или для ввода-вывода? Если у вас есть вычислительные возможности, есть ли у вас несколько ядер для параллельной работы?

Извините - много вопросов, но ваша конкретная среда повлияет на ответ на этот вопрос. Вам нужно профилировать и определить, что имеет значение в вашем конкретном сценарии (возможно, запустить тесты с другим размером Threadpools ?).

Не забывайте (также), что потоки по умолчанию занимают значительный объем памяти для своего стека (по умолчанию 512k, IIRC), и это также может повлиять на производительность (через запросы на подкачку и т.

0 голосов
/ 13 октября 2010

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

...