OSDev

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

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

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

Ну дык... должны же быть исключения, подтверждающие правило ))



Собсно, написал уже в ответ на сообщение Павии. Подобные процессоры есть, но они не универсальны, а автор же явно спрашивает про "обычные" процессоры для обычных ПК и, возможно, всяких там смартфонов. С универсальными же (во всяком случае, высокопроизводительными) такое не светит, и от архитектуры тут не очень много что зависит. Например, декодирование команд и управление памятью ARM или MIPSкуда проще, чем IA-32, поэтому процессор архитектуры АРМ/МИПС теоретически много проще, чем процессор архитектуры ИА-32. Но это верно лишь до тех пор, пока процессор -- "тупой", без всяких там суперскалярностей и спекуляций (что имеет место быть для большинства тех же АРМов -- только последние ядра вроде Cortex-A9 и Cortex-A15 обладают суперскалярностью). Если же процессор имеет сложную микроархитектуру, поддерживающую все эти навороты (без которых нельзя достигнуть действительно высокой производительности одного ядра), вопрос со сложностью декодирования команд и MMU отходит на очень задний план. Да, из-за дурной системы команд ИА-32 всегда будет более сложен, чем аналогичный с остальных точек зрения АРМ или МИПС, но разница в сложности будет уже невелика, поэтому замена одной архитектуры на другую не даст кардинально повысить число ядер.

1. Нет задач которые нельзя распаралелить.
2. Нет алгоритмов которые нельзя распаралелить.
3. Есть только те алгоритмы которые плохо паралелятся. Чтобы получить прирост в скорости в 2 раза надо 4 ядра. Чтобы в 4 раза надо 16 ядер. 8 раз 64 ядра.
Есть которые совсем плохо. У них прирост оставляет не более (n-2)/n при 4 кратном увеличении ядер.
4. Вопрос только в поиске другого алгоритма который решает туже задачу, но не будут столь привередливым.
5. Понятно что самое простое это просто увеличить частоту процессора.
Хотя есть и другой подход изначально писать параллельный код.


Это вообще не проблема. И элементарно решается. Как рассказывать не буду, секрет, очень много писать что-бы объяснить. Хотя вам дам подсказку. Железячники(плисоводы) умеют писать такой код. Так как у них весь код параллельный! А программистов учат думать последовательно, поэтому они не умеют думать и как следствие писать качественный параллельный код.


Основная проблема многоядерности это ветвления. Дело в том что ядра должны исполнять свой код. И надо в них как-то загружать новый код. Современные офисные программы имеют код размером в 10МБ что ни в один кэш не влезет. Который насчитывает от 1 до 128 кб
Нужно просто создать эффективный способ загрузки. А это в принципе возможно. Если код нарезать на составные части и разместить по кластерам ядер. А после переключать ядра.
Что в принципе будет работать если суммарный кэш команд сделать 100 мб. Добавить загрузку да хотя бы раз в 1 мс. Надо посчитать но в принципе такой подход будет не чуть не хуже существующего. Может не столь эффективный по энергетике зато эффективный по скорости.

Куча бреда.



Такие задачи и алгоритмы есть. Это любые задачи, где расчёт необходимо вести итеративно, и результат каждого следующего шага зависит от результата предыдущего. Если Вы таких задач не знаете -- это показатель Вашего кругозора и не более того.



Наверняка что-то настолько гениальное, что никто другой в принципе до этого догадаться не способен.



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

Это у вас кругозор маленький. Такие задачи паралелятся. См.
http://www.intuit.ru/studies/courses/58 ... cture/5556
Ссылка работает только после регистрации. Там теория.
А на практике могу продемонстрировать на примере сумматора. Как сумматор работает знаете?
Для того чтобы сложить два числа. Надо сделать последовательный перенос бита. Процесс этот интерационно и идёт по всем битам.
Однако хорошо известен паралельный сумматор, который работает быстрее.

Ничего нового нет. Однако парадоксально, но 99% программистов неспособны найти ответ.
Это не я гениальный это общество не созрело. Надо просто менять способ мышления. Тогда поменяется и подход к программированию.


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

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

