Тута образовалось две занятные темы. Быстродействие видеосистем и умножение матриц. И вот что мне подумалось, мы разговариваем здесь только в контексте современной традиционной архитектуре. А ведь эти задачи решаемы. Нужно просто отойти от догм традиционной архитектуры.
Что я подразумеваю под традиционной архитектурой. Традиционная архитектура процессор, обращающийся к памяти и последовательно выполняющий команды. То бишь, Фон Нейман во всей его красе и недостатках. Если я скажу, что у архитектуры имеется большой недостаток, я Атлантиды не открою. Это еще сделал Бэкус в знаменитой Тьюринговой лекции Can programming be liberated from the von Neuman style? (правда думаю что это настолько очевидно, что кто-то мог это ляпнуть и раньше). А именно, bottleneck в шине памяти. Можно сколько угодно убыстрять работу памяти, работу процессора, но шину между процессором и памятью убыстрить такими же темпами не удастся. Это в принципе заметно и сейчас – добавление процессора не дает скачка в 100%.
Как решить проблему быстродействия? Легко. C помощью параллельных вычислений. Большинство часто встречающихся и в то же время тяжелых для процессора алгоритмов, как то сортировка, или то же умножение матриц легко делается с помощью алгоритмов разделяй и властвуй. Те же матрицы могут быть разделена на несколько, раздельно вычислены частями и затем вычислены уже в одну матрицу. Или возьмем, ту же видеопамять. Допустим у нас существует 10 процессоров. Каждый работает со своей областью памяти. При приходе команды на вывод строки, команда разделяется по разделам памяти, и каждый процессор выполняет вывод своих символов. Если нельзя увеличить быстроту шины, то почему бы и не увеличить количество шин. Я верю что данная архитектура будет более производительной чем традиционная. И это в принципе доказано. mainframe системы как раз и строятся на параллельных алгоритмах и архитектурах. Мы слишком привыкли к традиционной архитектуре. Все что делается и делалось, например те же учебники по алгоритмам, подразумевают традиционную архитектуру с последовательным выполнением команд.
Некоторые естественно сразу подумали, а ведь современная архитектура уже параллельна. NUMA хоть в виде кэша есть(NUMA – Non uniform Memory Architecture. Каждый процессор имеет свою локальную память). Ну и внутри у него несколько Risk процессоров(а сейчас и ядер несколько). В общем все это есть, а вот счастья нет. Потому как не работает это все на полную мощность. И никогда не заработает, пока все, от железа до OS и компилятора и программиста не смогут распараллелить вычисление сознательно и вручную. Но зато можно сказать, что аппаратных проблем для стандартного писюка уже нет.
Сейчас OS распараллеливает программы и потоки. Ничего хорошего и удобного я об этом сказать не могу. Кроме грыжи и расшатанных нервов такая синхронизация не приносит. И процессор, который на внутреннем уровне состоит из нескольких процессоров, выполняет один поток команд. Мы платим деньги только за один поток команд. А теперь представим, у нас есть несколько управляемых процессоров. У каждого процессора есть своя личная память. Мы загружаем в каждый процессор подпрограмму, и выполняем независимо. Пускай даже эти процессоры работают медленнее чем теперешние, но выигрыш мы получим. Единственное что, языки не поддерживают данное начинание.
Mainstream языки ориентированы на последовательное выполнение команд. Максимум поддержки – это ручная синхронизация данных в виде какой-нибудь lock или critical_section. Ничего кроме торможения, и нелокализованных ошибок это не приносит. Но ведь компилятор имеет всю информацию для того, чтобы организовать параллельную обработку данных. И язык должен вынудить программиста писать программы, которые легко распараллелить. Я не сторонник функциональных языков, но они могут такое. Они вынуждают разделять функциональность на функции без состояния. Только входные и выходные параметры. О синхронизации данных, можно забыть. Можно ли это организоваться в ООП программах? Наверняка можно. Есть фичи типа активных объектов. Это когда объект имеет свой поток выполнения. Считай что набор подпрограмм для процессора. Может данная фича мне и не нравится(это мое личное IMHO) но она все-таки есть. И наверняка есть другие способы безопасного распараллеливания. Я боюсь даже догадываться о том, что можно придумать. У компилятора – вся необходимая информация есть. Если он откажется от мысли, что код должен быть именно такой каким его написали, то ограничения снимаются и возможности повышаются.
Возможна ли революция? По моему нет. Практически все что можно в языках программирования придумали в 50-60 годах. И в том числе Algol, Lisp и параллельное программирование. Ничего кардинально нового не появилось. В mainstream остался только Алгол, который стал вбирать многие средства Lisp(и вбирает до сих пор). Но Лиспом он не стал и не станет. Так же и в архитектурах. Intel вбирает в себя параллельную архитектуру (и вбирает до сих пор), но параллельным не станет. А следовательно будем дальше мучиться с синхронизацией shared memory, и оптимизацией качества кода для конкретного процессора.

С уважением, Gleb.

Идею смены архитектуры полностью поддерживаю, так как по-моему назрела она давно.
А вот по поводу способов — как это можно сделать — вызывают большие сомнения.

Начну с самой очевидной идеи распараллеливания — кучи процессоров с собственной памятью. Идея прекрасная и давным-давно уже применяется. Великолепно работает, когда нужно провести много идентичных вычислений, особенно для тех алгоритмов, которые допускают разбиение на отдельные и распараллеливаемые фрагменты (вот как те же матрицы). Однако далеко не все алгоритмы столь хороши. Есть случаи, когда скорость вычислений будет расти как логарифм от числа процессоров. А добиться увеличения производительности в 6-10 раз, за счёт миллиона процессоров — может быть несколько накладно... Это главное препятствие математического плана.

Теперь о программировании. Идея написания языка, который автоматически обеспечивал бы распараллеливание (или хотя бы облегчал его) — витает очень давно. И попытки создать такой язык предпринимались неоднократно — вспомнить хотя бы бум вокруг транспьютеров и языки программирования, которые были для них созданы. И хотя некоторый прогресс и был достигнут — до серебряной пули или базового решения, которое можно было бы использовать, как основу для новой технологии, оказалось довольно далеко. Оказалось, что для достижения действительно высоких результатов от разработчика требуется квалификация и трудозатраты идентичные тем, что требуются для обеспечения параллелизма на обычных языках. То есть — весьма существенные. И это является главным препятствием. Где то я видел оценку, по которой написание и отладка многопоточного (распараллеливаемого кода) получалась от 10 до 50 раз дороже, чем написание кода обычного — однопоточного. Хотите проверить — напишите многопоточную сортировку, которая будет работать быстрее однопоточной

К вопросу о шинах между процессором и памятью. Взгляд совершенно здравый — они действительно являются зачастую узким местом в системе. И их действительно нужно распараллеливать. Однако это не обязательно требует распараллеливания процессоров. Можно увеличить количество шин между процессором и памятью не увеличивая количество ядер. При определённом подходе это даст хороший прирост производительности, особенно, если в пересылку данных одновременно с процессором вовлечены другие устройства или процессоров – несколько. Впрочем, и эта технология сейчас активно применяется.

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

Здравствуйте, AndreyFedotov, Вы писали:

AF>Начну с самой очевидной идеи распараллеливания — кучи процессоров с собственной памятью. Идея прекрасная и давным-давно уже применяется. Великолепно работает, когда нужно провести много идентичных вычислений, особенно для тех алгоритмов, которые допускают разбиение на отдельные и распараллеливаемые фрагменты (вот как те же матрицы). Однако далеко не все алгоритмы столь хороши. Есть случаи, когда скорость вычислений будет расти как логарифм от числа процессоров. А добиться увеличения производительности в 6-10 раз, за счёт миллиона процессоров — может быть несколько накладно... Это главное препятствие математического плана.

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

Здравствуйте, AndreyFedotov, Вы писали:

AF>Идею смены архитектуры полностью поддерживаю, так как по-моему назрела она давно.
AF>А вот по поводу способов — как это можно сделать — вызывают большие сомнения.

AF>Начну с самой очевидной идеи распараллеливания — кучи процессоров с собственной памятью. Идея прекрасная и давным-давно уже применяется. Великолепно работает, когда нужно провести много идентичных вычислений, особенно для тех алгоритмов, которые допускают разбиение на отдельные и распараллеливаемые фрагменты (вот как те же матрицы). Однако далеко не все алгоритмы столь хороши. Есть случаи, когда скорость вычислений будет расти как логарифм от числа процессоров. А добиться увеличения производительности в 6-10 раз, за счёт миллиона процессоров — может быть несколько накладно... Это главное препятствие математического плана.

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

