А вот Кнут против всяких этих новомодных параллельных технологий.

А выбора как бы нет. Против дальнейшего увеличения гигарцев выступают скорость света и размер атома. Так что для увеличения производительности придётся освоить параллельные технологии. Рано или поздно.

Думаешь, что ты умнее Кнута?

Думаю, что а) Кнут говорил что-то другое б) Выбора нет

P.S. И да, многое Кнут предусмотреть наперёд не смог.

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

За последние 50 лет я написал более тысячи программ, многие из которых были значительного размера. Не думаю, что хотя бы пять программ из числа написанных мной существенно выиграли бы за счет параллелизма или многопотоковости. Например, вне всякого сомнения, дополнительные процессоры бесполезны для TeX.

а) Есть задачи которые хорошо параллелятся

б) То, что дополнительные процессоры бесполезны для TeX — это печалька, а не достоинство, хотя безусловно это сложно.

в) Стандарты похоже начинают устаканиваться. Это началось относительно недавно aka последнее десятилетие.

г) Просмотрите цикл статей — возможно это даст ответы на интересующие вас вопросы.

д) И да, Кнут не говорил, что параллелизм не нужен — он говорил что он его не осилил (хотя пять программ — это на самом деле круто).

«не осилил» следует заменить на «у него не было подходящей задачи».

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

Как бы векторные были именно такими, в смысле одноядерными, но таки да — сейчас их уже почти и нет (в TOP500 точно). В перспективе «одноядерными» можно будет назвать квантовые.

Годно! Исходники могут пригодиться.

Стандарты похоже начинают устаканиваться. Это началось относительно недавно aka последнее десятилетие.

Ага, сколько про OpenCL вопили, что это, мол, унификация CPU и GPU, а в итоге нет ни одной нормальной CPU-only реализации.

Реализации чего? Железа? OpenCL даже к FPGA прикрутили.

Или имеется в виду стандарт, который GPU не поддерживает? Ну дык используй MPI.

На правах оффтопика

Как в TeX набрать Ѣ (ять)?

Тебе нужны подходящие шрифты. Смотри в сторону Old standard. Проще для этого освоить xelatex.

Разве все это нужно когда есть эрланг?

Эрланг может волшебным образом разрулить все ограничения GPU? Проблема как раз и состоит в том, что оптимизирующие компиляторы дают прирост в среднем 20%, а если хочется получить два-три порядка по производительности, то добро пожаловать в мир «настоящих мужчин, для которых что запилить драйвер к железяке, что сочинить параллельный алгоритм  — раз плюнуть».

Эрланг может волшебным образом разрулить все ограничения GPU?

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

Почитал статью о кластерах - понравилось, спасибо.

Параллелизм на данных? Вы имеет в виду то, что может любая система управления очередями? _Это_ простая задача. Попробуйте решить сложную.

Попробуйте решить сложную.

И в чем же состоит сложная задача?

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

Обработка данных - Все совсеменные научные институты имеют небольшой суперкомпьютер =) А там как раз все раз параллелено.

Начните с простого: клеточный автомат (пусть будет 1024 на 1024 клеток и можно взять за правила игры Жизнь) на 2 ядрах. Ускорьте его в два раза. Потом сделайте тоже самое на 1024 ядрах. Ускорьте его в 1000 раз.

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

P.S. Лично я специализируюсь в области, где всё как раз параллелится на уровне данных (введение и последняя статья). Но это не повод не глядеть по сторонам.

Потом сделайте тоже самое на 1024 ядрах.

А почему бы не сделать на десятке 100-ядерных?

Ну если ты не доверяешь Teslам, то можешь напихать обычных видюх.

Я не доверяю одному компьютеру.

А выбора как бы нет. Против дальнейшего увеличения гигарцев выступают скорость света и размер атома. Так что для увеличения производительности придётся освоить параллельные технологии. Рано или поздно.

Так есть же экспериментальные транзисторы на 700 ГГц. А ещё скорая реальная реализация «оптических» процессоров (не квантовых) более вероятна, чем квантовых. Или речь идёт именно о повышении гигагерцев свыше той самой скорости света и неминуемость использования распараллеливания?

Параллель - не параллель, а, в конце концов, получится, как с PATA(SCSI) -> SATA (SAS). Хотя, если взять PCIe, то она как бы официально последовательная, но можно брать несколько параллельных линков. Хм.

Спасибо за статьи, посмотрю; а исходники - всегда приветствуются. Их так не хватает крутым иностранным «papers», которые из-за их отсутствия смотрятся, как воздушные замки, мешая науке развиваться инкрементально по спирали вверх, а не по кругу.

Дохловато. Примеры из мануала.

Ты врешь. Не мог Кнут такого говорить!

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

Спасибо бро!

P.S. Если будет интерес, то начну процедуру выкладывания >исходников статей под открытой лицензией.

Да, да, да!

Хотя чёт я сильно обрадовался, содержание не оч торкнуло.

Более идиотского примера, чем верстка не нашлось? Ничего что есть задачи, которые без параллелизма за разумное время вообще не решить?

Eвгений, судя по тексту статьи: - Роман из Adapteva; - ParalleLLa — некий проект и в нём два двойных L.

P.S. Любопытно, как много читателей LinuxFormat представляют себе размеры американского цента, использованного для задания масштаба на фотографии с процессором...

Меня вот этот курс весьма торкнул.

https://computing.llnl.gov/tutorials/parallel_comp/

Есть мнение, что скорость не нужна, за исключением единичных особых случаев.

По сабжу: спасибо, когда-то интересовался.

Действительно опечатался. Имел в виду, что участвует в создании Parallella

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

Привет,я хотел бы высказать своё мнение по поводу параллельных вычислений.На самом деле это очень важно, и даже очень.Если вы прикладной математик и информатик,я думаю вы поймете о чем я.Решать СЛАУ 10^6 x 10^6 на one pc даже самым быстрым оптимальным алгоритмом займет около века,если не больше(все зависит от метода,да и где вы память возмете?).Алгоритм Фокса,Кеэнона,сортировки и т.п - не зря придумано.Есть реально большие задачи.Трехмерные нелинейные задачи темболее,какой там уж один компьютер. Мой друг по комнате пишет fraemwork mpi,чтобы потом еще менее заморачиваться с интерфейсом mpi,т.к нужна скорость разработки-времени нет.Поэтому ребят,вы не думайте,что это не нужно:-) Кнут молодец конечно,но увы Evgueni прав))

а) не везде

б) это ликбез, а для переднего края лучше сходить на arxiv.org

Всё верно вы пишите. Просто не забывайте ещё, что параллелизация бывает разная. От параллельного запуска одного алгоритма (распараллеливание на потоки), до параллельного запуска процессов, которые могут быть совершенно разными, и работать на ядрах с разной скоростью, но т.или иначе, это приводит к уменьшение времени на получение конечного результата. Также тут в топике пишут про стандарты параллелизации 1-го типа на видеокартах, но забывают о памяти, выделенной GPU, которая не позволит(-яет) паралелльно запустить 900 потоков с выделенной памятью в 20-30 мб на ядро, т.е. запустить 900 копий виртуальных машин Java или Python на CUDA или других параллельных GPU стеках в 2013 году невозможно.

запустить 900 копий виртуальных машин Java или Python на CUDA или других параллельных GPU стеках в 2013 году невозможно.

Ну дык не с проста CUDA и OpenCL - си-подобные языки
И вообще что касается GPU - там принцип совсем другой чем для CPU, там в один момент только одно ядро (программа-kernel) работает над массивом данных.

Безусловно. Более того конкретно в моей области деятельности GPU де факто не применимо.

Сейчас это уже совершенно не обязательно (см. например возможности архитектуры Kepler от Nvidia). GPU дрейфуют в сторону процессоров общего назначения и наоборот.

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

Я тоже уже не уверен что имел в виду :) Возможно я хотел сказать, что kernel может инициализировать запуск другого kernel. Но это действительно совсем не в ту стпь. В GPU есть быстрая память, к которой могут доступаться все процессы.

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

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

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

Расскажите ему кто-нибудь про opengl и про Unified Shader Model

GPGPU это всё же принципиально другой подход

Это не от хорошей жизни и они всеми силами (по крайней мере для расчётных GPU) пытаются от этого подхода эволюционно перейти к кластеру.

Ну не знаю, народу нравится вроде. Да и что в этом мире от хорошей жизни?