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

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

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

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

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

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

Когда-то проводил такой эксперимент, написал программу, которая считает сколько раз в тексте встречается то или иное слово. Для начала использовал обччную хэш таблицу (ключ-слово, значение-количество повторений этого слова в тексте) и скармливал ей войну и мир, Анну Коренину и еще что-то, программа пережевывала все примерно за 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 раздельными памятями и коммутатором могут дать лучший результат (а могут и не дать)