AF>Теперь о программировании. Идея написания языка, который автоматически обеспечивал бы распараллеливание (или хотя бы облегчал его) — витает очень давно. И попытки создать такой язык предпринимались неоднократно — вспомнить хотя бы бум вокруг транспьютеров и языки программирования, которые были для них созданы. И хотя некоторый прогресс и был достигнут — до серебряной пули или базового решения, которое можно было бы использовать, как основу для новой технологии, оказалось довольно далеко. Оказалось, что для достижения действительно высоких результатов от разработчика требуется квалификация и трудозатраты идентичные тем, что требуются для обеспечения параллелизма на обычных языках. То есть — весьма существенные. И это является главным препятствием. Где то я видел оценку, по которой написание и отладка многопоточного (распараллеливаемого кода) получалась от 10 до 50 раз дороже, чем написание кода обычного — однопоточного.
Но вот с этим несогласен. При текущих мейнстримовых языках, писать многопоточные приложение действительно нелегко. А особенно отлаживаться. Но возьмем к примеру функциональный язык. Он вынуждает программиста не держать состояний за пределами функций. В результате, мы можем прозрачно накормить каждый процессор данной подпрограммой. Но для этого нужно чтобы и OS и процессор знали что такое подпрограмма. То есть, нужно не тупое выполнение последовательности инструкций, нужно выполнение именно подпрограмм.
AF>Хотите проверить — напишите многопоточную сортировку, которая будет работать быстрее однопоточной
Вот как раз quick сортировку описать действительно легко. Только я этого делать не буду. Потому как нет удобных средств распараллеливания. Я вообще не хочу заниматься распараллеливанием. Пускай этим будет заниматься компилятор и OS. У них достаточно знаний для этого.

AF>К вопросу о шинах между процессором и памятью. Взгляд совершенно здравый — они действительно являются зачастую узким местом в системе. И их действительно нужно распараллеливать. Однако это не обязательно требует распараллеливания процессоров. Можно увеличить количество шин между процессором и памятью не увеличивая количество ядер. При определённом подходе это даст хороший прирост производительности, особенно, если в пересылку данных одновременно с процессором вовлечены другие устройства или процессоров – несколько. Впрочем, и эта технология сейчас активно применяется.
Сейчас разговор идет именно о mainstream. В действительности производители уже отошли от увеличения разрядности шины к алгоритмам одновременного доступа. Но говорить что DDR действительно эффективен, по моему, нельзя. Это попытка остаться в рамках текущих технологий. Тут нужны более целенаправленные и эффективные меры, для которых нынешняя архитектура не особо подходит.

AF>В общем-то, очевидно, что сейчас распараллеливание (и ядер и шин и отдельных процессором) является основной технологией и создание средств, которые обеспечивали бы её использование (в том числе и новых языков) – весьма востребовано. Однако как раз в области языков особо новых идей пока и не видно. Хотя возможно вместе до чего и додумаемся.
Честно говоря работа в данной области ведется и не останавливалась. Можно вспомнить гугловские кластеризованные серваки. Или comega.

С уважением, Gleb.

Здравствуйте, Дарней, Вы писали:

Д>Компьютерная графика, например — прекрасно распараллеливается
Д>Интересно — а какие еще задачи создают большую нагрузку на процессор, и насколько легко их можно разделить по процессорам?
Я думаю, что в основном сортировка, поиск, и обработка больших массивов. В остальном производительность процессора избыточна. Для первых двух распараллеливание подходит на 100 процентов. Для обработки больших массивов, частично тоже.
Д>Статистика? Базы данных?
Для баз данных эта проблема уже решена. У них свои алгоритмы распараллеливания. Они разбивают запрос на подзапросы, и раздельно выполняют. Но они и дальше развиваются. Например — здесь. Там было определено дальнейшее развитие теории БД. Отдельным пунктом идет Sensor Data and Sensor Networks. Гугловкий сервак параллелен по самое нехочу. Точно знаю что ведутся работы по разложению XQuery запросов на подзапросы, и раздельное выполнение.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Но вот с этим несогласен. При текущих мейнстримовых языках, писать многопоточные приложение действительно нелегко. А особенно отлаживаться. Но возьмем к примеру функциональный язык. Он вынуждает программиста не держать состояний за пределами функций. В результате, мы можем прозрачно накормить каждый процессор данной подпрограммой. Но для этого нужно чтобы и OS и процессор знали что такое подпрограмма. То есть, нужно не тупое выполнение последовательности инструкций, нужно выполнение именно подпрограмм.

Так устроены шейдеры в последних поколениях GPU. Это некая подпрограмма, выполняемая для каждого вертекса или пиксела. Они не то что бы очень быстрые, но зато "дуют в 32 струи". Но, со всеми вытекающими — например, сметить подпрограмму шейдера — операция сравнительно дорогая. И там тоже много засад, где можно свести на нет все усилия по распараллеливанию.

http://www.rsdn.ru/Forum/Message.aspx?mid=1410129&only=1

Автор: McSeem2
Дата: 29.09.05

Можно представить себе следующую схему (я, кстати говоря, еще лет 15 назад о такой мечтал). У нас есть светодиодная матрица 8000x6000. Под каждым пикселом находится маленький процессор и сотня байт памяти. Этот процессор умеет выполнять операцию AlphaBlend. В продвинутых случаях — остальные color compositing операции. Управляются эти процессоры строчно-столбцовым способом. Типа "открыть порт для передачи данных по всей строке номер 1343 — передать данные в колонку 2345". Таким образом мы засветили один пиксел. Закраска прямоугольника 1000x1000 при этом требует не миллион итераций, а всего-навсего 1000+1000. Anti-aliasing при таком разрешении нам не нужен и это сильно упрощает дело. Кроме того, каждый пиксел может сам себе быть альфа-маской и/или z-буфером.

Да, очень многие операции поддаются распараллеливанию таким образом. Но не все. Например, что делать, если нам нужно смасштабировать изображение с передискретизацией (resample)? — это основная операция в современных 3D-акселераторах? Надо, что бы кажый элементарный процессор как минимум имел доступ к некой общей памяти или должна быть некая сеть для коммуникации. А вот это уже очень нетривиально обеспечить. Я бы даже сказал, что практически невозможно — количество проводов растет по квадратичному закону.

Но это все в общем-то тривиально — есть вещи гораздо более удивительные. Как бы мы ни наращивали число процессоров — тысячи, миллионы, миллиарды — не имеет значения. Это все жалкие копейки для ряда задач (весьма обширного, кстати). Типичная задача — разложение большого числа на простые сомножители. Если мы задействуем 1000 процессоров с недостижимым коэффициентом распараллеливания в 1.0, мы всего-навсего можем разложить число в 1000 раз большее (грубо говоря три лишние десятичные цифры). Каковы усилия и каков результат?!
Данная задача является вообще не решаемой на машине Тьюринга. И даже на параллельной машине Тьюринга. Казалось бы, она вообще не решается. Однако, математики доказали, что алгоритм Шора позволяет разложить натуральное число n на простые множители за полиномиальное от n время. Но для этого требуется квантовый компьютер. Здесь я боюсь скатиться в дебри, но раз доказано, что алгоритм Шора работает (не имеет значения, что он пока нереализуем на практике), то откуда "черпается" вся эта вычислительная мощность в квантовом мире?! Согласно гипотезе о мультиверсе, в процессе квантового вычисления принимает участие совершенно невообразимое количество параллельных вселенных (юниверсов), скажем, 10^500. И посредством интерференции мы можем "вытащить" результат в наш мир. Убойная трава у этих физиков растет!

Это я не к тому, чтобы рассуждать на темы множественности миров, а лишь к тому, чтобы подумать — а возможно ли что-то принципиально новое в обычном (неквантовом) вычислительном мире? Мне сдается, что все, что мы можем — лишь наращивать мускулы. Никуда не уйти от банальной машины Тьюринга, сколько бы процессоров мы ни приделывали. Грубо говоря, функциональный язык, распараллеливающий вычисления на 1000 процессоров, всего-навсего эквивалентен процедурному языку, работающему на процессоре в 1000 раз более шустром. То есть, игра с исусственным распараллеливением не стоит свеч. Да, для ряда задач это хорошо и правильно, например, для 3D акселераторов. Но не в качестве универсального вычислителя. У меня есть большие сомнения, что это вообще возможно — построить универсальную машину на принципах искусственного распараллеливания. Распаралеливание должно быть естественным, природным — вот как в теории квантовых вычислений. И вот там, возможно (но не гарантировано), удастся не только создать универсальную параллельную машину, но и решать принципиально новые задачи.

Здравствуйте, GlebZ, Вы писали:

А новый ibm'овский процессор cell (http://www.3dnews.ru/cpu/cell/) это не то что ты хочешь?

Здравствуйте, Дарней, Вы писали:


Д>Компьютерная графика, например — прекрасно распараллеливается

Графику в современых GPU уже аппаратно распаралелили так что вроде дальше некуда

Здравствуйте, McSeem2, Вы писали:

MS>Так устроены шейдеры в последних поколениях GPU. Это некая подпрограмма, выполняемая для каждого вертекса или пиксела. Они не то что бы очень быстрые, но зато "дуют в 32 струи". Но, со всеми вытекающими — например, сметить подпрограмму шейдера — операция сравнительно дорогая. И там тоже много засад, где можно свести на нет все усилия по распараллеливанию.
Занятно, но к сожалению слишком специализированно. А так хочется мэйнстрима.

