Как стать автором
Обновить

Комментарии 85

Да, наблюдаю такое у своих клиентов. Далеко не все программисты понимают правильно распараллеливание, и те, кто понимает, как правило являются ведущими программистами/тимлидами.
главное не параллелить ради параллелинга.
Лет 10 назад когда многие юные программисты делали все раздельные компоненты в разных тредах — процессорам на это было совершенно параллельно.
Потом звук как стандарт дефакто переполз в свой тред.
После, в начале эпохи двуядерности, туда же ушла и физика и видео конвертеры.

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

Так в чом мы тут говорим — о банальном разбивании програмы на блоки и обучении этих блоков работать асинхронно, или о тех красивостях что дает OpenMP и другие CUDA\OpenCL( имхо мы же в параллели на нескольких сотнях ядер считаем )

Если последнее — сотрите упоминание по pthreads :)
А если первое — сотрите OpenMP

эти две философии живут в параллельных мирах
пс: и я очень надеюсь что я везде написал правильное количество «лл»
Да сейчас всё WEB-программирование, по-сути, параллельное. Даже банальные скрипты на PHP. Даже простейшая гостевая книга, если к ней одновременно обратятся двое.

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

Главное — понимать, что распределение работ осуществляется на нижнем уровне. А проблема разработчика — обеспечить работу своих скриптов таким образом, чтобы их параллельная работа не нарушала исходного алгоритма. Например, за счёт использования БД. Либо за счёт файлов-флагов.

Статья, конечно, правильная для «системщиков» типа Игоря Сысоева (разработчика ngnix-a), но таких единицы. А для остальных особо ничего не изменится. Просто весь софт постепенно перейдёт в интранет/интернет.
пхп скрипты совсем не параллельны, и их запросы к базе данных тоже.
это просто набор «програмок» которые исполняют различные задания для различных людей, и, по хорошему, полностью изолированные друг от друга.
Вопросы же поднимаемые в данном топике касаются решения ОДНОЙ задачи и одной цели несколькими мозгами.
Тоесть ровно обратная задача :)

И нгинкс кстати не параллельный — он асинхронный( воркеры не всчет)
Вы ошибаетесь. Никакой параллельности тут нет.

Может быть есть одновременность выполнения, что создает иллюзию параллельности. Как же это сказать то правильно… интуитивно представляю, а словами не могу :(

Понимаете, скрипты выполняются одновременно (и как-бы параллельно, но только для наблюдателя), но выполняют разные завершенные задачи. Например добавляют сообщения в гостевую книгу.

Насколько я понимаю параллельность (википедию не читал ;) ) — это… давайте я аналогию приведу лучше?

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

P.S. Надеюсь, мои аналогии не покажутся наивными для гуру ;)
конкурентность ( concurrency ) это называется причём может способствовать паралелизму если процессы не блокируют друг друга и система может им выделить отдельные ядра
Да понятно что это не чистая параллельность, никто не спорит :) Но я смотрю более глобально на проблему. По сути — все те задачи, что сейчас решаются параллельно — это множество разных, независимых кастрюль.

Даже извлечение корня и вычисление числа Пи можно разложить в ряды, части которых считать на разных процессорах (или в разных потоках). Тогда снова получается, отличий от банальных скриптов PHP нет.

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

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

Может, за этим будущее?
Как вариант развития событий — мода на распараллеливание всего пройдёт, и область останется довольно узкой и специфичной.
В частности, такой позиции придерживается Дональд Кнут:
Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.

How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, although the hardware folks in our department assure me that I’m wrong.

I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.
Мода уйдет, если будет предложен альтернативный путь. А его пока не видно.
kashey в комментарии очень здраво отделил параллельные системы от параллельных алгоритмов.
То есть да, выполнение различных по функциональному наполнению модулей на разных ядрах — это приятно.
А вот задач, где нужны именно параллельные алгоритмы (мы же про OpenMP тут, и иже с ними?), ну их же реально не так много.

> будет предложен альтернативный путь
Альтернативный путь чего? Дальнейшего истязания закона Мура?
Закон Мура — это же просто маркетинг, с него вполне можно пересесть на что-либо ещё.

