Вопрос простой: потоки многопотокового приложения выполняются параллельно на нескольких ядрах процессора? или же этим свойством обладают только многопроцессовые приложения?

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

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

Это сообщение отредактировал(а) GremlinProg - 23.12.2008, 18:13

На N ядерном процессоре могут выполняться в любой момент времени N потоков, одновременно, на каждом из ядер выполняется один из потоков, в следующий момент времени этот-же поток может продолжить выполнение на другом ядре. Как уже написал GremlinProg для потока(или для всех потоков процесса) можно запретить использование части ядер.
В принципе, если у нас есть N ядер, то мы можем выполнить в N раз больше вычислений. Но, не всегда скорость выполнения кода зависит от процессора, например, если в один прекрасный момент программе потребуется записать файл с жесткого диска, скорость ее работы будет ограничена скоростью работы подсистемы ввода-вывода. Тоже самое касается любого синхронного ввода-вывода. Что-бы это обойти, используют асинхронный ввод-вывод. Так-же нескольким потокам может потребоваться синхронизировать доступ к общей памяти, в этом случае они не будут выполняться параллельно абсолютно всегда, но можно свести подобные простои к минимуму при правильном дизайне приложения. 

Всем спасибо за ответы

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

тут вариантов-то всего 2:

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

2. если такого разделенного доступа нет, то эти ядра синхронизируются по общему "клоку" (clock), т.е. я как раз про этот вариант и писал выше, т.е. формируется физическая очередь между ядрами или конвеер

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

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

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

да, можно считать что это независимые процессоры, только размещенные на одном кристалле. У них разные конвейеры, так-же можно считать что кэши второго уровня то-же независимы(у процессоров AMD это действительно так, у Intel  кэш делится динамически). Взаимодействуют они с помощью аппаратных прерываний, например когда вызывается ф-я InterlockedIncrement(&value) происходит прерывание, заставляющее другое ядро обновить значение переменной value размещенной в кэше(если конечно эту переменную используют оба ядра).

Lazin, а ссылки есть читабельные по теме?

распиновка-то процессора одна,
выходит, что на мульмиядерном процессоре каждое ядро должно либо делить время при передаче управляющих сигналов, либо запрашивать усовно-зависимую платформу(мать) под специализированную, "узкую" инфраструктуру

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

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

Мы  как-то проверяли: длительный процесс обсчета распараллеливался, если есть на что (2 процессора или 2 ядра).  Сокращение времени обсчета, конечно, не в два раза было, а поменьше (за счет затрат на разделение). Но оно было примерно одинаковое, что в случае 2 ядер, что в случае 2 процессоров (на разных машинах пускали).
В общем, с внешней точки зрения получается, что вполне параллельно.

в подтверждение своих слов, я просто привожу первую попавшуюся статью, в которой речь идет именно о параллельности многоядерных процессоров: http://www.osp.ru/os/2007/04/4219910/
и чтобы особо не искать:

собственно, об этом я и веду речь, конечно, публицистика - не совсем то, что надо, но, тем не менее, хоть одна понятная формулировка )
я не нашел конкретных указаний на системы реального времени, но в HDL это четко выделено, поскольку параллельные системы все таки очень тесно связаны с геометрией кристалла, такие, "блочные" решения мало рентабельны в обычной жизни ( пока на смену не придут нанокомпьютеры )

Earnest, порвала мой монолог )


в этом плане поправка Lazin'а, была очень кстати:

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

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

Неужели ты 30 минут это писал?      

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