MS>http://www.rsdn.ru/Forum/Message.aspx?mid=1410129&only=1

Автор: McSeem2
Дата: 29.09.05

Блин, забыл ссылки сделать на сообщение. Именно твое сообщение и дало толчок на написания топика.

MS>Да, очень многие операции поддаются распараллеливанию таким образом. Но не все. Например, что делать, если нам нужно смасштабировать изображение с передискретизацией (resample)? — это основная операция в современных 3D-акселераторах? Надо, что бы кажый элементарный процессор как минимум имел доступ к некой общей памяти или должна быть некая сеть для коммуникации. А вот это уже очень нетривиально обеспечить. Я бы даже сказал, что практически невозможно — количество проводов растет по квадратичному закону.
Нет, это неоптимальность алгоритмов. Во первых, можно ввести принцип достаточности. То бишь, главное чтобы на стыках не било в глаза. И разделить изображение на несколько(как это делается например в фотошопе и фотопаинте), обработать отдельно в промежуточные результаты, и смешать результаты. Возможно что разделенная память не нужна. Нужно окно с помощью которого можно указать что данные в этом окне не должны быть доступны другому процессору. Чтобы не надо было их синхронизировать. В общем творчество.

MS>Но это все в общем-то тривиально — есть вещи гораздо более удивительные. Как бы мы ни наращивали число процессоров — тысячи, миллионы, миллиарды — не имеет значения. Это все жалкие копейки для ряда задач (весьма обширного, кстати).
Миллионы процессоров? Это ты хватанул. Сейчас иметь и 4 проца накладно. А вообще, достаточно и 4 процессоров, только если они будут на mainstream компьютерах, и их ресурсы будут загружены. Операционке на рабочей станции, такое загрузить не подсилу. Это нужно делать явно компилятору и программисту.
Я не предлагаю решать проблемы вселенского масштаба. Я предлагаю решать проблемы именно сейчас стоящие. Скажу даже — бизнес приложений, как наиболее часто встречающихся.
С одной стороны, для бизнес-приложений процессор сейчас не загружен. Но его и не хватает в тех особых случая когда нужна математика. Какие задачи в основном стоят — преобразования большого количества данных, сортировки, поиск. В любом из этих случаев существующие распараллеленые алгоритмы разделяй и властвуй будут выполнятся значительно быстрее и эффективней.

MS>Это я не к тому, чтобы рассуждать на темы множественности миров, а лишь к тому, чтобы подумать — а возможно ли что-то принципиально новое в обычном (неквантовом) вычислительном мире? Мне сдается, что все, что мы можем — лишь наращивать мускулы. Никуда не уйти от банальной машины Тьюринга, сколько бы процессоров мы ни приделывали. Грубо говоря, функциональный язык, распараллеливающий вычисления на 1000 процессоров, всего-навсего эквивалентен процедурному языку, работающему на процессоре в 1000 раз более шустром. То есть, игра с исусственным распараллеливением не стоит свеч. Да, для ряда задач это хорошо и правильно, например, для 3D акселераторов. Но не в качестве универсального вычислителя. У меня есть большие сомнения, что это вообще возможно — построить универсальную машину на принципах искусственного распараллеливания. Распаралеливание должно быть естественным, природным — вот как в теории квантовых вычислений. И вот там, возможно (но не гарантировано), удастся не только создать универсальную параллельную машину, но и решать принципиально новые задачи.
Maybe, но меня интересует именно универсальный вычислитель, именно сейчас и именно в контексте mainstream. Сейчас уже несмотря на квазипараллельность, мы уже подходим к тому что у нас будут почти полноценные процессоры(например двухядерные) которые будут стоять на рабочих станциях. Но в то же время, мы имеем то, что для того чтобы работать с этой параллельностью, мы рискуем словить кучу непонятных ошибок. И в текущем случае, мы получим машину(например если брать двухядерный проц), загруженную на 50 процентов. И нет предпосылок на более полную загрузку машины, поскольку и архитектура этому не способствует(проблема shared memory, которая решается остановкой всех процессоров), и компиляторы нам отнюдь не помогают. Но ничего невозможного и нереального я здесь не вижу. Просто я пока точно не могу сказать как.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, McSeem2, Вы писали:

MS>>Так устроены шейдеры в последних поколениях GPU. Это некая подпрограмма, выполняемая для каждого вертекса или пиксела. Они не то что бы очень быстрые, но зато "дуют в 32 струи". Но, со всеми вытекающими — например, сметить подпрограмму шейдера — операция сравнительно дорогая. И там тоже много засад, где можно свести на нет все усилия по распараллеливанию.
GZ>Занятно, но к сожалению слишком специализированно. А так хочется мэйнстрима.

Люди на GPU уже математические расчеты делают,которые к графике ни как ни относятся

Здравствуйте, FR, Вы писали:

FR>А новый ibm'овский процессор cell (http://www.3dnews.ru/cpu/cell/) это не то что ты хочешь?
Ага, именно то. Теперь остался вопрос в том, каким должен быть язык для его эффективного использования.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, FR, Вы писали:

FR>>А новый ibm'овский процессор cell (http://www.3dnews.ru/cpu/cell/) это не то что ты хочешь?
GZ>Ага, именно то. Теперь остался вопрос в том, каким должен быть язык для его эффективного использования.

С языком проблемы, зато распрастранение этот процессор получит большое sony его испоолльзует в своей новой игровой консоли. Microsoft в своем Xbox 360 вместо cell использует практически нечто очень похожее:

Специальный процессор IBM PowerPC: 3 симметричных ядра на частоте 3.2 ГГц; 2 хардварных "потока" на каждое ядро; 3 векторных сопроцессора VMX-128, по одному на каждое ядро; 128 регистров VMX-128 на каждый "хардварный" поток; кэш второго уровня на 1 Мбайт

