Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 74
круто! Будем ждать новых сверхмощных компиляторов. :)
erlang то им чем ну угодил?
Ну он же уже есть. Под это дело 6 миллионов освоить сложно...
Количество плюсов превышает количество ранее зарегистрированных фанатов Эрланга, недавняя статья сделала своё дело :-)
А вообще это сильно однобокий взгляд, message passing concurrency дело не ограничивается, даже отбросив тот факт, что сделать пригодный для числодробилок оптимизирующий компилятор насквозь динамического Эрланга практически невозможно, да и не предназначен он для этого.
А вообще это сильно однобокий взгляд, message passing concurrency дело не ограничивается, даже отбросив тот факт, что сделать пригодный для числодробилок оптимизирующий компилятор насквозь динамического Эрланга практически невозможно, да и не предназначен он для этого.
Наконец-то я увидел человека, который понимает, что Erlang не предназначен для больших вычислений.
Erlang лишь помогает написать параллельную программу, но нисколько не снимает с программиста задачу рассудительного анализа и определения, что в программе нуждается в распараллеливании, а что - нет, и как эти части и потоки будут между собой взаимодействовать.
Erlang лишь помогает написать параллельную программу, но нисколько не снимает с программиста задачу рассудительного анализа и определения, что в программе нуждается в распараллеливании, а что - нет, и как эти части и потоки будут между собой взаимодействовать.
Но не под десятки процессоров.
Я хотел сказать десятки ядер, которые обещают в будущем.
Надо же как-то оправдать причину смены процессора с 2 ядрами на 22 перед пользователем. А то он того и гляди передумает деньги тратить.
Надо же как-то оправдать причину смены процессора с 2 ядрами на 22 перед пользователем. А то он того и гляди передумает деньги тратить.
Но не под десятки процессоров.
Совершенно наоборот, при современных размерах изображений распараллелить некоторые операции с ними вполне стоит и на десятки потоков.
Совершенно согласен. Нужно, но пока насколько я знаю, так распараллелен только очень специальный софт под очень специальное железо. Пользовательское ПО (игры) хорошо если использует 4 ядра.
Насколько я знаю, игры вообще не используют паралеллизм в настоящее время. То есть некоторые пытаются использовать, но выигрыш от этого смешной по сравнению с одним ядром. Просто потому что игровые расчеты сложно эффективно распараллелить, в итоге получаются что потоки всё равно ждут друг друга.
Строго говоря, параллелизм в играх давно есть. Например, выводя данные в конвейер OpenGL, вы отдаете их на откуп графическому процессору, а дальше он может спокойно работать параллельно с основным.
Более яркий пример — множество процессоров приставки PS3. Их, конечно, можно не использовать, но обычно все-таки используют :)
Более яркий пример — множество процессоров приставки PS3. Их, конечно, можно не использовать, но обычно все-таки используют :)
Где это серверное ПО под многоядерность делается? Покажите мне веб / database сервер, который умеет потоки в процессе на несколько ядер расшвыривать.
Основная нагрузка как раз таки ляжет на клиента. С каждым годом веб-клиенты (ака сайты) все толще и толще: ajax, mootools, ext.js, Flash, Adobe Air. А на серверах особо ничего не поменялось с момента запуска Рамблера.
Основная нагрузка как раз таки ляжет на клиента. С каждым годом веб-клиенты (ака сайты) все толще и толще: ajax, mootools, ext.js, Flash, Adobe Air. А на серверах особо ничего не поменялось с момента запуска Рамблера.
Вот интересно, сейчас паралельность в пределах программы достигаеться, фактически, только использованием потоков. А нельзя было бы использовать подход, на уровне разпаралеливания блоков инструкций. Например
for(i=0; i!=N; i++) {
...
}
Если :-) известно, что i не зависит от i-1. Генерировать, не как делают нынешние компиляторы, одну последовательность инструкций, а максимально возможное количество "паральных" блоков инструкций. А при загрузке программы составлять схему, что делать паралельно, а что нет, причем хитро указывать процессорам на отдельные блоки инструкций.
OpenMP, вроде как, всеравно все в потоки превращает.
for(i=0; i!=N; i++) {
...
}
Если :-) известно, что i не зависит от i-1. Генерировать, не как делают нынешние компиляторы, одну последовательность инструкций, а максимально возможное количество "паральных" блоков инструкций. А при загрузке программы составлять схему, что делать паралельно, а что нет, причем хитро указывать процессорам на отдельные блоки инструкций.
OpenMP, вроде как, всеравно все в потоки превращает.
А можно вопрос, что за блоки инструкций? Это 1010101000101?
i зависит от i-1: i = (i-1) + 1 :)
Может вы имели ввиду f(i) не зависит f(i-1)?
Ну тогда распараллеливание идет на N процессоров/ядер и то все завист от того, что в цикле. Если данные, с которыми работает алгоритм в цикле попали в кеш данных ( который не общий для ядер) то вполне будет прирост
Может вы имели ввиду f(i) не зависит f(i-1)?
Ну тогда распараллеливание идет на N процессоров/ядер и то все завист от того, что в цикле. Если данные, с которыми работает алгоритм в цикле попали в кеш данных ( который не общий для ядер) то вполне будет прирост
Мне почему-то кажется, что будущее за языками, в которых есть конструкции для непоследовательной блочной обработки данных (типа map и filter в питоне, map и grep в перле). Нынешние реализации, возможно, обрабатывают данные последовательно, но можно ограничить такое использование, тогда программисты будут в "непоследовательных" случаях их использовать, а в "последовательных" ограничатся старым добрым for - и компилятор сам распараллелит задачу на нужное (или заданное) число потоков в "непоследовательных" конструкциях )
Не "вроде как", а именно такие конструкции OpenMP в основном и призвана распараллеливать, нужно только отметить какий циклы нужно обработать так. Обычно компилятор с поддержкой OpenMP сам предлагает, какие циклы в программе можно распараллелить.
Когда я учился в университете, нам показывали concurrent pascal.
Там можно было написать for ... do, а можно было for ... pardo
Во втором случае все шаги цикла запускались параллельно.
Естественно, программист должен отслеживать легальность такой операции.
Там можно было написать for ... do, а можно было for ... pardo
Во втором случае все шаги цикла запускались параллельно.
Естественно, программист должен отслеживать легальность такой операции.
НУ елы-палы. Как же люди не могут понять, что не в компиляторах дело и не в языках! Все дело в алгоритмах! Ну не распараллелишь ты программу по определению последовательную! Надо изначально разрабатывать алгоритм параллельным. А запрограммировать его - относительно несложное инженерное дело. Вполне хватает Си и дополнительных специальных библиотек.
Много{ядерные, процессорные} системы выгодны для много{пользовательских и задачных} вычислительных систем. А там все делается на уровне ОС. И давно все придумано и сделано!
Глупые люди не могут понять, что со специализированными задачами с параллельными вычислениями работают ученые (!) а не программисты. А там как правило не только на программном уровне идут разработки, но и на аппаратном ( ПЛИСы, потоковые процессоры и т.п. ). Ну как нельзя научить постороннего человека программировать простые программы ( исключая исключения :) ), так и обычных программистов не научишь разрабатывать параллельное ПО...
В общем чего говорить, NYtimes - этим все сказано....
Много{ядерные, процессорные} системы выгодны для много{пользовательских и задачных} вычислительных систем. А там все делается на уровне ОС. И давно все придумано и сделано!
Глупые люди не могут понять, что со специализированными задачами с параллельными вычислениями работают ученые (!) а не программисты. А там как правило не только на программном уровне идут разработки, но и на аппаратном ( ПЛИСы, потоковые процессоры и т.п. ). Ну как нельзя научить постороннего человека программировать простые программы ( исключая исключения :) ), так и обычных программистов не научишь разрабатывать параллельное ПО...
В общем чего говорить, NYtimes - этим все сказано....
алгоритмы бывают широкие и/или длинные.. :)
1) Большинство? Вы подсчитали все задачи, выяснили какие из них распараллеливаются? :) Ну если рассмотреть множестов задач, состоящее из "парсинга и анализа задач" + "какую-то задачу, которая вам пришла в голову", то вы вполне правы :) Надеюсь вы поняли, глупость утверждения?
Теперь поясню, что я имел ввиду:
для решения задачи ( ТЗ ) разрабатывается алгоритм. Алгоритм можно представить в виде графа алгоритма ( в виде сети петри - как угодно душе ), где четко видны параллельные части и последоваетльные. Если алгоритм получился чисто последовательный, то его НЕЛЬЗЯ РАСПАРАЛЛЕЛИТЬ! Только не говорите мне про скрытый параллелизм! Поверьте на слово, в науке много задач, плохо распараллеливаемых. К сожалению это главная причина низкого коэффициента загрузки выч систем.
2) О чем спор? Я ms-dos не пользуюсь. Или у вас ассоциация ms-dos с Си? Если так, то мне вас жаль, т.к. такие стереотипы ни к чему хорошему не приводят. Кстати, я в своем посте сказал: "все делается на уровне ОС". Этим я хотел сказать, что решения для написания параллельных программ уже существуют и хорошо отлажены, хоть и на однопроцессорных машиных в режимы виртуального параллелизма. Вы же тмже тоже самое говорите, но только ссылками на мсдн... Не пойму о чем спор...
ПЛИС- это самый мощный инструмент для решения вычислительных задач и одновременно самый сложный в освоении для инженера-системотехника, ибо это другая философия и другой уровень разработки выч систем.
Теперь поясню, что я имел ввиду:
для решения задачи ( ТЗ ) разрабатывается алгоритм. Алгоритм можно представить в виде графа алгоритма ( в виде сети петри - как угодно душе ), где четко видны параллельные части и последоваетльные. Если алгоритм получился чисто последовательный, то его НЕЛЬЗЯ РАСПАРАЛЛЕЛИТЬ! Только не говорите мне про скрытый параллелизм! Поверьте на слово, в науке много задач, плохо распараллеливаемых. К сожалению это главная причина низкого коэффициента загрузки выч систем.
2) О чем спор? Я ms-dos не пользуюсь. Или у вас ассоциация ms-dos с Си? Если так, то мне вас жаль, т.к. такие стереотипы ни к чему хорошему не приводят. Кстати, я в своем посте сказал: "все делается на уровне ОС". Этим я хотел сказать, что решения для написания параллельных программ уже существуют и хорошо отлажены, хоть и на однопроцессорных машиных в режимы виртуального параллелизма. Вы же тмже тоже самое говорите, но только ссылками на мсдн... Не пойму о чем спор...
ПЛИС- это самый мощный инструмент для решения вычислительных задач и одновременно самый сложный в освоении для инженера-системотехника, ибо это другая философия и другой уровень разработки выч систем.
1.1. После того, как вы придумали параллельный алгоритм, его надо как-то выразить. На каком-то языке записать. И желательно сделать это с минимумом телодвижений. Об этом же речь идёт в основном. Если вы вместо threadcreate/join можете воспользоваться parallelfor, то почему бы и нет? То есть, компилятор 'распараллеливающий', если он может автоматически генерировать код для разбрасывания вычислений по нитям/процессам.
1.2. Можно автоматизировать процесс построения графа потока данных по описанию вычисляемой функции. И эта задача может быть решена компилятором. И это повышает удобство программирования. Не нужно писать 10 раз один и тот же алгоритм.
2. ПЛИС - это не самый мощный, а самый специфичный инструмент :) Для решения некоторых задач требуется полноценный процессор, а полноценный процессор на ПЛИС будет медленным по нынешним несколькогигагерцовым временам. А для некоторых не требуется, и там могут помочь ПЛИС'ы, но это не универсально.
1.2. Можно автоматизировать процесс построения графа потока данных по описанию вычисляемой функции. И эта задача может быть решена компилятором. И это повышает удобство программирования. Не нужно писать 10 раз один и тот же алгоритм.
2. ПЛИС - это не самый мощный, а самый специфичный инструмент :) Для решения некоторых задач требуется полноценный процессор, а полноценный процессор на ПЛИС будет медленным по нынешним несколькогигагерцовым временам. А для некоторых не требуется, и там могут помочь ПЛИС'ы, но это не универсально.
Не буду спорить - смысле нет :) Наверное вы правы :) ...
ссылочка на заметку: http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/advantages/performance.htm - обратите внимание на цифру 192 GFLOPS. Это для одного кристалла и то если использовать только dsp48...
ссылочка на заметку: http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/advantages/performance.htm - обратите внимание на цифру 192 GFLOPS. Это для одного кристалла и то если использовать только dsp48...
Есть неточности в деталях :) Университет Калифорнии в Лос-Анджелесе (UCLA точно не при чем.
Stanford University and six computer and chip makers plan to announce Friday the creation of the Pervasive Parallelism Lab. Besides Stanford, the backers are Sun Microsystems, Advanced Micro Devices, Nvidia, I.B.M., Hewlett-Packard and Intel.
Last month, Intel and Microsoft announced they were jointly financing new labs at the University of California, Berkeley and the University of Illinois at Urbana-Champaign to tackle the same problem. [Race Is On to Advance Software for Chips]
Стенфордский университет совместно с производителями компьютеров и процессоров планирует объявить в пятницу о создании Pervasive Parallelism Lab ("Лаборатория вездесущего параллелизма"). Кроме Стенфорда в ее создании принимают участие Sun Microsystems, Advanced Micro Devices, Nvidia, I.B.M., Hewlett-Packard и Intel.
В прошлом месяце Майкрософт и Интел сообщили, что они осуществляют совместное финансирование новых лабораторий, созданных для решения аналогичных проблем в университе Калифорнии в Беркли и университете Иллинойса в Урбана-Шампейн.
Мне кажется или они и вправду будут использовать роботов потому что денег хватает и на игрушки тоже? Я хочу там работать...
Допустим, что ввода-вывода нет вообще. Например, у нас какая-нибудь счетная программа: математика, графика и т.п. Или еще сложнее - база данных, у которой все нужные данные уже лежат в памяти и расходы на ввод/вывод отсутствуют, обращений к ОС нет. Как распараллелить такую программу на 20 ядер, если она написана на "C"?
Я не говорю, что это вообще невозможно - но на практике эта выливается в неимоверный мега-трах, занимающий уйму времени. И это могут сделать только программисты наивысшей квалификации.
Причем мы не достигаем линейного роста производительности даже если задача идеально распараллеливается в теории. И можно поехать крышей, вручную принимая решения на микро-уровне: нужно ли распараллелить memset(p, 0, n) и при каком "n", или что делать с циклом:
while (p) {
...
p = p->next;
}
Язык "C" плохо подходит для современных суперскалярных конвейерных процессоров (особенно с SIMD-расширениями), не говоря уже о многоядерных процессорах.
Чего стоит одна только проблема aliasing-а при использовании указателей - когда никому не известно, какую именно память затрет конструкция вида * p = 0 - не одну ли из глобальных переменных используемых в нашей процедуре? Не тот ли элемент массива, который компилятор только что закэшировал в регистре?
В общем, настало время что-то делать с "C".
Я не говорю, что это вообще невозможно - но на практике эта выливается в неимоверный мега-трах, занимающий уйму времени. И это могут сделать только программисты наивысшей квалификации.
Причем мы не достигаем линейного роста производительности даже если задача идеально распараллеливается в теории. И можно поехать крышей, вручную принимая решения на микро-уровне: нужно ли распараллелить memset(p, 0, n) и при каком "n", или что делать с циклом:
while (p) {
...
p = p->next;
}
Язык "C" плохо подходит для современных суперскалярных конвейерных процессоров (особенно с SIMD-расширениями), не говоря уже о многоядерных процессорах.
Чего стоит одна только проблема aliasing-а при использовании указателей - когда никому не известно, какую именно память затрет конструкция вида * p = 0 - не одну ли из глобальных переменных используемых в нашей процедуре? Не тот ли элемент массива, который компилятор только что закэшировал в регистре?
В общем, настало время что-то делать с "C".
Во многом согласен, но как раз на практике с распараллеливающими компиляторами для функциональных языков сложностей еще большие, чем с автоматически распараллеливающими компиляторами для C[++]. Сейчас функциональные языки распараллеливаются по большей части за счет своей run-time системы исполнения, что тоже хорошо, но не позволяет выжать из железа все, на что оно способно.
Хотелось бы иметь компилятор, который дал бы возможность писать идеально распараллеленные "цифродробилки", работающие на пределе возможностей процессора. Причем не только чисто счетные программы, но и с обработкой данных.
Что же касается работы с общими данными, то в последнее время я начинаю склоняться к тому, что лучше ее не иметь вообще, sharing nothing рулит. Чем меньше общих данных, тем лучше. Конечно, иногда от них не уйти по сути задачи (например, если мы разрабатываем базу данных). Но хоть в служебных структурах стараюсь от них избавиться. Пока есть общие данные, будут и все эти неразрешимые толком конфликты типа ложного разделения строчек кэша, будут mutex-ы и т.п.
Хотелось бы иметь компилятор, который дал бы возможность писать идеально распараллеленные "цифродробилки", работающие на пределе возможностей процессора. Причем не только чисто счетные программы, но и с обработкой данных.
Что же касается работы с общими данными, то в последнее время я начинаю склоняться к тому, что лучше ее не иметь вообще, sharing nothing рулит. Чем меньше общих данных, тем лучше. Конечно, иногда от них не уйти по сути задачи (например, если мы разрабатываем базу данных). Но хоть в служебных структурах стараюсь от них избавиться. Пока есть общие данные, будут и все эти неразрешимые толком конфликты типа ложного разделения строчек кэша, будут mutex-ы и т.п.
Познакомтесь с технологией OpenMP. Я сейчас пишу один проект как раз по вычислениям и сложнейшие алгоритмы сбора статистических данных адаптивным окном отлично распараллеливаются 2-3 прагмами OpenMP.
Я знаком с технологией OpenMP. К сожалению, удобна она только для чистого счета - расставить прагмы вокруг циклов for. Очень сложно добиться распараллеливания операций над структурами данных - например, сделать так, чтобы распараллеливались операции поиска в дереве, причем чтобы они совмещались со счетом в других циклах. OpenMP везде ставит синхробарьеры. Если убрать их директивами - вся ответственность за последствия на тебе. Начинаешь на микро-уровне обдумывать, что в программе на что влияет и можно ли здесь считать параллельно - никакой помощи от компилятора уже нет. Сделать же что-то вроде параллельной модификации независимых ветвей в дереве средствами OpenMP просто невозможно. То есть, как я и говорил - для чистого счета есть решения (например OpenMP или аналогичные свои средства других компиляторов), а для обработки данных - ничего нет, пиши все сам и принимай все решения своей головой. В этом плане функциональные языки потенциально лучше "C" - они могли бы (в теории) сами выявить изрядную долю параллелизма, так как в них нет переменных и компилятору самому понятно, что можно распараллелить.
Архитектуру обдумывать в любом случае надо, вопрос здесь в другом. В данном случае распараллеливание только лишь алгоритма поиска совершенно не имеет смысла, т.к. данные хранятся в разделяемой памяти, следовательно частый атомарный доступ к памяти просто напросто скушает выигрыш за счёт распараллеливания. А это уже не проблема OpenMP как технология, это ограничение архитектуры как таковой.
И ещё, я не спорю с тем, что OpenMP неидеален, это очевидно и для меня. Но, зачастую, не имеет смысла распараллеливать алгоритм на низком уровне. Допустим имеется у вас N деревьев, в которых надо осуществить поиск и сравнить результаты. Зачем распараллеливать алгоритм поиска? Можно осуществить параллельный поиск по деревьям.
И ещё, я не спорю с тем, что OpenMP неидеален, это очевидно и для меня. Но, зачастую, не имеет смысла распараллеливать алгоритм на низком уровне. Допустим имеется у вас N деревьев, в которых надо осуществить поиск и сравнить результаты. Зачем распараллеливать алгоритм поиска? Можно осуществить параллельный поиск по деревьям.
Согласен. Да и вообще используя OpenMP распараллелить УЖЕ существующий код ой как не просто. Кстати, вот еще на тему OpenMP:
"32 подводных камня OpenMP при программировании на Си++"
http://www.viva64.com/articles/32_OpenMP_traps_%28rus%29.html
"32 подводных камня OpenMP при программировании на Си++"
http://www.viva64.com/articles/32_OpenMP_traps_%28rus%29.html
Для низкоуровнего параллелизма есть Intel Threading Building Blocks.
Скорее уж не с СИ, а со стилем программирования на СИ. 'Используйте указатели разумно и наступит вам счастье' - об этом пишут в современных руководствах по оптимизации. Кроме того, есть всякие диалекты с поддержкой монад (блин, модной слово :) памяти, вроде Cyclone.
КРоме того развивается глобальный анализ программ. Можно же вычислить в довольно большом количестве случаев, куда реально показывает *p в данном конкретном вызове функции. Но это другая философия генерации программ. Например, без shared libraries.
Указатели же всё-равно нужны. Без них объективно не получится сделать сложные структуры данных. Конечно, можно выбросить арифметику, но, наверное, человечество больше выиграет от создания анализаторов программ, где эта арифметика есть.
КРоме того развивается глобальный анализ программ. Можно же вычислить в довольно большом количестве случаев, куда реально показывает *p в данном конкретном вызове функции. Но это другая философия генерации программ. Например, без shared libraries.
Указатели же всё-равно нужны. Без них объективно не получится сделать сложные структуры данных. Конечно, можно выбросить арифметику, но, наверное, человечество больше выиграет от создания анализаторов программ, где эта арифметика есть.
Нужны, вообще не представляю без них жизнь. :) Но не зря же ввели ключевое слово restrict, чтобы ограничить область их действия и всякие ключи типа -fstrict-aliasing у GCC. Было бы хорошо, если бы можно было вообще явно описывать диапазоны изменения значений у целых переменных и области действия у указателей (кстати, в древних языках типа PL/I указатели не были настолько неконтролируемыми, как в "C", правда, наверное, там больше заботились о борьбе с ошибками затирания памяти, чем о параллелизме).
Отрасль взрослеет, ООП заменил процедуры и функции, те кто хотел повысить свой профессиональный уровень, они его повысили изучив ООП. Сейчас подходит параллельное программирование, кто захочет повысит свой уровень, тот его повысит. На данную тему начинают выходят книги по паттернам параллельного программирования. И компилятор тут не причем. Так что полный бред все эти исследования (максимум что они дадут это добавление "сахара" в синтаксис, но для этого я думаю вполне хватить меньшей суммы :) ). Возможно имеет смысл сделать более удобные инструменты для отладки и тестирования параллельных программ.
С компиляторами есть реальные проблемы. Возьмем C или C++ и посмотрим на реальный код программ на них. Там постоянно используются указатели, которые делают крайне сложной или попросту невозможной оптимизацию циклов, так как формально невозможно установить, есть ли зависимости между итерациями цикла или их нет. Сложно выявить индуктивные переменные. Не понятны диапазоны изменения значений переменных. Можно, конечно, всякими прагмами и прочими нестандартными hint-ами указывать компилятору, что он должен делать в каждом конкретном случае - но это сильно усложняет программирование, а программа становится нечитабельной.
Странная новость...
В университете, который я закончил, уже лет 20 разрабатывают алгоритмы параллельных вичеслений на основе алгоритмических алгебр( пионером данного направления был, между прочем, Глушков).
Похоже что статья не имеет никого отрешение к реальности или просто является рекламой.
В университете, который я закончил, уже лет 20 разрабатывают алгоритмы параллельных вичеслений на основе алгоритмических алгебр( пионером данного направления был, между прочем, Глушков).
Похоже что статья не имеет никого отрешение к реальности или просто является рекламой.
Тот же дотнед может спокойно расшвыривать потоки по ядрам.
Вот даже специально написал простую программку чтоб проверить это.
Если кому интересно, то вот: http://www.d-popov.ru/threading.zip
Вот даже специально написал простую программку чтоб проверить это.
Если кому интересно, то вот: http://www.d-popov.ru/threading.zip
Создатели Erlang'а как в воду глядели :)
гибрид erlang и C++ (или C#) завоюет мир. :)
Компилятор из императивного языка в десять ядер невозможен. Придется переучивать миллионы быдлокодеров на фп :-)
А что ответят на это МГУ и Сколково? ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Золотая лихорадка вокруг компиляторов нового поколения