Вот почему-то мощность автомобилей не растёт почти совсем, но чего-то не слышно плача и выкриков «О! Автомобильная индустрия зашла в тупик! Надо искать выход!»
Тихонько фигачат себе, и всё.

Производителей железа постигнет та же участь. Рано или поздно.
Вот лично меня всё устраивает в моём настольном Семпроне-1800 с 512 метрами.
мощность автомобилей не растёт почти совсем
Это правда, если вы говорите про ВАЗ.
Скачал
«Energy in Transport
Trends and Influencing Factors
2006 Report»

Буду изучать и авторитетно отвечу тогда
Машин есть разумный предел.
Вы себе представляете таксиста на 600 сильном тарантасе, или бабушку отправлющуюся за покупками на реактивном автомобиле?

Есть порог разумности. В городе, на трассе, и даже на автобане не всем нужно нестись 300-400, разгонятся и тормозить с перегрузкой как в истребителе.

Правда для компьютеров пока ещё придумают чем озадачить ресурсы :)
Я, впрочем, и не говорил, что это надо.
НЛО прилетело и опубликовало эту надпись здесь
python как управляющий, все вычисления в С/С++
Собственно, я сейчас именно так пишу для кластера (только на Ruby вместо питона).

Ну, ещё с D можно поковыряться, только сейчас там синтаксис неопрятный…
В D неопрятный синтаксис? Тогда ковыряйте Common Lisp. ;)
Ruby ковыряю же.

2**(123.to_s.reverse.to_i)

Угадайте, что делает?

Хотя D конечно намного, НАМНОГО лучше чем perl.
Ну или там
100.times{ puts rand }

или

(9..17).to_a.inject(0){|summ,i| summ+3**i}

выведет 193700403
НЛО прилетело и опубликовало эту надпись здесь
У меня только один вопрос: зачем? Паралельность на таких простых конструкциях не нужна никогда.

Паралельность нужна, когда нужно производить много вычислений (зачастую однотипных), тогда компилятор олжен понимать, как надо разбить вычисления нанезависимые части (в идеале, зависимые) чтобы считать их в разных потоках.
Такое уже есть — причем давно.
www.keldysh.ru/dvm/dvmhtm1107/rus/dvmINTRr.html#3%20%D0%A1%D0%BE%D1%81%D1%82%D0%B0%D0%B2%20DVM-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B
Программы на Фортране и Си автоматически распараллеливаются.
Все равно, в этой системе вся паралельность ложится на плечи прикладного программиста.

Программисту предоставляются следующие возможности спецификации параллельного выполнения программы:

* распределение элементов массива между процессорами;
* распределение витков цикла между процессорами;
* спецификация параллельно выполняющихся секций программы (параллельных задач) и отображение их на процессоры;
* организация эффективного доступа к удаленным (расположенным на других процессорах) данным;
* организация эффективного выполнения редукционных операций — глобальных операций с расположенными на различных процессорах данными (таких, как их суммирование или нахождение их максимального или минимального значения).
НЛО прилетело и опубликовало эту надпись здесь
либо тот исполняется, либо тот. Не вижу применение многопоточности на одном конкретном if-е
НЛО прилетело и опубликовало эту надпись здесь
Вообще то например в Pentium 4, скорее всего конвер будет переупорядочен и одновременно будут исполнятся оба if, на момент сравнения один из результатов будет отброшен. Но вот чрезмерное усложнение схемы предсказания с некоторого момента перестаёт играть позитивную роль, а усложняет схему, повышает потребление, замедляет ковеер, потому в Core 2 Duo вернулись к модифицированной архитектуре P3, а вот Core iххх возможно возродила опять эти идеи, HyperThreading требует довольно сложного планировщика и предсказателя переходов, но я уже перестал следить за новшествами в архитектурах.

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