(http://www.dtf.ru/articles/read.php?id=4011)

А программистам ms в своих рекомендацих на разработку игр под новые конслоли предлагает как можно сильнее распаралеливать программы

Здравствуйте, GlebZ, Вы писали:

GZ>Занятно, но к сожалению слишком специализированно. А так хочется мэйнстрима.

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

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

Дык вся проблема-то в том, что очень часто нельзя разбить на области — эти области пересекаются. Но ты правильно заметил, что это — именно творчество. Компилятор вряд ли это сделает. Ну или нужен очень творческий компилятор!

GZ>Миллионы процессоров? Это ты хватанул.

Это я не просто "хватанул". Я даже посмею утверждать, что для ряда задач это никак не поможет. И это — никакие не задачи "вселенского масштаба" — они очень даже практические.

GZ>С одной стороны, для бизнес-приложений процессор сейчас не загружен. Но его и не хватает в тех особых случая когда нужна математика. Какие задачи в основном стоят — преобразования большого количества данных, сортировки, поиск. В любом из этих случаев существующие распараллеленые алгоритмы разделяй и властвуй будут выполнятся значительно быстрее и эффективней.

Есть такое дело. Проблема, как мне кажется, в том, что это практически нереально — достичь универсального параллелизма. Во всяком случае, до сих пор этого никому не удавалось, хотя все стараются очень и очень сильно (а уж для супекомпьютеров — ух как стараются!). Чтобы уметь автоматически утилизировать параллельные ресурсы, наш гипотетический творческий компилятор должен знать все взаимосвязи между всеми данными! Иными словами, он должен уметь разгадать замысел программиста. На практике это просто нереально (возможно в квантовом мире это реально, но здесь я рассуждаю лишь на уровне дилетанта). Чем хороша машина Тьюринга? — тем, что это априорное знание в ней сведено до минимума! Машина понятия не имеет о взаимосвязях — она знай себе молотит инструкции. Именно поэтому она и является в принципе работоспособной. Как только мы пытаемся что-то распараллелить, сразу появляется другая задача — "объяснить" машине все возможные взаимосвязи (что от чего у нас зависит). А это может быть гораздо сложнее самой задачи. Поэтому, все, что возможно — это строить специализированные параллельные железки — блок пиксельных шейдеров, блок параллельной сортировки, блок матричных вычислений. То есть, такие, в которых данные либо не являются взаимосвязанными, либо эти взаимосвязи можно заранее описать.

Фактически, чем занимается универсальная машина Тьюринга — выполнение программы как раз и устанавливает (вычисляет) эти взаимосвязи. Но ни сама машина, ни программа для нее не знают этих взаимосвязей заранее в общем случае. Установить эти взаимосвязи — и есть цель вычисления. А при универсальном распараллеливании получается, что надо установить (вычислить) все взаимосвязи до выполнения самого вычисления! Я еще раз повторю — это характерно только для универсального случая. В специализированных случаях машина заранее "что-то знает".

В случае универсальной параллельной машины можно работать лишь в направлении гадания — "а попробуем-ка мы забежать вперед и вычислить вот это параллельно вот этому". А потом смотрим, а не случилось ли у нас некой коллизии. Если случилось — ничего не поделаешь, надо откатываться назад и переделывать всю работу. Это, кстати и делается в современных процессорах — все эти branch prediction и прочее. Вот все, что мы можем себе позволить в случае (повторюсь) универсальной машины. Но здесь из за необходимости переделывать уже сделанную работу (в результате коллизий), коэффициент утилизации резко падает с увеличением количества параллельных потоков. Я рискну предположить, что это и есть фундаментальное свойство универсальной параллельной машины.

GZ>Maybe, но меня интересует именно универсальный вычислитель, именно сейчас и именно в контексте mainstream. Сейчас уже несмотря на квазипараллельность, мы уже подходим к тому что у нас будут почти полноценные процессоры(например двухядерные) которые будут стоять на рабочих станциях. Но в то же время, мы имеем то, что для того чтобы работать с этой параллельностью, мы рискуем словить кучу непонятных ошибок. И в текущем случае, мы получим машину(например если брать двухядерный проц), загруженную на 50 процентов. И нет предпосылок на более полную загрузку машины, поскольку и архитектура этому не способствует(проблема shared memory, которая решается остановкой всех процессоров), и компиляторы нам отнюдь не помогают. Но ничего невозможного и нереального я здесь не вижу. Просто я пока точно не могу сказать как.

Это чем-то напоминает принцип неопределенности. Смотри что получается. В идеале, хотелось бы писать последовательный набор инструкций (на том же C++), который бы автоматически распараллеливался с максимально возможной утилизацией. Но это нереально. Можно пойти на уступки и возложить часть задачи по распараллеливанию на программиста (при помощи специального языка). Можно вообще ничего не делать и полностью положиться на человека — как сейчас, для программирования тех же пиксельных шейдеров. Так вот, чем больше у нас появляется автоматизма, тем менее эффективно работает вся система. И 100%-ная автоматизация приближает эффект от распараллеливания к нулю.

Впрочем, я согласен с тем, что некий промежуточный вариант автоматизации принес бы значительную пользу. Но он все равно останется специализированным. Я лишь пытаюсь обосновать свою точку зрения, что универсальный параллельный компьютер в нашем неквантовом мире построить нереально.

Здравствуйте, FR, Вы писали:

FR>Люди на GPU уже математические расчеты делают,которые к графике ни как ни относятся

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

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, FR, Вы писали:

FR>>Люди на GPU уже математические расчеты делают,которые к графике ни как ни относятся

MS>Но что бы там они не расчитывали, для параллельной сортировки это все равно непригодно. Следовательно, не является универсальным.

Ну никто ни обещал панауею
А вообще много что считают: http://www.gpgpu.org/
Если посмотреть на тот же Cell то производители процессоров уже предложили паралельную архитектуру, и не совсем классическую, а так как закон Мура похоже споткнулся, то хочешь не хочешь а придется все распаралеливать.

Здравствуйте, FR, Вы писали:

FR>Графику в современых GPU уже аппаратно распаралелили так что вроде дальше некуда

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

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, FR, Вы писали:

FR>>Графику в современых GPU уже аппаратно распаралелили так что вроде дальше некуда

MS>Распараллелили не графику, а всего-лишь видеоэффекты. Все эти шейдеры почти никак не помогают нарисовать банальную полилинию — произвольной толщины, с заданным line join, с субпиксельной точностью и хорошим качеством сглаживания.

Так на 2D производители видеокарт давно плюнули, и вроде на всех современных карточках линии эмулируются через треугольники.

Здравствуйте, FR, Вы писали:

FR>Так на 2D производители видеокарт давно плюнули, и вроде на всех современных карточках линии эмулируются через треугольники.

В том-то и дело. И бедным игрушечникам приходится много чего рендерить на CPU для UI. Я сейчас сотрудничаю с http://scaleform.com, так вот, быстро и качественно отрендерить сцену из Flash SWF — это очень нетривиальная задача. И вряд ли в ближайшие годы это удастся сделать с более высоким качеством, чем обеспечивает сам Flash. Быстрее — да, несомненно, но качество сглаживания оставляет желать лучшего. И утилизировать мощь GPU для улучшения качества при этом не получается.

McSeem2 wrote:

> Есть такое дело. Проблема, как мне кажется, в том, что это практически
> нереально — достичь *универсального* параллелизма. Во всяком случае,
> до сих пор этого никому не удавалось, хотя все стараются очень и очень
> сильно (а уж для супекомпьютеров — ух как стараются!). Чтобы уметь
> автоматически утилизировать параллельные ресурсы, наш гипотетический
> творческий компилятор должен знать все взаимосвязи между всеми данными!

Это элементарно делается в чистых функциональных языках — у них есть
такое свойство, как ссылочная целостность. Erlang — фактически полностью
универсально параллелен, да еще и вполне практичен при этом (применяется
в телефонных коммутаторах).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:


C>Это элементарно делается в чистых функциональных языках — у них есть
C>такое свойство, как ссылочная целостность. Erlang — фактически полностью
C>универсально параллелен, да еще и вполне практичен при этом (применяется
C>в телефонных коммутаторах).

Интересно. Однако, позволю себе усомниться, что он "полностью универсально параллелен". Это бы фактически означало, что такие задачи как, например:
— перемножение матриц
— линейный поиск в списке
— сортировка
— разложение числа на простые сомножители
формулируются на этом языке одинаково легко и одинаково легко поддаются распараллеливанию. Я специально выбрал такой список задач, который на классическом процедурном языке приблизительно одинаков по сложности кодирования (для разложения чисел мы не берем всякие "хитрые" алгоритмы — берем самый тривиальный). Теперь два вопроса:

1. Какова дисперсия по сложности кодирования всех этих задач на Erlang?
2. Насколько хорошо все эти задачи поддаются распараллеливанию на реальном железе?

Только в случае малой дисперсии и хорошего коэффициента утилизации при работе на тысячах процессоров, можно говорить об универсальности — и вот оно, всеобщее "ЩАСТЕ". Но есть сильные сомнения, что это так.

Здравствуйте, McSeem2, Вы писали:

MS>Но это все в общем-то тривиально — есть вещи гораздо более удивительные. Как бы мы ни наращивали число процессоров — тысячи, миллионы, миллиарды — не имеет значения. Это все жалкие копейки для ряда задач (весьма обширного, кстати). Типичная задача — разложение большого числа на простые сомножители.

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

MS>Данная задача является вообще не решаемой на машине Тьюринга.

Разложения на простые множители? Решаема, только очень задолго.

MS>Здесь я боюсь скатиться в дебри, но раз доказано, что алгоритм Шора работает (не имеет значения, что он пока нереализуем на практике), то откуда "черпается" вся эта вычислительная мощность в квантовом мире?!

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

Здравствуйте, AndrewVK, Вы писали:

MS>>Данная задача является вообще не решаемой на машине Тьюринга.
AVK>Разложения на простые множители? Решаема, только очень задолго.

Я имел в виду, что невозможно достичь полиномиальной сложности алгоритма. Что на практике означает "нерешаемость".

MS>>Здесь я боюсь скатиться в дебри, но раз доказано, что алгоритм Шора работает (не имеет значения, что он пока нереализуем на практике), то откуда "черпается" вся эта вычислительная мощность в квантовом мире?!

AVK>Нет никакой абсолютной вычислительной мощности. Есть вычислительная мощность в конкретном базисе. И квантовый базис для некоторых задач выгоднее. Но точно так же есть задачи, которые не решаются эффективно в квантовом базисе, но неплохо решаются обычными вычислителями.
AVK>Чтобы не загребать в непонятности квантовых вычислений, можно придумать пример попроще. Например взять в качестве базиса операционные усилители. Они очень эффективно решают дифф. уравнения очень высоких порядков за очень малое время. Откуда берется вычислительная мощность? Неужели из паралельных вселенных?

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

Но насколько я понимаю, даже вопрос о принципиальной возможности квантовых вычислений остается открытым. Вроде бы все данные и все эксперименты говорят, что — да, можно. Но полной уверенности нет.
http://www.sciam.ru/2003/3/inform.shtml

Здравствуйте, McSeem2, Вы писали:

MS>Интересный поинт, спасибо за наводку. Да, действительно, аналоговые вычисления позволяют очень быстро дифференцировать — у нас даже было несколько учебных часов на эту тему (и аналоговая вычислительная машина на лампах!). Но вычислительная мощность здесь действительно ниоткуда не берется. Скорость вычисления обеспечивается за счет точности.

Не совсем. В осовном точность обеспечивается качеством ОУ. Т.е. нет теоретических проблем создания ОУ с очень высоким коэффициентом усиления и малой емкостью. В этом случае скорость и точность вычислеиевых чиповний будет расти. Другое дело что практически такие ОУ сделать очень дорого и сложно. Ну так и с квантовыми вычислениями тоже с этой стороны все печально.

MS> Во всяком случае, вычислять расположение планет при помощи операционников смысла не имеет именно в силу недостаточной точности.

Хорошо. Тогда тебе другая элементная база на эту тему. Всем известно что советская лунная программа так и не завершилась успехом. Однако лунный корабль был создан и несколько раз на Н1 летал. Так вот, при его создании была такая проблема: нужно было вычислить траекторию, по которой спускаемый аппарат должен был стартовать с поверхности луны. Задача, за счет того что луна вращается вокруг своей оси и эта ось не совпадает с орбитой станции, была не такая уж и простая. ЦВМ в начале 60-х в СССР не было. Так вот, задачку решили механическим способом, механизмом с кулачками, шестеренками и заводной пружиной.

MS> Но представим себе, что мы все более и более совершенствуем наши схемы и получаем все большую и большую точность без потери производительности. К чему мы приходим в пределе? — к тем же самым квантовым вычислениям!

Конечно же нет. Квантовый вычислитель принципиально вероятностный. Он считает вероятностями. А АВМ считает реальными величинами тока и напряжения. Совершенно иные принципы.

MS>Но насколько я понимаю, даже вопрос о принципиальной возможности квантовых вычислений остается открытым. Вроде бы все данные и все эксперименты говорят, что — да, можно. Но полной уверенности нет.

Была в свое время одна научная работа, в которой было показано, что, даже если удасться создать такой вычислитель, энергетическая эффективность его будет крайне некудышной. Т.е. жрать энергию оно будет на порядки больше современных кремниевых чипов. А ведь кубиты еще и жутко неустойчивы и нагрев им противопоказан куда сильнее, нежели полупроводникам.
Лично я больше верю в оптические технологии. Вот, кстати, тебе еще привер базиса, на некоторых задачах показывающего сверхвысокие результаты. Ряд применений оптоэлектроники еще в середине прошлого века до сих пор недостижим для теперешней электроники.

Здравствуйте, McSeem2, Вы писали:

MS>В идеале, хотелось бы писать последовательный набор инструкций (на том же C++), который бы автоматически распараллеливался с максимально возможной утилизацией.

Зачем? Надо просто переходить на ФЯ. Алгоритмические задачи прекрасно ложатся на такие языки, а задача определения зависимостей между данными намного упрощается.

McSeem2 wrote:

> C>Это элементарно делается в чистых функциональных языках — у них есть
> C>такое свойство, как ссылочная целостность. Erlang — фактически
> полностью
> C>универсально параллелен, да еще и вполне практичен при этом
> (применяется
> C>в телефонных коммутаторах).
> Интересно. Однако, позволю себе усомниться, что он "полностью
> универсально параллелен". Это бы фактически означало, что такие задачи
> как, например:
> — перемножение матриц
> — линейный поиск в списке
> — сортировка
> — разложение числа на простые сомножители
> формулируются на этом языке одинаково легко и одинаково легко
> поддаются распараллеливанию.

За программиста никто распараллеливать ничего не будет, но вот лекость
написания параллельных программ в Эрланге — просто потрясающая. Не нужны
всякие мьютексы, события и т.п.

> 1. Какова дисперсия по сложности кодирования всех этих задач на Erlang?
> 2. Насколько хорошо все эти задачи поддаются распараллеливанию на
> реальном железе?
> Только в случае малой дисперсии и хорошего коэффициента утилизации при
> работе на тысячах процессоров, можно говорить об универсальности — и
> вот оно, всеобщее "ЩАСТЕ". Но есть сильные сомнения, что это так.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, McSeem2, Вы писали:
MS>Интересно. Однако, позволю себе усомниться, что он "полностью универсально параллелен".

Првильные сомнения.
Он паралелен "не универсально". Просто при обычном программировании язык сохраняет всю ту паралельность, которую "имел в виду" программист. И это почти не требует дополнительных трудозатрат.
Но если программист "думал последовательно", то и решение с большой вероятностью окажется тоже последовательным.
То есть это язык естественного описания паралельности.
Паральный алгоритм за тебя erlang не придумает, но всю паралельность, которая твоему алгоритму присуща,
может выжать.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, McSeem2, Вы писали:

MS>>Интересный поинт, спасибо за наводку. Да, действительно, аналоговые вычисления позволяют очень быстро дифференцировать — у нас даже было несколько учебных часов на эту тему (и аналоговая вычислительная машина на лампах!). Но вычислительная мощность здесь действительно ниоткуда не берется. Скорость вычисления обеспечивается за счет точности.

AVK>Не совсем. В осовном точность обеспечивается качеством ОУ. Т.е. нет теоретических проблем создания ОУ с очень высоким коэффициентом усиления и малой емкостью. В этом случае скорость и точность вычислеиевых чиповний будет расти. Другое дело что практически такие ОУ сделать очень дорого и сложно. Ну так и с квантовыми вычислениями тоже с этой стороны все печально.

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

MS>> Во всяком случае, вычислять расположение планет при помощи операционников смысла не имеет именно в силу недостаточной точности.

AVK>Хорошо. Тогда тебе другая элементная база на эту тему. Всем известно что советская лунная программа так и не завершилась успехом. Однако лунный корабль был создан и несколько раз на Н1 летал. Так вот, при его создании была такая проблема: нужно было вычислить траекторию, по которой спускаемый аппарат должен был стартовать с поверхности луны. Задача, за счет того что луна вращается вокруг своей оси и эта ось не совпадает с орбитой станции, была не такая уж и простая. ЦВМ в начале 60-х в СССР не было. Так вот, задачку решили механическим способом, механизмом с кулачками, шестеренками и заводной пружиной.

как не было?
или имеешь в виду таких которые можно засунуть в луный модуль?

Здравствуйте, McSeem2, Вы писали:

MS>Впрочем, я согласен с тем, что некий промежуточный вариант автоматизации принес бы значительную пользу. Но он все равно останется специализированным. Я лишь пытаюсь обосновать свою точку зрения, что универсальный параллельный компьютер в нашем неквантовом мире построить нереально.
Эх, сяду на пенек и помечтаю.
Примерно рискну описать алгоритмы которые возможно были бы использованы. Архитектура проца — Cell.

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

and-параллелизм. Это когда нам важен результат со всех подпрограмм. Например quick sort. Сначало выполняется функция, которая генерит два рекурсивных вызова. Рекурсивные вызовы параллельно запускаются на других процах. И т.д. Ессно попутно придется загружать и выгружать программы из лок. памяти процесса, но параллелизм и выгода от него есть. Конечно, алгоритм который сразу бы детерменировано сначало разбивал массив и сортировал частями был бы более эффективен.

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

for (int i=0;i<1000;i++)
    bla-bla;

Это легко преобразовать в две подпрограммы:

for (int i=0;i<500;i++)
    bla-bla;
for (int i=500;i<1000;i++)
    bla-bla;

Разбитие циклов с связанным результатом.
Тута ступенчетое выполнение. Ну например, нам нужно выполнить шифрования в котором используется результат предыдущего блока.
1. Проц1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
2. Проц1 — Шифрует. Проц2 — загружает подпрограмму и блок памяти для шифрования.
3. Проц1 — выгружает основные результаты в основную память, синхропосылку доступна через шину между процами. Проц2 — берет результат предыдущего и шифрует. Проц3 — загружает подпрограмму и шифруемый блок из основной памяти.
4. Проц1 — загружает шифруемый блок. Проц2- выгружает результаты в основную память. Проц3 — шифрует.
Поскольку все шифрование работает в быстрой памяти, то можно иметь и достаточный выйгрыш.

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

Наибольшая проблема — это определение количества ресурсов для подпрограммы. Например, в случае and-параллелизма в один проц загрузили программу которая выполняется за 1 условную единицу времени. В другую 1000 условных единиц. Для получения результата — мы получаем 1000 условных единиц выполнения. Для этого нужно иметь возможность динамически подключать и отключать процы от подпрограммы.

Что касается языков. Чем хороши функциональные языки в данном случае? Тем что они математически описаны. И их можно трансформировать в эквивалентные формы и доказать, что это формы абсолютно эквивалентны. С нефункциональными языками все сложней. Любая программа является графом. В случае нефункциональных языков этот граф на порядки сложней, и качества связей значительно больше.
Что бы я хотел от компилятора подобного языка. Ну не нравятся мне функц. языки. Грешен. Язык должен быть императивным. Но при этом язык должен вынуждать использовать как можно больше локальных переменны, и как можно меньше переменных доступных для других процессоров. Ну и конечно язык должен иметь достаточное количество библиотек. Сейчас трудно найти язык, в стандартной библиотеке которой нету основных алгоритмов типа quick sort. И управление параллельностью должно быть более автоматизированным и выверенным. Программисты бывают с разным консистентностью серого вещества, а компилятор должен быть умнее всех.

Сложновато получается, но ничего сверхестественного.

С уважением, Gleb.

Здравствуйте, Cyberax, Вы писали:

C>Это элементарно делается в чистых функциональных языках — у них есть
C>такое свойство, как ссылочная целостность. Erlang — фактически полностью
C>универсально параллелен, да еще и вполне практичен при этом (применяется
C>в телефонных коммутаторах).

Первым параллельным языком считается Simula 67(блин, обидно. Все идеи были придуманы в 50-60 годах. С тех пор ничего кардинально нового не появилось).
Похожие на Erlang аспекты, а именно активные объекты, уже обсуждались здесь

Автор: Сергей Губанов
Дата: 21.03.05

. Языков, объекты которых могут работать в параллельном режиме значительно больше. Active Oberon, POOL, Ада, Hybrid, sC++, Distributed Smalltalk.

С уважением, Gleb.

GlebZ wrote:

> Первым параллельным языком считается Simula 67(блин, обидно. Все идеи
> были придуманы в 50-60 годах. С тех пор ничего кардинально нового не
> появилось).

Да, историю я плохо знаю

> Похожие на Erlang аспекты, а именно активные объекты, уже обсуждались
> здесь <http://rsdn.ru/Forum/Message.aspx?mid=1081998&amp;only=1&gt;

Автор: Сергей Губанов
Дата: 21.03.05

.

Гадость... Лучше на Boost.Thread посмотрите — там они как раз хотят
делать механизм каналов.

> Языков, объекты которых могут работать в параллельном режиме
> значительно больше. Active Oberon, POOL, Ада, Hybrid, sC++,
> Distributed Smalltalk.

Даже С++ обычный в своем OpenMPшном воплощении подойдет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Гадость... Лучше на Boost.Thread посмотрите — там они как раз хотят
C>делать механизм каналов.
Таже гадость. Только еще хуже. Все-таки механизмы многопоточности привязаны к OS конкретно. И для использования подобной библиотеки нужно иметь веские основания в виде обязательной кроссплатформенности с непонятно с кем.

>> Языков, объекты которых могут работать в параллельном режиме
>> значительно больше. Active Oberon, POOL, Ада, Hybrid, sC++,
>> Distributed Smalltalk.

C>Даже С++ обычный в своем OpenMPшном воплощении подойдет.
Про OpenMP могу сказать только как об изнасиловании языка. Безусловно классная вещь. Но это инструктаж компилятора, а не средство языка. Приделали пятую ногу, и думают что задача решена.

С уважением, Gleb.

Здравствуйте, FR, Вы писали:

FR>Нет такие ОУ нельзя сделать, мешают шумовые токи,

С ними тоже можно бороться. А главное, я не хотел сказать что АВМ круче квантовых вычислителей. Речь о другом — простота решения той или иной задачи зависит от выбранного базиса.

FR>или имеешь в виду таких которые можно засунуть в луный модуль?

Которые можно засунуть.

Здравствуйте, AndreyFedotov, Вы писали:

AF>Оказалось, что для достижения действительно высоких результатов от разработчика требуется квалификация и трудозатраты идентичные тем, что требуются для обеспечения параллелизма на обычных языках. То есть — весьма существенные. И это является главным препятствием. Где то я видел оценку, по которой написание и отладка многопоточного (распараллеливаемого кода) получалась от 10 до 50 раз дороже, чем написание кода обычного — однопоточного. Хотите проверить — напишите многопоточную сортировку, которая будет работать быстрее однопоточной

Это только для вычислительных задач сложнее. Например, многопоточная сортировка — вычислительная задача. Есть другие задачи — не вычислительные, а так сказать архитектурные. Уверяю Вас архитектурные задачи решать легче при наличии не ограниченного числа активностей. Гораздо легче проектировать систему состоящюу из почти независимых частей живущих самостоятельно — активных объектов; нежели чем проектировать систему, которая одновременно состоит из двух слоев: обычных объектов и потоков оперирующих с ними. Логика работы каждой активности получается очень простой.

Вот пример. Программа должна обслуживать телефонные звонки. Каждый звонок происходит независимо от другого. Было бы очень просто с точки зрения архитектуры на каждый звонок заводить отдельную самостоятельную активность. К сожалению, слишком много потоков в Windows/Linux создавать нельзя. Поэтому приходится использовать малое число потоков, каждый из которых обрабатывает несколько телефонных звонков в цикле по очереди малыми квантами. Архитектура программы чудовищно усложняется по сравнению с той какая могла бы быть будь у нас возможность использовать неограниченную прорву активностей. Речь не об эффективности работы программы. Будет ли она работать быстрее или нет — другой вопрос. Речь о простоте архитектуры. Архитектура программы становится более простой, чистой и понятной если при проектировании применять идеологию возможности использования неограниченного количества активностей.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вот пример. Программа должна обслуживать телефонные звонки. Каждый звонок происходит независимо от другого. Было бы очень просто с точки зрения архитектуры на каждый звонок заводить отдельную самостоятельную активность. К сожалению, слишком много потоков в Windows/Linux создавать нельзя. Поэтому приходится использовать малое число потоков, каждый из которых обрабатывает несколько телефонных звонков в цикле по очереди малыми квантами. Архитектура программы чудовищно усложняется по сравнению с той какая могла бы быть будь у нас возможность использовать неограниченную прорву активностей. Речь не об эффективности работы программы. Будет ли она работать быстрее или нет — другой вопрос. Речь о простоте архитектуры. Архитектура программы становится более простой, чистой и понятной если при проектировании применять идеологию возможности использования неограниченного количества активностей.
Эта "хотелка" из той же серии: почему бы нам не реализовать String через StringBuffer|StringBuilder, скрыв это от программиста.
Вот и Вы предлагаете реализовать тысячи-тысячи тредов через системный пул потоков (нитей, активных "активностей") достаточно разумного объёма (ведь всё равно активности не все будут активны, а какие будут — хватит и пула), чтобы не придумывать пулы на прикладном уровне.
С этой точки зрения для программиста было бы всё просто.

Здравствуйте, iZEN, Вы писали:

ZEN> Вот и Вы предлагаете реализовать тысячи-тысячи тредов через системный пул потоков

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Оказалось, что для достижения действительно высоких результатов от разработчика требуется квалификация и трудозатраты идентичные тем, что требуются для обеспечения параллелизма на обычных языках. То есть — весьма существенные. И это является главным препятствием. Где то я видел оценку, по которой написание и отладка многопоточного (распараллеливаемого кода) получалась от 10 до 50 раз дороже, чем написание кода обычного — однопоточного. Хотите проверить — напишите многопоточную сортировку, которая будет работать быстрее однопоточной

СГ>Это только для вычислительных задач сложнее. Например, многопоточная сортировка — вычислительная задача. Есть другие задачи — не вычислительные, а так сказать архитектурные. Уверяю Вас архитектурные задачи решать легче при наличии не ограниченного числа активностей. Гораздо легче проектировать систему состоящюу из почти независимых частей живущих самостоятельно — активных объектов; нежели чем проектировать систему, которая одновременно состоит из двух слоев: обычных объектов и потоков оперирующих с ними. Логика работы каждой активности получается очень простой.

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

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

Здравствуйте, GlebZ, Вы писали:

GZ> Какие задачи в основном стоят — преобразования большого количества данных, сортировки, поиск.

На таких задачах уже сейчас производительность ядра часто избыточна. Узкое место — пропускная способность шины памяти —

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

и добавление новых процессоров ничего не даст. кроме увеличения нагрузки на шину CPU<->RAM.

Здравствуйте, GlebZ, Вы писали:

GZ>Ну например, нам нужно выполнить шифрования в котором используется результат предыдущего блока.
GZ>1. Проц1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
GZ>2. Проц1 — Шифрует. Проц2 — загружает подпрограмму и блок памяти для шифрования.
GZ>3. Проц1 — выгружает основные результаты в основную память, синхропосылку доступна через шину между процами. Проц2 — берет результат предыдущего и шифрует. Проц3 — загружает подпрограмму и шифруемый блок из основной памяти.
GZ>4. Проц1 — загружает шифруемый блок. Проц2- выгружает результаты в основную память. Проц3 — шифрует.
GZ>Поскольку все шифрование работает в быстрой памяти, то можно иметь и достаточный выйгрыш.

А вот реальная картина для одного CPU:
1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
2. Проц Шифрует. Механизм prefetching'а загружает следующий блок памяти для шифрования в кэш.
3. Проц выгружает основные результаты в быструю память (остаются там для последующего использования). Данные в основную память будут выгружены из кэша контроллером "прозрачно".
Шифрование и так работает в быстрой памяти. Нет никаких сообщений между CPU.
Хорошо, если контроллер памяти успевает предоставить данные для CPU.

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

Здравствуйте, gear nuke, Вы писали:

GN>На таких задачах уже сейчас производительность ядра часто избыточна. Узкое место — пропускная способность шины памяти -
Об этом и речь.

GN>и добавление новых процессоров ничего не даст. кроме увеличения нагрузки на шину CPU<->RAM.
Об этом и речь. Технология с одной шиной памяти, и с кэшем — уже не срабатывает.

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>А вот реальная картина для одного CPU:
GN>1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
GN>2. Проц Шифрует. Механизм prefetching'а загружает следующий блок памяти для шифрования в кэш.
GN>3. Проц выгружает основные результаты в быструю память (остаются там для последующего использования). Данные в основную память будут выгружены из кэша контроллером "прозрачно".
GN>Шифрование и так работает в быстрой памяти. Нет никаких сообщений между CPU.
GN>Хорошо, если контроллер памяти успевает предоставить данные для CPU.
Я подразувал именно архитектуру Cell.

GN>Архитектура современных компьютеров не является фон-неймановской в чистом виде.
Да, не является.
GN> Ядро CPU ничего не знает про память, реальная работа происходит (практически всегда) только с кэшем. Передачу данных cache<->RAM выполняет отдельный "процессор". Ни один существующий компилятор не позволяет эффективно использовать эту (уже готовую) архитектуру.
Об этом и речь. Нету таких компиляторов(или мы о них не знаем). К сожалению. OpenMP — пятое колесо к старой телеге.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Технология с одной шиной памяти, и с кэшем — уже не срабатывает.

Дык можно было бы — давно бы сделали шину 2048 бит. Тут проблема в том, что количество проводников чрезмерно усложняет дизайн материнской платы. Решение перенести память в ядро возможно, но ещё более дорого.

Здравствуйте, GlebZ,

GN>>А вот реальная картина для одного CPU:
GN>>1. Загружается подпрограмма и блок памяти для шифрования в быструю память.
GN>>2. Проц Шифрует. Механизм prefetching'а загружает следующий блок памяти для шифрования в кэш.
GN>>3. Проц выгружает основные результаты в быструю память (остаются там для последующего использования). Данные в основную память будут выгружены из кэша контроллером "прозрачно".
GN>>Шифрование и так работает в быстрой памяти. Нет никаких сообщений между CPU.
GN>>Хорошо, если контроллер памяти успевает предоставить данные для CPU.

GZ>Я подразувал именно архитектуру Cell.

ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу, чем какие-то навороты (которые наверняка имеют какие-то подводные камни) . На бумаге всегда всё хорошо выглядит, а когда дело доходит до практики — это не так. История того же x86 имеет массу примеров подобного — вспомните PIV с его супер-ядром, проигрывающем ядру предудущему.

Здравствуйте, gear nuke, Вы писали:

GN>Дык можно было бы — давно бы сделали шину 2048 бит. Тут проблема в том, что количество проводников чрезмерно усложняет дизайн материнской платы. Решение перенести память в ядро возможно, но ещё более дорого.
А никому не нужна двухкилобайтная шина. Просто двухкилобайтных данных нет. Даже если забыть о x86 и вспомнить о SIMD(которые теперь уже и в x86 есть но мало пользуются), то не наберешь столько данных. Увеличивают пропускную способность только за счет тактовой частоты, и некоторыми хаками(типа DDR).

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу,
В том то и дело что нет. Во первых, проц не знает что такое шифрование, он знает только что такое инструкции и последняя использованная память. Неугаданный переход в PIV много стоит. Во вторых, он может через некоторый момент заняться обработкой прерывания(в результате заполнение кэша начнется сначало) В третьих, при многопроцессорности, у каждого своя память. И разделив расчеты, мы получаем то, что приходится бегать с промежуточными данными через более медленную память.

GN>чем какие-то навороты (которые наверняка имеют какие-то подводные камни) . На бумаге всегда всё хорошо выглядит, а когда дело доходит до практики — это не так. История того же x86 имеет массу примеров подобного — вспомните PIV с его супер-ядром, проигрывающем ядру предудущему.
Или вспомнить Cray — который изначально был параллельным, и в стародавние времена делал то куда x86 никогда не добраться.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>А никому не нужна двухкилобайтная шина. Просто двухкилобайтных данных нет.

Не важно, есть ли такие данные или нет. Передавать данные параллельно быстрее. x86 сейчас читает данные блоками по 16\32 байта. Как видите, это мало похоже на 32 бита.

GZ>Даже если забыть о x86 и вспомнить о SIMD(которые теперь уже и в x86 есть но мало пользуются), то не наберешь столько данных. Увеличивают пропускную способность только за счет тактовой частоты, и некоторыми хаками(типа DDR).

Пропускная способность = ширина канала * частота передачи.

Здравствуйте, GlebZ, Вы писали:

GN>>ИМХО мой пример показывает, что современная архитектура лучше подходит под задачу,
GZ>В том то и дело что нет. Во первых, проц не знает что такое шифрование, он знает только что такое инструкции и последняя использованная память.

А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?

GZ>Неугаданный переход в PIV много стоит. Во вторых, он может через некоторый момент заняться обработкой прерывания(в результате заполнение кэша начнется сначало)

А когда будет много ядер, прерывания исчезнут?

GZ>В третьих, при многопроцессорности, у каждого своя память. И разделив расчеты, мы получаем то, что приходится бегать с промежуточными данными через более медленную память.

В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.

GZ>Или вспомнить Cray — который изначально был параллельным, и в стародавние времена делал то куда x86 никогда не добраться.

x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры. "Смерть" Itanium яркий тому пример.

Здравствуйте, gear nuke, Вы писали:

GN>Не важно, есть ли такие данные или нет. Передавать данные параллельно быстрее. x86 сейчас читает данные блоками по 16\32 байта. Как видите, это мало похоже на 32 бита.
Я собственно застал то время, когда был переход с 16 разрядной на 32 разрядные шины. Огромный прирост производительности был только у маркетологов. Сейчас в связи с переходом на 64 разрядную шину — все повторяется. Неважно сколько разрядов в шине, важно сколько проц сможет обработать за тик. Он же заказывает данные по последовательному алгоритму.

GN>Пропускная способность = ширина канала * частота передачи.
Добавь * на количество шин.

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
Нет. Программа будет знать о процах.

GN>А когда будет много ядер, прерывания исчезнут?
Нет. Но можно будет распределить нагрузку.

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

GN> x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры. "Смерть" Itanium яркий тому пример.
Много чего живо. Но это не повод сохранять костность мышления. Всегда найдется более интересное чем mainstream. По крайней мере даже в x86 по сравнению с первоначальным вариантом много нового(начиная от тех же SIMD инструкций). Приходится перенимать.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Я собственно застал то время, когда был переход с 16 разрядной на 32 разрядные шины. Огромный прирост производительности был только у маркетологов.

Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .

GZ>Сейчас в связи с переходом на 64 разрядную шину — все повторяется. Неважно сколько разрядов в шине, важно сколько проц сможет обработать за тик.

Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.

for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.

GN>>Пропускная способность = ширина канала * частота передачи.
GZ>Добавь * на количество шин.

Ширина канала = количество шин * ширина шины

Здравствуйте, GlebZ, Вы писали:

GN>>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
GZ>Нет. Программа будет знать о процах.

А чейчас она не знает?

GN>>А когда будет много ядер, прерывания исчезнут?
GZ>Нет. Но можно будет распределить нагрузку.

Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)