Для не совсем понимающих, но желающих разобраться, о чём речь, привожу в пример принципиальную схему так называемой схемы (прошу прощения за тавтологию) ускоренного переноса (СУП; см. скриншот даташита внизу). Её задача -- как раз формировать сигналы промежуточных переносов сразу, без ожидания формирования предыдущих переносов во время выполнения сложения или вычитания. Подобные схемы являются необходимой частью любого многоразрядного параллельного двоичного сумматора. Как легко заметить, для формирования младшего из переносов (на схеме обозначен как Cn+x, вывод 12 микросхемы -- это схема реального чипа 74182, а соответственно, и его отечественной копии К155ИП4) достаточно трёх логических элементов -- двух двухвходовых И и одного двухвходового же ИЛИ-НЕ. Формирование следующего разряда (Cn+y, вывод 11) требует уже двух трёхвходовых И, одного двухвходового И и одного трёхвходового ИЛИ-НЕ. Третий перенос (Cn+z) требует ещё больше элементов с большим числом входов. Ну а логические элементы -- это не только площадь на кристалле и энергопотребление, но ещё и длины связей между ними (понятно, что, чем больше элементов и чем большую площадь они занимают, тем длиннее будут соединяющие их проводники). Всё это приводит к увеличению времени задержки распространения сигнала, поэтому, даже если считать, что собственно сложность не является ограничением, 64-разрядный параллельный сумматор будет существенно медленнее 4-разрядного -- хотя с точки зрения чистой логики (не учитывающей реальную физику) схемы вроде бы должны быть одинаково быстрыми. Всё это и является причиной, почему в реальной жизни полностью параллельные многоразрядные сумматоры не встречаются -- они заняли бы недопустимо большую площадь кристалла, не окупаемую повышением производительности. Сюда можно добавить технические сложности с созданием многовходовых логических элементов большого быстродействия.

В итоге в реальности используются последовательно-параллельные сумматоры. В частности, во времена, когда была создана микросхема 74182 (а за ней -- куча других подобных схем), обычной практикой было использование 4-разрядного последовательного АЛУ (выполняющего, помимо прочего, операции сложения и вычитания) совместно с подобными схемами ускоренного переноса. Одна такая СУП способна обслуживать 4 АЛУ, что в результате позволяло построить 16-разрядное последовательно-параллельное АЛУ. СУП допускают наращивание своей разрядности (выходы G и P в верхней части приведённой схемы подаются на соответствующие входы СУП более высокого "порядка"), но это тоже получается последовательно-параллельная схема, а не чисто параллельная, как одиночная СУП.

То же самое касается, например, умножения. Теоретически можно умножение выполнить чисто параллельным образом. Скажем, умножение двух 4-разрядных двоичных чисел требует выполнить сложение четырёх промежуточных произведений (по одному на каждую цифру множителя), для чего вроде бы достаточного одного 7-разрядного 4-входового сумматора. Такие схемы вполне реально создать; более того, они существуют (например, у нас выпускался 4-входовый 4-разрядный сумматор -- кажется, КР1802ИМ1; понятно, что он был содран с какой-то буржуйской микросхемы, и предназначался в первую очередь как раз для построения быстродействующих умножителей). Проблема в том, что с увеличением количества разрядов и числа входов (слагаемых) сложность такого сумматора очень быстро нарастает. Поэтому на практике многоразрядное (скажем, 32- или 64-битное) осуществляется за несколько циклов, в каждом из которых производится суммирование частных произведений с получением всё менее "частных", пока не будет получено единственное итоговое произведение. Такое суммирование можно выполнять конвейерным образом, благодаря чему при выполнении нескольких команд умножения подряд у программиста складывается впечатление, что каждая из них выполняется за один такт. Однако латентность (задержка между началом выполнения операции и получением её результата) довольно велика -- скажем, 4 такта, поэтому, если сразу за командой умножения следует другая команда, использующая результат умножения, процессор вынужден будет ждать окончания умножения. (Ну, на практике суперскалярный процессор с возможностью внеочередного выполнения инструкций попробует заняться какой-нибудь другой работой, которую выполнить уже можно, но это к теме распараллеливания умножения не относится никоим образом, да и очень усложняет сам процессор).

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

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



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

