Многопоточность на однопроцессорном компе

+1

3 дня назад Интел сбросила цены на 20-25% для Core2Duo. В сентябре-октябре еще немного сбросят.

Т.е. нормальный двухядерник можно будет купить за 70-90$ в этом году.

Так же сниженны цены на 4 ядерные Кватры - цена упала ниже 300$ и скоро упадет еще сильнее.

AMD анонсировалла к 2009 8 ядерный проц.

Тенденции я думаю ясны через 2-3 года 1 ядерный проц будет сложно купить - их просто перестанут производить.

Соответственно софт уже нужно писать с учетом этих тенденций !

 

Введем понятия. Одно процессорная система с одним логическим процессором. Много процессорная система с несколькими логическими процессорами.


Распараллеливани кода. Может достигаться нетолько путем увиличения потоков, но и путем использования паролельных команд.

Эффективность<>производительность.

Если создаешь несколько потоков на одно процессорной системе, то производительность падает. Эффективность может и возрасти.
Производительность падает так, как требуется больше времени на переключение процессов. Но это не значительно если мало потоков. Больше производительности может съесть синхронизация.
Насчет эффективности. Эффективность может возрасти. К примеру пока один поток ждет данных. К примеру с сети, сканера, другого источника. Если у нас два потока. То первый ждет данные, а второй выполняет код. К примеру по обработке уже поступивших данных. Тем самым эффективность возростает.

На много процессорной системе. Разумеется будет увилечение производительности если использовать несколько патоков.

Насчет распараллеливани, ускорение можно добиться если использовать паролельные команды.
Такие как SIMD - это известные расширения MMX SSE SSE2 SSE3
Основная суть их в том что одновременнои идет расчет набора данных.
К примеру одновременно идет сложени 8байт с другими 8Байтами.
Или уможение двух Single переменных на две другии переменные.

Помимо этого существует куча способов оптимизации.

 

От слова патока

 

asmlamo, никто не спорит, тот же сервер значительно удобнее делать на тредах, но извини меня тот же фрактал разбивать на потоки - это грех. И не важно сколько ядер у процессора. Не стоит забывать, что твоя прога не единственная в системе, нужно и с другими считаться

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

Поправь меня, но я считал, что уже давно почти все команды распаралеливаются, как обычные, так и FPU, и разумеется MMX и тд. Да и у MMX и XMM диапозон применения довольно узкий - скажем так 3Д, да и то ограниченно, тот же cross product удобнее на FPU сделать, на SSE слишком много гемора, с обработкой сразу четырех векторов. Да и здесь очень большую роль играет правильная работа с памятью(читай кэшем).
Ну и что бы не плодить тем, спрошу уж здесь. Не так давно проводил сравнение перемножения векторов и матриц между FPU и SSE. Последние на несколько процентов оказались быстрее. Но это в однозадачной среде. А как насчет многозадачных систем? Кто нибудь замерял? По идее SSE лучше к ним приспособлен, но это имхо, хотелось бы услышать другие имхо

 

Так оно и есть. По крайней мере у Агнера Фога это написанно.

 

Удобней, это не значит что лучше.

 

Смотря какую технику применяешь. Если WSAEventSelect и Overlapped(на event'ах), то безусловно через потоки. Если на WSAAsyncSelect или Non blocking режим, то нужно 1-3 потока. Но все эти методы довольно тормознутые, лучше уж через CompletionPort делать. Тогда и потоков то всего два потребуется - слушающий(большую часть времени находящийся в спячке) и обслуживающий клиентов

 

Можно обойтись одним (см AcceptEx)

 

В продолжении темы. Написал простую тестовую программу. Из основного потока по нажатию кнопки запускается еще два потока: один просто добавляет в цикле по +1 (до 575 - выбрано произвольно)и выводит цифру на экран, второй - подсчитывает время работы потока. Введена небольшая задержка для визульности. Затраченное время - 4 сек. Добавляю еще один поток, который делает то же самое и оканчивает время работы по тому же признаку (число 575). Общее время работы сократилось до 2 сек. Почему?
Попробывал делать то же самое (тот же цикл с той же задержкой) без создания потоков, т.е. в основном потоке.
Результат как и в 1-ом варианте - 4 сек.

 

tar4
Может, у тебя время сократилось в два раза из-за того, что два потока инкрементят одну переменную. А введенная задержка позволила им это делать в разные (непересекающиеся) моменты времени даже на однопроцессорном компе. То есть, допустим, переменная в одном потоке инкрементится 575/4=143 раза в секунду, и в другом с той же частотой. В результате скорость удваивается. Поробуй увеличить 575 до 575000000 и убрать задержку. Все встанет на свои места.

 

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

 

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

 

апгрейт благо это не очень дорого.

 

Я попробывал еще раз и локальной переменной для каждого потока и глобальной переменной для обоих потоков без задержек. Если подытожить, то в 1-ом варианте (два локальных счетчика) - общее время работы двух потоков больше примерно на 50% чем время работы одного из них. Если же счетчик будет объявлен как глобальная переменная,
то время работы обоих потоков примерно равно времени работы одного из них (2-й в этом случае не запущен).
Вообщем, все понятно.

Наверное. Но если задача - это хобби, сложно мотивировать на работе апгрейд компа.