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

Подскажите, можно ли повысить производительность алгоритма за счет распараллеливания потоков?
Согласно теории "Эффективность приложения повышается при создании внутри него нескольких потоков, одновременно решающих независимые друг от друга задачи."
У меня есть функция, в которой производится длительные сложные итерационные вычисления. Исходные данные для расчета, например, числа Х,Y,Z. Я сейчас выделяю отдельный
поток, в котором последовательно на вход вычислительной функции подаются эти числа. Одно из них является решением задачи. Есть нормальное желание разделить этот поток на 3 потока, в котором каждый поток, как бы по отдельности, работал с числами Х,Y,Z. Но меня смущает то, что на самом деле, распараллеливание потоков является виртуальным, как бы идет псевдопаралельное выполнение.
Ведь потоки на самом деле выполняются не одновременно, а по очереди, но переключение между ними происходит так часто, что кажется будто они выполняются параллельно.
Тогда есть ли большая разница между выполнением кода в одном потоке или в трех? Каково Ваше мнение?

 

Есть разница. В твоем случае код в трех потоках будет работать в несколько раз медленее.

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

 

Вот даже как! Спасибо.

 

Сейчас в современном процессоре по-настоящему уже несколько ядер. Так что лучше писать с потоками - будет быстрее работать на современных машинах.

 

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

 

в современном мире параллелизм должен быть везде. начиная от обычного последовательного исполнения кода (параллелизм по данным) и заканчивая параллельно выполняемым кодом (разными потоками и/или разными ядрами/процессорами).

Код (Text):

1. // a = b + c + d + e
2. // преобразуется в следующее
3. f = b + c
4. g = d + e
5. a = f + g

 

Да можно при наличии 2 и более ядер.

 

Можно, в принципе, получить некоторое ускорение и на одном ядре, если это ядро P4, за счет HT.

 

А еще надо читать название топега прежде чем постить ответы. Кажется там ясно написано

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

 

Я как раз и прочитал название топика. Могу еще раз повторить, для особо непонятливых
- один процессор (в топике "однопроцессорном"), в настоящее время это больше чем одно ядро (Pentium 4+HT, Pentium D, Core2Duo).

Извините за оффтоп.

 

Ultrin Faern
Не прикапывайся к словам. Аффтар имел в виду именно одно ядро, так как многоядерный процессор равнозначен мультипроцессорной системе (и программно выглядит в точности как мультипроцессорная система).

 

точнее бы написть один логически процессор, тогда бы точно непоняток не было =)
а по теме - это смотря где работаешь - в rtos да, разницы будет мало. А вот в винде планировщик будет выделять твоему процессу больше времени, и следовательно программа быстрее просчитает.

 

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

 

Спасибо за высказанные мнения. По-видимому, я все же не точно сформулировал вопрос, так как возникли разночтения. В моем понимании было процессор и ядро - одно и то же. Наверное, надо было сразу написать, что у меня - АMD Athlon(tm) 64 Processor 3200+ и ничего подобного типа Pentium 4+HT, Pentium D, Core2Duo нет. Работаю на WinXP. И судя по тому, что написали в теме - мне не удасться ускорить вычислительную работу алгоритма за счет распараллеливания потоков.

 

asmfan:

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

 

AndNot
Можно вообще вернуться в DOS (не в смысле отказа обслуживания) - операционную систему, где всё время процессора отдавалось одной задаче.
Просто кто не пишет и не собирается писать многопоточные программы - в будущем делать нечего (да и в настоящем тоже).
Как пример рассмотрим программку с окном, рассчитывающую большой факториал. Есть как минимум 2 способа сделать это:
1) сделать это в оконной ф-ии - как следствие "повисание" GUI программы.
2) сделать это через потоки - "сложность" реализации.
Я выбираю 2е.
Не буду сейчас вдаваться в подробное описание OoOE (out-of-order execution), что уже в себе подразумевает параллелизм исполнения.
В общем, пора выбираться из ДОСа.

 

asmfan

Для этого есть стандартные решения типа ProgressBar и т.п.

ОоО как раз предполагает оптимизацию однопоточного приложения, грубо говоря разбивку его на независимые "микропотоки" инструкций, выполняющиеся "параллельно" (с перекрытием во времени). Твой же пример с разбивкой a = b+c+d+e на два независмых сложения за счет ОоО даст выигрыш (особенно на FPU) и без всякой разбивки на классические виндовые потоки

 

leo
Об этом я и говорил в 1м своём посте, говоря о "начиная от обычного последовательного исполнения кода (параллелизм по данным)".
И всё же я считаю, что ПО научится пользоаваться данными процессора по оптимизации самого же себя в рантайме - число ядер; число потоков, исполняющихся параллельно на одном ядре; ширина кэш-линии; размер кэша и т.п. Рантайм идентификация особенностей архитектуры и набора расширений процессора сделают своё дело по формированию эффективной обработки данных - разбивки на потоки, на р-ры данных для кэша на специальные инструкции данного семейства и проч.
Для всего это лишь надо пользовать cpuid корректно и всё... вуаля.

 

asmfan

НТ скоро канет в лету вместе с P4, и видимо раньше, чем ты научишься оптимально использовать эту фичу А о других технологиях исполнения потоков "параллельно на одном ядре" я вроде ничего не слышал

На правах рекламы ?
К сожалению мало знать фичи процессора, нужно еще и уметь их использовать. Это во-первых. А во-вторых, для критических задач проще задавать требования к процессору или сразу при оптимизации ориентироваться на некоторый круг процессоров\параметров, чем писать код в "десяти вариантах" под каждый камень

 

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

Ты путаешь совершенно разные понятия. Распаралеливание инструкций - это совсем не тоже что многопоточность. К тому же, чем меньше прерывают некий поток, тем эффективнее он сможет использовать распаралеливание.

Зачем же старых друзей бросать Может и пригодится еще ;-?

Когда шампанское готовить?