GN>>В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.
GZ>Через пару лет один проц(или одно ядро) уйдут в небытье.

Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.

GZ>Много чего живо. Но это не повод сохранять костность мышления. Всегда найдется более интересное чем mainstream.

Я в детстве научился на своём опыте. Больше не хочу. Выкидывать кучу наработок только потому, что дяди на биржах ничего не понимают в железе, зато понимают в бизнесе. Разбитое корыто тоже интереснее чем mainstream, ни у кого такого нет .

GZ>По крайней мере даже в x86 по сравнению с первоначальным вариантом много нового(начиная от тех же SIMD инструкций). Приходится перенимать.

Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".

Здравствуйте, gear nuke, Вы писали:

GN>Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .
Именно, что не было прироста эффективной пропускной способности. Ну и нафиг мне двухкилобайтная шина, если она не работает.

GN>Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.
GN>

GN>for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
GN>for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.
GN>

Достаточно редкая конструкция. 32-разрядности вполне хватает для подавляющего числа операций.
Прирост в основном будет на memset, memcpy операциях.

С уважением, Gleb.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, GlebZ, Вы писали:

GN>>>А новйй проц будет знать про шифрование? И про все алго, которые придумают в будующем?
GZ>>Нет. Программа будет знать о процах.

GN>А чейчас она не знает?
Нет. Об этом знает только операционка. Вводятся правда OpenMP команды в различные компиляторы С++. Но они меня не впечатляют.