х86 архитектура не самая удачная для таких задач, компилятор для Итаниума для такого кода может сгенерировать сразу код для загрузки конвеера, а учитывая что это VLIW, то там и плотность инструкий выше, а конвеер проще.
Если там будет вызов функции, то получим колл, и если компилятор не смог оптимизировать вызов, то получаем перезагрузку конвеера, а возможно и его остановку изза того что нужно подгрузить в кеш недостающие данные.
А теперь представьте что в рамках одной архитектуры P3, P4 и Core 2 Duo и даже в рамках одного поколения но с кристалами с разными кешами этот код будет исполнятся по разному. Вы всё ещё хотите что-то вроде VHDL, а готовы оптимизировать под все наличествующие на рынке семейства процесоров, а также после поставки на рынок обновлять для новых. Во сколько вам такая разработка вольётся?
Я считаю что оптимизации такого рода должен делать по большей мере компилятор или возможна или какой-то рантайм с оптимизацией по мере исполнения, Profile-Guided-Optimization пока не расскрыл весь свой потенциал, да и JVM, .NET JIT можно в этом направлении оптимизировать.
А если посмотреть на типичный софт, то действует как всегда принцып Паретто, 10% функций исполняются 90% времени, а остальное ждёт окончания. Те 10% в большинстве случаев оптимизируются неплохо и существующими методами.
НЛО прилетело и опубликовало эту надпись здесь
Предел уже можно сказать достигнут, ведь гонка ГГц уже прекраилась, это примерно 3,3 Гц.
Я так понимаю на большей частоте издержки на схемы синхронизации превышают все разумные значения.
Вспомните из личных задач сколько из них не решаются имеющимися средствами. Игры — для ных созданы графические ускорители. Для остальных повседневных задач домашнего пользователя 4 ядра пока будет достаточно. Я понимаю маркетинг каке-то время превознесёт перекодирование в AVC за надцать секунд на 50 ядерном процесоре, но будет ли готов потребитель платить за это?
Закон Мура домашнему пользователю не нужен, потому что потребности домашнего пользователя не растут по этому закону.
Остаются нучная сфера и корпорации, но и там, часто применение специализированого ускорителя даёт больший результат, чем сотни универсальных вычислителей с КПД для даной задачи менее 10%. В Веб параллелизм на уровне процесов, который достаточно хорошо работает в рамках существующих парадигм простым добавлением ядер и памяти, здесь больше играет архитектура компютерных систем, иерархия памяти, арбитраж доступа к ней, пропускная способность, латентность, системы ввода-вывода.
Современные технологии призваны решать задачи, которых не было до их появления =)
Так же и с компьютерами — были бы 50 ядер, а применение найдется.
НЛО прилетело и опубликовало эту надпись здесь
Я более чем уверен что маркетинг Интела придумает больше новые задачи, готов ли за это платить потребитель. Но вот только указанное вами расспознавание неплохо работает и на существующих архитектурах. Более того х86 для многих алгоритмов избыточен и неэфэктивен, мне кажется OpenCL для этих задач более предпочтителен будет.
3D лучше работает на специализированных видеоускорителях, а там уже и так >50 ядер. Тот факт что приставочный бизнес приносит больше прибыли привёл к тому что изза игрушек стали меньше покупать ПК, а современные масовые игрушки стали менее требовательны, потому что уровень приставок отстал от уровня видеоускорителей.

Если же говорить об исходной теме статьи. То не будет масового предложения работы паралелистам, просто потому что не может быть много хороших паралеллистов, алгоритмистов и математиков. Их нужно достаточно чтобы написать достаточно хороших оптимизированных библиотек Intel Performance Primitives, OpenCV, оптимизированные компиляторы, а остальная маса будет использовать иногда правильно, иногда нет ихние наработки.

НЛО прилетело и опубликовало эту надпись здесь
В Picassa и iPhoto расспознавание лиц уже реализировано.
Вы хотите по сути искусственный интелект и увязываете его с паралелизмом. К сожалению я не вижу возможности для какого-то особого прорыва в этой области, только решение частных задач. Многоядерность здесь вообще слабо увязывается, да некоторые задачи можно распаралеллить, но невозможно расспаралелить то для чего не придумано алгоритмов. Гугл, Майкрософт и компании помельче работают над этими задачами, но кроме частных решений я не верю в радикальный прорыв в ближайшем будущем. Более того я думаю более ресурсо'мкие приложения будуть исполнятся в специализированніх облаках, а пользователь будет получать только результаты.
Насчёт фильмов, такой проблемы нет если изначально иформация имеет метаинформацию. Так или иначе ваша свалка фильмов это пережатые варианты чего-то что уже существует с этой иформацией. Решений для вашей проблемы скорее всего и не будет, потому что фильмы то пиратские, а следовательно на вас денег не заработаешь. Если брать тот же iTunes, Miro при помещении в каталог добавляют необходимую метаинформацию. Можно конечно придумать задачу, найти сколько в секундах в определённом фильме и в каких нарядах появлялась Одри Хепбэрн, а также проставить метки для быстрого перехода к эпизодам, но только насколько нужно это будет пользователю, готов ли он будет оплатить трудозатраты на это и почему он не может то же получить с облака например на свой мобильный?
Моя идея такова, что каждое новое ядро даёт всё меньше полезного действия пользователю и уже скоро будет излишним. Готов ли он будет оплатить миллиардные затраты Интела и АМД?
НЛО прилетело и опубликовало эту надпись здесь
Не в плане спора, просто замечание:

> распознаванием оно станет, когда будет находить Васю Пупкина на всех имеющихся фотках

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

Ребята из Гугла хорошо вложились в Picasa, и «распараллелена» она — любо-дорого посмотреть.
> Я думаю до такого распознавания еще годы и годы и годы. современные средства еще просто не в состоянии решать такие задачи.

Они не в состоянии не из за технологической невозможности, а изза отсутствия универсального алгоритма. И таковой вряд-ли появится в обозримом будущем.
Вообще то такие штуки Intel C++ Compiler умел расспаралелить наверное уже в году 2004, только вот нужды в этом не так уж и много.
Чесно говоря не верю в будущее erlang в мейнстриме. F# и при определённом везении Scala получат расспространение безотносительно к их преимуществам, недостаткам, только потому что за первым стоит Microsoft, а второй по сути единственный более-менее расспространённый функциональный язык на платформе JVM.
Легкие потоки + иммутабельность и чистота.
Иммутабельность и чистота не являются необходимыми, но учат писать независимые потоки без синхронизаций.

Erlang, Haskell,…

Многопоточные системы пишут уже давно (Erlang), просто не везде, так что технологии есть.
Для 1-3 нужны задачи которые хорошо расспаралеливаются, а их пока не так уж и много. Да возьмём Ворд вроде-бы много потоков, но вот проблема, та же проверка орфографии не так хорошо и расспараллеливается, потому что зависимость меж данными и их уровнями.

VHDL выбран как не самый удачный прототип, к тому же не самый расспространённый.

Вообще-то в мейнстрим возвращаются функциональные языки(.NET F#, JVM Scala) и я уверен что основные движения будут именно здесь.

Мне кажется Кнут как раз имел ввиду то, о чем написал предыдущий комментатор:
«главное не параллелить ради параллелинга», совсем недавно это было действительно модно.

Ключевая фраза в высказываниях Кнута:
But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.
ТеХ требует параллельности не от компа
Он требует это( и распальцовку еще, также как и vim) от пользователя.
Распальцовка — это, напротив, емакс.
не, распальцовка, это когда надо дергаться к мыши каждую пару минут
Вполне возможен и вариант развития событий, при котором многоядерность используется для массивной виртуализации всяких новомодных cloud штук, которые вполне последовательно высчитывают по старинке :)
*пошел учиться распараллеливать
Подсчитал посты на главной Хабра; любопытно — ровно половина так или иначе связана с определенными требованиями к производительности:

Opera 10.50 — снова самый быстрый браузер
Новое поколение nVidia ION
johnny-cache — кэширование SQL-запросов
Нынче ночью состоялся запуск ещё трёх космических аппаратов Глобальной навигационной спутниковой системы (ГЛОНАСС)
Электроника в болидах Формулы 1

Так о чем это я… Есть такое мнение, что производительность — вторична, а функционал — первичен.
Андрей, а покажите нам класс? Попробуйте «продать» Хабрапользователям каждый из этих проектов, «с точки зрения повышения конкурентоспособности». Мы все — как бы заказчики. Вы — подрядчик, в совершенстве владеющий методами параллельного программирования.
Какой выигрыш мы получим в этих «проектах» от распараллеливания?