я просто не обновлял топик с первого поста ), минут 10 прошло (AJAX'у на вас мало))

ну да, увлеклись малость, я просто сам хотел удостовериться, ну, и заодно развеяли миф параллельности,

хотя на счет практического эффекта, лучше вообще иметь несколько систем под рукой, а то порой параллелишь-параллеллишь, да такого напараллелишь, что на 1 процессорнике летает, а на двух - черепаший забег, причем тривиальные вещи - синхронизация.
меня, к примеру, смущает отсутствие многоядерника в закромах, но 2-х процессорники есть, причем как интеловский, так и от атлона
есть с чем сравнивать (кстати, практическая разница реально бывает существенной), да и уверенности больше в правильно выбранном алгоритме

Это понятно, распараллеливание никогда не бывает бесплатным, и издержки могут сожрать весь выигрыш и еще чуть-чуть. Но мы же кривые руки здесь не обсуждаем... Ну и не все задачи легко распараллелить.
Не поняла только зачем 2 системы, чтобы проверить эффект... Включаем распараллеливание (какой-нибудь if в коде) - меряем. Выключаем - опять меряем. Хотя посмотреть, как оно на разных машинах, конечно, полезно.
У нас как раз больше 2-ядерники, а 2-процессорник вроде только один. Но эффекты был похожи.

Добавлено через 5 минут и 40 секунд
На наши результаты наверняка существенно влиял доступ к диску: данные большие (растры) и в память целиком не лезли, так что параллельность не очень чистая получилась, конечно. Но выигрыш был заметный. 

А что, каждый процессор должен отдельно выходить наружу?   
'Управляющие сигналы' - это что? Если доступ к внешней памяти и шине (например PCI), то они конечно разделяются, более того, они будут разделяться, даже если будет несколько ФИЗИЧЕСКИХ процессоров (в разных корпусах).
Если речь идет о внутренней машинерии коров, то они полностью раздельные. Разные коры работают на своих (раздельных) кэшах, так что тут полная паралельность. Тут надо правда различать коры и HT процессоры, последние хотя и выглядят как отдельные процессоры, таковыми не являются
Нет, пересекаются они уже почти на выходе из кристала (на кэшэ 1го уровня и мосте к PCI (или др) шине)
Все таки именно 'паралельно'
Специализация начинается на комутации памяти между разными процессорами, и начинается это в кластерных системах
Вообще то таких статьей до фига и более
Микроархитектуру вам конечно не раскажут, но по поводу 'паралельности/перпендикулярности' данные производителей вполне доступны (developer.intel.com) Вот например: Nehalem

параллельный - да, не стоит искать подводные камни, мы говорим о ядрах, т.е. о виртуальных процессорах

управляющие - исходящие, т.е. контролирующие внешние процессы на периферии, по-моему, я ясно выразился

ты наверное хотел, чтобы тебя поняли? ) или я не прав?

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

да, об этом мы уже упомянули

если не сложно, ткни в нужный кусок, как я это сделал выше

Когда-то проводил такой эксперимент, написал программу, которая считает сколько раз в тексте встречается то или иное слово. Для начала использовал обччную хэш таблицу (ключ-слово, значение-количество повторений этого слова в тексте) и скармливал ей войну и мир, Анну Коренину и еще что-то, программа пережевывала все примерно за 20 секунд. Потом я вместо обычной хэш таблицы использовал tbb::concurrent_hash_map из библиотеки threading building blocks, эта штука не лочит всю таблицу целиком, а только один bucket при изменении его содержимого из 2х потоков. Так-же я запустил 2 потока(машина у меня 2х ядерная). Стало работать почти в 2 раза быстрее 

Добавлено через 1 минуту и 23 секунды
точные цифры не помню, но что-то около 45% прироста в скорости у меня точно получилось  

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

Добавлено через 5 минут и 59 секунд
Lazin, а на одном процессоре та же конкурирующая карта сколько выполнялось?
в твоей-то задаче суть ускорения не в том, что 2 ядра, а в том, что общее время на процесс увеличилось вследствии введения нескольких потоков, от-того обычно и многопоточные приложения быстрее однопоточных на 1 процессоре

когда я использовал tr1::hash_map из 2х потоков и синхронизировал доступ к нему, все работало в два раза медленней, с большой степенью точноти  
c tbb::concurrent_hash_map все работало в два раза быстрее, обя ядра были загружены полностью, а в первом случае общая загрузка 2х процессоров не превышала 50%, что не удивительно.
Я могу завтра выложить исходник который я использовал для тестов.

Добавлено через 3 минуты и 36 секунд
в однопоточном режиме, tr1::hash_map работает немного быстрее чем tbb::concurrent_hash_map, так-как синхронизация все-же есть(на уровне bucket-ов хэша), но она выполняется в пользовательском режиме, там используется bysy wait вместо ожидания в режиме ядра.

Чего ради они виртуальные? И чего ради 'паралельный' должен КАЖДЫЙ выходить наружу? 

Тогда непонятно, в чем сомнения?

Хотел, но видимо не судьба. Как ответить на вопрос, если твой ответ не понимают? Попробую еще раз:
В SMP системе ВСЕ процессоры, вне зависимости от того, внутри они одного кристала или в разных, сидят на ОДНОЙ шине, поэтому нет НИКАКОЙ разницы внутри корпуса они посажены на эту шину или снаружи - результат будет один и тот же
О, как все запущенно   Вы в курсе, что эта внешняя шина работает на частотах на несколько ПОРЯДКОВ меньших, чем сама корка? И что кэш для того и применяются, что бы процессор работал не с частотой внешней шины, а гораздо быстрее. Так что, при таком отношении скоростей процессоры (корки) вполне успевают прокачать все, что им нужно, через эту шину не мешая друг другу. Совершенно банальное временное разделение.
Вообще то это и был тот самый кусок, там ссылка на публично доступное описание микроархитектуры (Core i7)
Если будут КОНКРЕТНЫЕ вопросы по микроархитектуре, спрашивай. Закрытые части я понятно рассказать не смогу, но в пределах общедоступных, всегда пожалуста   

виртуальный, логический - какая разница

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

хорошо, сделаем по-другому:

есть у нас дорога,
по ней из пункта А в пункт Б едут в одном направлении две фуры с грузом
едут они на одном уровне,  т.е. по двум полосам - параллельно
к финишу они приедут одновременно и на перевозку грузов уйдет время, потраченное как за одну фуру

теперь, та же ситуация, но дорога - однополосная
для того, чтобы фуры приехали одновременно, есть 2 варианта:
  либо расширить дорогу до 2-х полос, 
  либо заменить фуры на магогабаритки
в обоих случаях, перевозчик теряет большие деньги: в первом случае - на строительство, во втором - на грузе, перевозка которого уменьшится

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

вот и вся разница

а на конвейере, происходит то же самое, только первый груз придет с задержкой на всю длину маршрута, после чего - поток данных (фур), друг-за другом, по одной - не параллельно, но с минимальными издержками
такая система и называется "системой реального времени"


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

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

даже если кэши у процов параллельные, они не для того предназначены, просто позволяют не обращаться лишний раз в уже прочитанную память, на периферию,
в том-то и дело, что если бы мы могли управлять этими параллельными кэшами, располагающиеся "рядом" с каждым процом, тогда и выигрыш могли бы сами контролировать. Кстати, ПЛИС'ы сейчас "модно" снабжать индивидуальной памятью, такие платки как-то даже так и называют "мега", или "монстр", вроде бы монстр ). Это просто говорит о том, что даже сейчас люди работают над новыми архитектурами, более гибкими, более управляемыми, более "реальными".


я прсто делаю вывод, что эту ссылку ты дал только для подтверждения слов:

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

ps: xvr, обрати внимание, пожалуйста, на тон своих ответов, я против тебя пока ничего обидного не делал.

Разница в том, что они вполне физические 
 Пардон, я никоим образом не касался систем реального времени, для них SMP в общем и целом не нужен. Все эти пляски с корами в основном делаются ради HPC (High Performance Computing), т.е. там, где надо что то массивно посчитать. 
 Пардон еще раз, вся специфичная терминология скорее из области HPC (как раз от програмистов), к схемотехнике она имеет меньшее отношение.

 Аналогия неправильная. Это было бы так, если бы процессор брал байт из памяти, обрабатывал его, и складывал обратно в память. Приведу другой пример:
У нас есть фабрика по производству керамической плитки. Она обнесена высоким забором, в котором есть одни ворота, через них въезжают грузовики с глиной и выезжают грузовики с готовой плиткой. Цикл производства занимает 1 день. Т.е. фабрика трудится вовсю, но грузовики приезжают 2 раза в день - привести глину и забрать плитку.
Теперь за забором постоили еще одну фабрику. Теперь там трудится 2 фабрики, выработка плитки возрасла в 2 раза, грузовики проезжают 4 раза в день, но это все еще очень далеко от реальной пропускной способности ВОРОТ.
И в multicore происходит то же самое - коры стараются вовсю, но их общий интерфейс вполне справляется с потоком.

 Хм, или я чего то не понимаю, или одно из двух   Вышеописанное называется pipeline (конвеер), а 'система реального времени' это система с детерминированными временами реакции на внешние сигналы. Или мы говорим о разных вещах?
 В очереди они могут стоять только для обращения к внешней аппаратуре, а в таких приложениях (где идет постоянная работа с внешними устройствами) SMP бесполезно.
 Неа, запись тоже буферизуется и выполняется при свободной шине (так называемый Write Back кэш, кстати, он сейчас везде такой)

 Память и переферия - это две БОЛЬШИЕ разницы. Память буферизуется кэшами, как на чтение, так и на запись. Переферия - нет.

 Не понял, что подразумевается под словом 'управлять'? Если имеется в виду возможности что то кэшировать, а что то нет, то такое управление существует.

 Это уже совершенно другие системы, не SMP и предназначенные для других областей.

 Оттуда все вполне можно найти. Хорошо, вот более конкретная ссылка: Intel® 64 and IA-32 Architectures Software Developer’s Manual страницы с 41 и далее

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

Возвращаясь к началу обсуждения, я утверждаю, что core'ы, упакованные в один чип, и core'ы представленные физически разными чипами (в SMP архитектуре) полностью идентичны.

) хороший пример   

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

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

Никак   
Для мультиядер есть 3 случая, когда эта самая ядерность не работает:

•  Задача в принципе не распаралеливается, т.е. работать может только одно ядро, для других нет работы 
•  Задача интенсивно общается с устройствами ввода/вывода. Ядра, все сколько есть, будут стоять на обмене с внешним миром
•  Задача требует большого объема данных и он не умещается в кэшах. Все коры повиснут на интерфейсе к памяти. У Nehalem'а это поток в 32 GBs (насколько я помню)

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

Как раз относится, в SMP режиме моногокоровый и N однокоровых будут давать идентичные результаты. В кластерной системе N однокоровых с N раздельными памятями и коммутатором могут дать лучший результат (а могут и не дать)