GN>>>А когда будет много ядер, прерывания исчезнут?
GZ>>Нет. Но можно будет распределить нагрузку.

GN>Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)
Опять. Я не говорю о кэше. Я говорю об абсолютно управляемой памяти.

GN>>>В случе одного CPU данные находятся всё время в кэше. Они будут выгружены, когда контроллер будет вынужден считать в линейку новые данные.
GZ>>Через пару лет один проц(или одно ядро) уйдут в небытье.

GN>Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.
С OpenMP — будет влиять.

GN>Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".
Обычных регистров, уже практически избыток. Вся сложность процов x86 именно в этих обычных регистрах.(правильно говорить о регистровой памяти).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GN>>Прирост и на самом деле был. Не производительности, а пропускной способности памяти. Ровно в 2 раза. А производительность CPU в общем случае не зависит от разрядности регистров — для некоторых задач оптимальна однобитная архитектура .
GZ>Именно, что не было прироста эффективной пропускной способности.

Вы путаете пропускную способность памяти с производительностью CPU. Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.

GN>>Уж проц-то без проблем выбирает возможности шины. По поводу разрядности ALU я писал выше.
GN>>

GN>>for ( unsigned long i = 0; i ; i++ ); // не ускоряется при переходе на 64 бита. может даже замедлиться.
GN>>for ( unsigned long long i = 0; i ; i++ ); // ускоряется при переходе на 64 бита - арифметика проще.
GN>>