Уважаемые Хабрапользователи! Предлагаю голосовать за каждую попытку «продажи»: плюс — убедил покупаю, минус — не впечатляет, не покупаю ;)
По поводу Opera. Как продать в ней хорошую параллельность, я не знаю. Зато точно знаю, как продать в комплект к Опере многоядерный процессор. У меня дома относительно слабенькая 2-х ядерная машина. И когда идет процесс компиляции, я не могу нормально посмотреть видео в интернете. Даже если компиляция идет в один поток. Видимо второе ядро в этот момент съедается VS IntelliSense, Касперским и так далее. Причину точно я не знаю, но дискомфорт ощущаю. На работе на машине с 4 ядами, я кажется подобного не замечал.
О, а вот Вам тогда и альтернатива, от профессора Преображенского.
Помните, «принимать пищу в столовой, а работать в кабинете» и всё такое прочее?

Вот я и думаю, что видео надо смотреть на телевизоре, звонит по телефону, а компилировать — на рабочем компьютере.
То есть специализация сделает решение конкретных задач гораздо более комфортным.
Автомобильная аналогия, опять же. Есть смарты, есть трактора. Они для разного, и каждый делает своё дело хорошо. Пользователи довольны и пляшут, маркетологи диверсифицировали рынок, инженеры работают не над одной универсальной моделью, а над несколькими специализированными, то есть работы для специалистов больше. Мечта прямо. И переписывать все-все программистские книжки не надо.
Религия поднять приоритет для видеоплеера или опустить для компилятора не позволяет? Совсем расслабились и забыли как это делалось на одноядерниках?
Как пользователь я ничего не знаю, и даже не хочу знать про приоритеты. Я хочу чтобы у меня не тормозило и все. :) Уверен такая позиция вполне имеет право на жизнь. :)
Ну нет в жизни счастья.
Если разработчики плеера (программного плеера или flash-плеера) не поднимают сами себе приоритет, то ничего тут не поделать. Для программных плееров есть например reclock, который умеет повышать автоматом приоритет. Есть также Prio, который умеет сохранять приоритет для заданного приложения. Но во для флэш-плеера придумать нечего, только лишь поднять приоритет всего браузера/опустить остального.
И никакой восьмиядерник тут не поможет, если в фоне будет рендериться что-то на всех 8ми ядрах.
Я не гуру в архитектурах ОС, но мне кажется можно было бы сдеать все гораздо проще не напрягая ни пользователей, и программистов ПО.
Отдавать максимальный приоритет тому приложению с которым в данный момент работает пользователь, а на другие приложения то что останется, и делать это автоматически на уровне операционки(ну или околоОСного окружения).

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

Если кто-то лучше понимает почему это не так — расскажите плиз, и что мешает разработчикам ОСей это реализовать — ведь идея лежит на поверхности, но нигде нет (покрайней мере из тех что я знаю).
Windows отдает приоритет приложению с активным окном. Проверял так: запустил 2 раза программу, которая жрет 100% моего одноядерного проца и щелкал между окнами. Разница не огромна, но хорошо заметна.
То что Вы описали, реализовано уже давным давно. :))) За подробностями — к Рихтеру.
Если кто-то лучше понимает почему это не так — расскажите плиз

Так, но не всегда. Если вы слушаете музыку и комплименты, то музыка не должна прорываться, чтобы отдать компилятору еще 1%, даже если он активен.


Грубо говоря — Есть какие-то дешевые 1% задачи, которым неплохо бы иметь повышенный приоритет

А вы уверенны что узким местом у вас не будет система ввода-вывода. На большом плюсовом проэкте именно «тормознутость» винта является узким местом.
Дальше не могу, я далек от данных тем. :) Надо погружаться в каждую из них. Быть может кто-то, для кого это актуально, присоединится? :)
Та же Формула-1 после сокращения времени, возможного проведения в аэродинамических трубах, переходит на вычислительную гидродинамику (про системы для вычислений такого рода задач можете почитать ниже в моем комментарии про кафедру Вычислительной механики). А для таких вычислений нужно достигать максимума из доступных ресурсов. Для того чтобы считать на супере эфективно надо прилагать усилия и не малые.
Немного про эфективность:
Если в однин поток время счета t_1, в 2 — t_2, ..., в N потоков t_N
И если рассматривать величину a_N = t_1 / t_N (во сколько раз уменьшилось время счета) и сравнивать с N, то получается печальная картина. Хорошо если a_N/N ~ C*N, бывает что и вообще стремится к нулю. А в случае ~ C*N, бывает C ~ 0.1, или и того меньше. Так что паралельное программирование не так уж и вторична.
Это более глобальное обобщение проблемы. Если брать детальнее, то достаточно сказать, что от собеседника требуется умение создавать атомарные процедуры, которые смогут работать как в едином экземпляре, так и в бешеном распределении на кластерах.