Кстати говоря, ёмкость традиционного кэша 1-го уровня ограничивает не невозможность впихнуть больший объём (в конце концов, помимо маленьких кэшей 1-го уровня, на том же самом кристалле процессора присутствуют более ёмкие кэши 2-го уровня, а зачастую -- ещё и 3-го; в процах мэйнфреймов IBM, если память не изменяет, сейчас 4 уровня кэшей). Главным ограничением является как раз необходимость иметь довольно небольшие размеры и простую коммутацию, чтобы обеспечить быструю работу кэша 1-го уровня -- чтобы собственно процессорное ядро не простаивало, дожидаясь, когда там кэш разродится очередной порцией информации. Дополнительное ограничение -- тепловыделение (частые переключения транзисторов означают большую рассеиваемую в виде тепла мощность, которую нужно отводить от кристалла, что является отнюдь не тривиальной задачей для высокопроизводительных процессоров).

Да я прошу извинить. Совсем нет времени писать на форуме. Устроился в автошколу. То на вождение надо ходить то билеты учить. Были праздники поэтому дома накопились дела.
А то что я с фрименом днём трепался. То была местная командировка и пока ехал было время почитать и написать ответы. Благо он не спрашивал ни чего нового для меня поэтому отвечать было легко.



Да там хуже. Сразу скажу что можно распаралелить. За основу можно взять вот этот алгоритм и его распарлелить. http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf


Тоже нет проблем. Физическое уравнение как правило описывается дифференциальным уравнением. Если есть начальные условия. То это задача с открытой границей.
Решается такое уравнение путем интегрирования. Наиболее известный метод численного интегрирования это метод Рунге-Кутты.
Такую задачу тоже можно решать и параллельно! Для этого достаточно сделать закрытую границу. Так нам всего на всего надо сделать замену b=1/t или использовать билинейное преобразование. Тогда приделы интегрирования станут равными от 0 до 1.
Далее используем методе конечных элементов. А он основан на решение системы уравнений методом наименьших квадратов. А для него известны быстрые параллельные алгоритмы.


Задержка распространения сигнала по металлической линии в SIO2. Составляет 6.7 пс/мм Откуда имеем придел для 35 мм(самый большой чип на сегодня). 4.2 ГГц. Снизим частоту да хоть до 2 ГГц. В ведём не 3 такта на чтения из кэша, а 6 тактов. И того падение в 4 раза. И эта константа никак больше расти не будет. Максимум еще в 2 раза. Но поставим размножитель рядом с кэшем. Будем читать параллельно с него по скажем по 32 потока. И будем иметь прирост в 4 раза. Будет больше ядер будет ещё более выгодно.

Это вопрос важный. Но он решаем. Никто не говорит о том что было 128 сделали 1280 ядер. Будет увеличение в 4 раза, а может 8. Надо будет просто поссчитать. А в виду того что предлагается другой подход к программированию, то даже что-бы сделать хоть какую оценку надо много написать нового кода.

http://www.3dnews.ru/918787?from=relate ... rce=902665
Вот это честно потрясает. Честно я не ожидал что Intel сможет сделать это так эффективно. Тест Spec 2006 достаточно жестокий, в нём не только Linpak, но и сжатие и другие повседневные программы.
График соответствует схема 4 ядра превратить в 1 последовательное, но работающему на скорости в 2 раза большей чем обычное 1 ядро.

На самом деле, думается, всё идёт к тому, что не будет нескольких традиционных ядер (т.е. независимых процессоров) на одном кристалле -- будет одно-единственное физическое ядро (как бы один процессор), но с гипертредингом не на два параллельных потока, а на большее их число. Соответственно, все имеющиеся исполнительные блоки процессора окажутся доступными при необходимости одному-единственному потоку. Это весьма и весьма разумно. Например, имеются задачи, не поддающиеся распараллеливанию на отдельные потоки, но допускающие одновременное выполнение нескольких операций внутри одного потока. Понятно, что число реально выполняемых операций ограничено числом имеющихся исполнительных устройств. Скажем, если у процессорного ядра два блока для простых целочисленных операций (типа сложения или логического И), то только две таких операции и сможет выполняться параллельно для одного потока -- хотя у других ядер того же процессора аналогичные блоки могут стоять без дела. А вот если процессор всего один, но у него 8 таких блоков (сколько их было бы в 4-ядерном с двумя блоками у каждого), то для этого потока может быть выполнено до 8 операций параллельно.

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