GZ>Достаточно редкая конструкция. 32-разрядности вполне хватает для подавляющего числа операций.

Это утрированная иллюстрация 64х битной арифметики.

GZ>Прирост в основном будет на memset, memcpy операциях.

Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.

Здравствуйте, GlebZ, Вы писали:

GZ>>>Нет. Программа будет знать о процах.

GN>>А чейчас она не знает?
GZ>Нет. Об этом знает только операционка.

Смотря какая программа.

GN>>Это ничего не даст. Потери времани и загрязнания кэша не уменьшатся (могут увеличиться как раз из-за распределения и необходимости синхронизации)
GZ>Опять. Я не говорю о кэше. Я говорю об абсолютно управляемой памяти.

Вот именно, что опять! Это одно и тоже. Вы меняете название, но суть не изменить. Да, у кэша не так много команд явного управления, как хотелось бы. И на то есть резон — добавим кучу команд управления кэшем, и CPU только и будет их выполнять, вместо полезной работы .

GN>>Ну будет 2 ядра, а будет ли это как-то заметно влиять на скорость? Сейчас мало влияет.
GZ>С OpenMP — будет влиять.

OpenMP совершенно ни при чём. HT не позволяет выполнять однотипные операции на 2х ядрах одновременно.

GN>>Вот это типичная маркетингавая утка. Добавили бы обычных регистров, лучше бы было. Но нет, это бы не было "революция".
GZ>Обычных регистров, уже практически избыток.

Неужели??? Всего каких-то 8, причём 8й ни один компилятор не даёт по полной использовать.

GZ>Вся сложность процов x86 именно в этих обычных регистрах.(правильно говорить о регистровой памяти).

Теневые регистры не доступны программно. С точки зрания исполняемого кода их нет.

Здравствуйте, gear nuke, Вы писали:


GN>Вы путаете пропускную способность памяти с производительностью CPU.
Нет не путаю. Для общей производительности компьютера важна именно эффективная пропускная способность.
GN>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
Ссылку в студию...

GZ>>Прирост в основном будет на memset, memcpy операциях.
GN>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
А ты попробуй. Только чтобы компилер понимал под кого memcpy.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GN>>Вы путаете пропускную способность памяти с производительностью CPU.
GZ>Нет не путаю.

Я приводил пример с 32х и 64х битной арифметикой. На 32х битной арифметике 64х битные регистры не дают выигрыша, на 64х битной дают. Каким образом это зависит от ширины шины памяти, когда все данные в кэше?

GZ>Для общей производительности компьютера важна именно эффективная пропускная способность.

"Общая производительность" — это слишком общая вещь. Есть производительность на конкретных задачах, и она уже может зависеть, может не зависеть.

GN>>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
GZ>Ссылку в студию...

Даже теряюсь на что ссылку-то приводить. В то время интернет был широкораспространён? Для меня формула "Пропускная способность = ширина канала * частота передачи" преподавалась как аксиома по предмету "проектирование цифровых цепей" (как-то так, уже не помню).

GZ>>>Прирост в основном будет на memset, memcpy операциях.
GN>>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
GZ>А ты попробуй. Только чтобы компилер понимал под кого memcpy.

Я говорю не про то, что где-то прочитал, и даже не просто попробовал, а потратил достаточное количество времени на изучение вопроса. Безо всяких компиляторов и memcpy. ~85% от теоретической пропускной способности памяти — потолок, они почти никак не зависит от использования mmx\xmm регистров. При использовании GPR производительность теряется только из-за их малого количества.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, gear nuke, Вы писали:


GN>>Вы путаете пропускную способность памяти с производительностью CPU.
GZ>Нет не путаю. Для общей производительности компьютера важна именно эффективная пропускная способность.
GN>>Pentuim при той же частоте шины имел в 2 раза более быстрые операции с памятью, чем 486.
GZ>Ссылку в студию...

GZ>>>Прирост в основном будет на memset, memcpy операциях.
GN>>Нет будет. Сейчас нет разницы, как копировать — по 4, 8 или 16 байт. Всё упирается в память.
GZ>А ты попробуй. Только чтобы компилер понимал под кого memcpy.

Penitum имеет 64 битную шину (хоть и пользуется 32 битными операциями), а 486 — только 32 битную. И, хотя система команд Pentium не может использовать полную разрядность шины — ей в полном объёме пользуется контроллер кэша. Так данные из кэша подгружаются и выгружаются в 2 раза быстрее, чем в 486 (при той же тактовой частоте). Потому memcpy будет работать быстрее безовсякой оптимизации.

Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).

Однако есть несколько моментов, которые мешают увеличить разрядность шины. И разводка печатной платы и количество контактов (ведь каждый контакт — потенциальный источник проблем) и наводка сигналов друг на друга. Тенденция сейчас ровно противоположная — уменьшение сигнальных проводов, с повышением тактовой частоты — последовательная передача данных. Некоторые спецы прогнозируют дальнейшее развитие (через 7-10 лет) следующим образом: шины между CPU, памятью и периферией становятся оптическими, пропускная способность таких шин и будет соответствовать 2-16 килобит. При этом по шине контроллер кэша будет обмениваться пакетами с памятью и другими CPU. Процесс формирования пакета будет достаточно медленным (как и сейчас — процесс чтения столбца/строки в чипе динамической памяти) — порядка 10 нс (100 МГц), зато скорость передачи этих пакетов будет в 100-1000 раз больше, чем сейчас. Соответственно будет более востребован большой кэш (16-32MB) и компиляторы/JIT фреймворки, учитывающие эти особенности архитектуры. Кстати, этот путь развития вполне хорошо соотносится с концепцией развития множества ядер на кристалле и одновременным доступом множества CPU к общей памяти (особенно через многопортовый мост, с собственной кэш памятью, используемой для синхронизации доступа).

С Уважением, Андрей

Здравствуйте, AndreyFedotov, Вы писали:

AF> Penitum имеет 64 битную шину (хоть и пользуется 32 битными операциями), а 486 — только 32 битную. И, хотя система команд Pentium не может использовать полную разрядность шины — ей в полном объёме пользуется контроллер кэша. Так данные из кэша подгружаются и выгружаются в 2 раза быстрее, чем в 486 (при той же тактовой частоте). Потому memcpy будет работать быстрее безовсякой оптимизации.
Действительно. Прогуглился, был неправ. Тот пентюх о котором я говорил, был с аббревитурой s. И вышел толи одновременно, то ли позже. И мог ставиться на ту же плату что и 486. Это меня и ступило. Пристрелите меня табуреткой.

AF> Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).
А вот здесь не понял. Если я правильно понял, это есть упреждающее чтение. И оно эффективно на 96-99%?

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

AF>> Потому gear nuke абсолютно прав, когда показывает, что более широкая шина ускорит работу CPU. При 2-х килобитной шине, к примеру, переключение потоков будет происходить за один цикл шины. При такой разрядности шины большинство алгоритмов будут работать так, как будто скорость работы памяти равна скорости работы кэша (или составляет 96-99% последней).
GZ>А вот здесь не понял. Если я правильно понял, это есть упреждающее чтение. И оно эффективно на 96-99%?

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

Здравствуйте, gear nuke, Вы писали:

GN> x86 — это самый ужасный из процессоров всех времён и народов. Тем не менее, он жив до сих пор. Слишком дорого обойдётся переход на новые архитектуры.

Было бы желание — за это время можно было бы потихоньку вылечить большинство болячек. К примеру WinXP x64 не умеет ни DOS ни Win16 приложения запускать. Это означает, что после массового перехода на x64 можно смело выкидывать из процессоров реальный, 286 и V86 режимы. То же самое и с системой команд. На сегодняшний момент добавить несколько новых декодеров для нового instruction set не так уж и сложно, а значит в x64 режиме можно было выкинуть всякие несуразности вроде leave и упростить схему описания команды и ее аргументов.
Другое дело что производителям х86 процессоров выгодно наличие очень высокого порога вхождения на этот рынок.

Здравствуйте, FR, Вы писали:

FR>А новый ibm'овский процессор cell (http://www.3dnews.ru/cpu/cell/) это не то что ты хочешь?

Кстати о Cell. Наткнулся на новость: http://www.linux.org.ru/view-message.jsp?msgid=1158295

Компании Mercury и Terra Soft объявили о том, что они будут поставлять серверы на базе процессоров IBM/Sony/Cell, работающие под управлением ОС Линукс. Для стойки размером 7U обещается производительность до 2.8 TeraFLOPS (!). Начало поставок Dual Cell-Based Blade'ов ожидается в начале 2006 года.