То же самое, что говорить о распараллеливании при постановке задачи «запускать демоном или по крону» — тут достаточно много решений, основное — это блокировка сущности в общей БД, а там работа по принципу — кто первый встал, того и тапочки.
вот, очень правильная мысль

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

навыки параллельного программирования здесь если и нужны, то минимальные
и такая ситуация в 90% задач

имхо достаточно иметь базовое представление о правилах проектирования приложений и систем, которое позволит при необходимости наращивать производительность критичных элементов путем настроек исполняющей среды, а не переписывая код
будет ли это отдельное ядро или отдельный сервер — дело десятое…
Я вижу, как технологии паралельного программирования приобретают все большую актуальность. У меня на кафедре (Вычислительная механика Мехмата МГУ) 2 года назад паралельностью занимался только я и еще 2 моих одногруппника (все трое у одного научного руководителя). Мы пишум уже третий год программную среду разработки, резко упрощающую написание паралельных программ. К сожалению, упрощение происходит только в «наших» задачах (то есть задачах механики, но эти задачи занимают немалую часть вычислений на суперкомпьютерах).

В этом году, среди третьекурсников (распределение по кафедрам после второго курса происходит) уже половина занимается паралельным программированием, при этом технолгии используются совершенно разные:

CUDA — неплохой прирост в производительности дают видеокарты, так как там много «маленьких ядер», каждый из которых может взять на себя маленький поток вычислений. В механических задачах, обычно строится какая-то вычислительная модель, основные действия в которой это стандартные сложение, вычитание, умножение и деление, поэтому CUDA замечательно подходит. В ИПМ (Институт прикладной математики им. Келдыша) вроде собираются строить супер(супер компьютер) на основе fermi.

Какая-то система от Intel, позволяющая паралелить программы на «домашнем» многоядерном процессоре. К сожалению не помню специфики.

Система, которой занимаюсь в том числе и я, позволяющая упросить написание паралельных программ, сейчас проходит обкатку на суперах (пока правда маленьких в ИПМ, но результаты выражают оптимизм). Может когда-нибудь выйдем на МГУ-шного «Ломоносова».

Конечно, есть люди использующие MPI, но есть мнение, что в нем используется много накладных расходов, при увеличении числа вычислительных узлов.

Так что я с оптимизмом смотрю в будущее и думаю, что специалисты по паралельному програмированию будут нивелированны средствами разработки и опытом молодого поколения.
Точно, давайте расширим понятия распараллеливания с одной машины и кучи ядер( все описанные технологии в этом топике на этот момент) на кластеры и другие современые клоуды.
Имхо сетевые мьютексы, отказы нод, асихроные ожидания — это вам не #pragma omp pallalel for и поехали
И RPC с корбами тут не спасет
Вы хоть раз Корбу видели в глаза? Это пример того, как не нужно делать.
RPC то же сколькая тема, к сожалению 90% существующих RPC систем малоприменнимы в том виде, в котором они есть.
И все равно, имея RPC программисту придется возиться со всеми синхронизациями, делая нудную, однообразную, плохоподдающуюся автоматизации работу.
да, я к сожалению видел и CORBA и препарировал ее ORBов
Хотя для своих задач — очень удобна.
В два клика прокинуть полный функционал класса в другой язык, да еще и с другой машины.
К сожалению, придется описывать весь функционал, который нужен.
Если посмотреть, например, на PyRo то там вообще какой-то праздник, в части rpc, посмотрите минимальный пример здесь
Гм, с виду работает также как корба.
Только не надо «ручками» интерфейсные классы поднимать.
Только она only python, но ctypes или c-api дает выход в любой другой язык программирования. А динамичность python-а позволяет объект с методами сгенерить находу.

И не надо никаких rmiregistry запускать на каждой машине (как это сделано в RMI в java), не надо описывать интерфейс класса как в большинстве RPC. Все просто и красиво. А главное работает, сходу без многочасового шаманства.
питон — один из немногих языков который реализует шаманство кода а не исполнения :)
Ой, я чуть неправильно понял ваше мнение. Почему-то думал, что вы считаете что rpc и corbo спасут. Этот топик просто очень близкок ко мне по части научной работы.
Гм, мне тоже ее подсунули по научной работе
«Вах смотри какая сказка, чтоб завтра в общем работало!»
И использовали ее потому что функционал который надо было викинуть в инет, да еще и в солярис работал только под виндами, на дельфях…
Ну зачем же переписывать, мы так старались..
Я вообще проводил анализ всех rpc, которые были хотя бы мало-мальски разумны с первого взгляда.

Некоторые решения, казалось бы разумных RPC, просто убивали: в Zeroc ICE, например, нельзя передать массив. Просто нельзя. Только контейнер или в виде связного списка.
Просто хочу уточнить один момент, почему я постоянно сужать внимание на многоядерных системах и упускаю из виду кластерные системы. Дело в том, что кластеры существуют уже давно и их использование уже отработано. Ничего революционного с кластерами не происходит. Были специалисты, которые работали с кластерами, есть и будут. А вот с многоядерными системами, которые появляются на столах у простых пользователей, совсем другого дело. Для них почти нет ПО. Методы его разработки не развиты. Почти нет разработчиков. Это новое направление. Поэтому и говорить про эти системы намного интереснее.
На многоядерных компьютерах (особено с видеокартами, где ядер много) можно использовать кластерный подход. Но для большой оптимальности надо использовать отсутвие ограничений, присутвующих в класстерах. Например: общая память, быстрые обмены между потоками и прочее
То есть Вы утверждаете, что в кластерах процессоры остаются прежними и на них технологии не меняются? :)
Меняется. Но я о другом. Например, раньше распараллеливали расчет полета тела на нескольких машинах, объединенных в сеть. Теперь отдельно задумываются, как распараллелить еще и на конкретном узле с общей памятью. Могут появляться спайки вида OpenMP+MPI.

А теперь берем пользовательское программное решение под Win32… там даже никто никогда и не задумывался, над таким словом как параллельность! Да, там могут быть потоки, например для фоновой отрисовки прогрессбара. Но это совсем иное. И адаптация подобных программ — терра инкогнито.

При этом адаптация бытовых приложений может быть сложнее, чем усовершенствование некой системы численного моделирования. Архитектура пакета численного моделирования изначально рассчитывается с учетом параллельности. А в обыкновенных приложениях, там не только черти ноги ломать будут. :)
Я похоже живу в другом мире. У меня распаралеливание ассоциируется с GoLang + MapReduce. Причем вторым занимаюсь последние 3 года.
Все коменты гадал что же вы имеете ввиду — кластеры или многоядерные процессоры у обычных, домашних пользователях.
Что делает пользователь обычно своей массе — смотрит/слушает/играет/пишет.
В играх этот тред уже давно, как писали выше.
Паралелить текстовые процессоры и программы создания презентаций? Они и так шустро летают, и тут каких-то сверхгигантских суперзадач нет.
Самые подходящие жертвы для распаралеливание это графические пакеты, музыкальные пакеты.
А там давно и старательно борятся за производительность, и они такой тренд не упустят.

Вобщем имхо, всё и так идёт как надо, а паралелить ворд я смысла не вижу — я не могу сразу 10 документов набирать — пусть себе в фоне орфографию проверяет и прогресс бары рисует многопоточно. Не надо увлекатся выше меры и преувеличивать важность этого дела :)
Рассуждения в рамках теории заговора.
Мир программирования давно уже стал коньюктурно оиентированным. Это означает что активным спросом на рынке пользуются те специалисты которые хорошо разбираются в абсолютно попсовых вещах типа .net.

С другой стороны рынок потребляет популярные технологии, которые обеспечиваются поддержкой массового количества специалистов с рынка труда.

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

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

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

Места в секретных лабораториях уже заняты. И надолго. Так что боятся не надо. Надо ли изучать новые технологии? Да. Потому что этого дребует профессиональная этика любого инженера или разработчика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий