MPI & CP( параллельные вычисления на конвергентных двуядерных процессорах) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

MPI & CP( параллельные вычисления на конвергентных двуядерных процессорах)

Отправлено andrews 01 августа 2007 г. 14:14

Поскольку практически каждому желающему сделались доступны (уже несколько лет назад)двуядерные конвергентные процессоры типа ADSP-BF561 в повестку дня стал вопрос о параллельных вычислениях :)
Увлекается кто-нибудь из присутствующих господ? Если да, есть следующие вопросы:
1) годится ли MPI (Message Passing Interface) для таких, скажем прямо, нетрадиционных мегакомпьютеров?
2) если да, есть ли бесплатные компиляторы и операционки для этого случая ( то есть портированные на Blackfin)
Спасибо!

Составить ответ | Вернуться на конференцию

Ответы

средства, то есть - но на BF это будет выглядеть приблизительно как ПРОЛОГ на спектруме — yes (01.08.2007 15:54:44 87.236.81.130, 579 байт)
- Ответ: есть ответ ниже...для BF это более сложный кодек, или обработка изображения с большим количеством пикселей за зад. время — andrews (01.08.2007 16:05:14 62.16.102.166, пустое)
  - Так там задача уже давным-давно самим стандартом MPEG/JPEG распараллелена. Для того и придуманы были slice'ы/scan'ы всякие. — quark (01.08.2007 16:43:56 89.20.146.162, пустое)
И зачам тебе этот геморой, не проще ли вычислитель помощьнее задействовать? — AlexD (01.08.2007 15:38:3 193.200.21.5, пустое)
- Ответ: деньги люди считают...но к дешевому (и экономичному по моще)железу нужен недешевый инструментальный софт :) + — andrews (01.08.2007 15:42:1 62.16.102.166, 104 байт)
  - ничё не понял — AlexD (01.08.2007 15:44:3 193.200.21.5, пустое)
    - Ответ: в реальной системе ( как в жизни) есть пиковые задачи...мощный проц их, конечно, решит+ — andrews (01.08.2007 16:01:9 62.16.102.166, 814 байт)
      - Не верю, что распараллелить задачу дешевле, чем просто сделать порт под другую архитектуру, даже купив новый софт для разработки. — SM (01.08.2007 16:07:45 85.21.237.237, пустое)
- зачам -> зачем — AlexD (01.08.2007 15:38:39 193.200.21.5, пустое)
  - За запал он на "черный плавник" ;) — Гудвин (01.08.2007 15:41:19 195.133.109.197, пустое)
    - Ответ: не меня одного интересует, как на двух ядрах счастье поиметь :) — andrews (01.08.2007 15:43:51 62.16.102.166, пустое)
      - Собсна какая проблема вручную то распараллелить? — AlexD   (01.08.2007 15:46:25 193.200.21.5, пустое)
        
        Ответ: время->деньги->издержки — andrews   (01.08.2007 16:02:37 62.16.102.166, пустое)
        
        Дык может там просто один цикл нужно тупо пополам распилить. Делов на пол часа. А мы тут копья ломаем. Ты ж партизан. — AlexD   (01.08.2007 17:59:36 212.220.83.74, пустое)
        
        Не обязательно пилить задачу строго пополам, можно сделать один проц сопроцессором другого для пиковой нагрузки, а остальное время пусть дрыхнет. — AlexD   (01.08.2007 18:01:27 212.220.83.74, пустое)
Он у Вас что-то припозднился с вставанием, этот вопрос. Вообще он встал лет 30 назад и даже кажется с лихером. Если не зацикливаться только на блэкфине. И народ вовсю занимался этим. Даже до появления многих (2-х) ядров на одном кристалле. Да и после, когда надо было очень много (больше 2-х) процессоров в задаче. — -=ВН=- (01.08.2007 15:11:16 193.125.71.140, пустое)
а VDK не поддерживает многопроцессорность? — AlexD (01.08.2007 14:42:49 193.200.21.5, пустое)
- Ответ: примерно так же как MMX для 8080 в 1980 г., а речь идет о нормальном распараллеливании компилятором, чтобы Visual DSP++ это мог делать! — andrews (01.08.2007 14:58:26 62.16.102.166, пустое)
  - Visual DSP++ - врятли, а вот GCC... — AlexD (01.08.2007 15:15:32 193.200.21.5, пустое, ссылка)
    - Ответ: очень интересно, спасибо, поизучаю — andrews (01.08.2007 15:24:54 62.16.102.166, пустое)
Вообще-то многоядерные процессоры такого класса (с соотв. быстродействием на то время) были доступны еще с прошлого века у конкуррентов :) (542x, 544x TMSы) И в их родной операционке как помнится была поддержка межпроцессорной связи через их FIFO-шки. — SM (01.08.2007 14:21:49 85.21.237.237, пустое)
- Ответ: средства разработки, заточенные на MPI были?+ — andrews (01.08.2007 14:31:27 62.16.102.166, 353 байт)
  - Тогда точно не были. А сейчас вроде многоядерность уходит в прошлое (у ТИ по крайней мере), заменяясь на умощнение 6000-ных серий, в которых параллелит вычисления сам компилятор, учитывая их особенности архитектуры (до 8 операций в паралелль). Так что тут я не могу ничего конкретного подсказать. — SM (01.08.2007 14:45:9 85.21.237.237, пустое)
    - Ответ: и можно проконтроллировать загруженность ядер, кстати, 8-ядерные что ли уже есть? — andrews (01.08.2007 14:56:24 62.16.102.166, пустое)
      - Да нет же, Вы не правильно поняли. Они перестали делать многоядерность, а продолжили одноядерные, но 8-юнитовые. Одно ядро там. Ну а проконтролировать загрузку тех многоядерных можно было штатными средствами внутрисхемной отладки. — SM   (01.08.2007 15:00:33 85.21.237.237, пустое)
        
        Ответ: а чем "юнит" отличается от "ядра"...гетерогенностью что ли? — andrews   (01.08.2007 15:01:55 62.16.102.166, пустое)
        
        Ну типа как ядро(процессор), способно решить задачу целиком, без помощи другого ядра, тока м.б. в другом временном масштабе. А вот юниту это может доставить большие хлопоты. Согласитесь, что не всякую задачу можно свести только к умножениям, например. — -=ВН=-   (01.08.2007 15:18:35 193.125.71.140, пустое)
        
        Ну тут как сказать - если брать комплекты из 4-х юнитов, коих там пара, то каждый из них может спокойно решить задачу целиком. Но вот решать каждой половине независимо от другой другую задачу сложновато :) — SM   (01.08.2007 15:22:8 85.21.237.237, пустое)
        
        Да так и сказать. Что вот если есть регистр, то во складывать он не умеет. А чиста сумматор с трудом сохраняяет результат, ввиду отсутствия места хранения. А вот если их скрестить, то это уже будет и не сумматор и не регистр и могет этот мутант и слагать и хранить. Вот и с четырями юнитами так же. Т.е. вроде как 4 юниты это уж вроде и не один юнит. — -=ВН=-   (01.08.2007 15:30:56 193.125.71.140, 173 байт)
        
        Тем, что из памяти из одного адреса "достается" одна VLIW-инструкция, содержащая в себе от 1 до 8-ми инструкций юнитам, в отличие от двух ядер, которые достают свои инструкции по своим отдельным счетчикам команд. Т.е. при 8-юнитовости компилер локально распараллеливает куски кода, а не глобально весь алгоритм. — SM   (01.08.2007 15:04:8 85.21.237.237, пустое)
        
        Ответ: вот в четырехядерных пнях есть такой компилер? чтобы честно показать юзеру, как они загружены вычислениями? — andrews   (01.08.2007 15:03:49 62.16.102.166, пустое)
        
        ИМХО "в пнях" не компилерово это дело. Там операционная система "делит пни" между процессами. А процессы уже (если захочет) плодит автор программы. — Сидоргек   (01.08.2007 15:11:19 217.146.246.12, пустое)
        
        Ответ: чтобы это происходило, код должен быть как-то помечен для распараллеливания в процессе разбора, а MPI дело довершает, имхо... — andrews   (01.08.2007 15:21:59 62.16.102.166, 481 байт)
        
        Именно, об том и речь. Чтобы автоматически разпаралеллить на этапе компиляции однопоточный алгоритм на несколько одинаковых потоков (одинаковый код, исполняемый паралелльно, с возможностью выполнения на N процессорах, где N задается юзером и заранее не известно). IMHO задача на сегодня в общем виде не решаемая, т.е. компилятор на это не способен. — SM   (01.08.2007 15:14:57 85.21.237.237, пустое)
        
        Ну было, было средство помогающее параллелить. На О называлось. До всяких пней и виндовсов. Народ в древности много чего напридумывал. — -=ВН=-   (01.08.2007 15:22:53 193.125.71.140, пустое)
        
        Ответ: Okkam(?) ...да полно людей этим занимается, но больше применительно к моделированию, а не во встроенных приложениях...тем не менее сейчас в индустр. компы пошли многоядерные пни, да и у TI, с ADI такое есть — andrews   (01.08.2007 15:27:46 62.16.102.166, пустое)
        
        Оккам. Только будет проще, если забудете слово встроенные. Параллельные вычислители дело давнее. Реальное и в железе исполненное не раз. Программили их кто как может. Кто и сам себе оккамом выступал. Но и оккам пользовали. — -=ВН=-   (01.08.2007 15:35:7 193.125.71.140, пустое)
        
        Гы... — AlexD   (01.08.2007 15:16:48 193.200.21.5, пустое, ссылка)
        
        Было бы все так, как пишут, давно все поголовно тулзы, жрущие немерено времени, были бы собраны с этим. Попробуйте найти например распараллеленный моделятор для HDL? Так ни модельсим, ни кэденс по крайней мере почему-то не умеют! — SM   (01.08.2007 15:19:29 85.21.237.237, пустое)
        
        хто сказал что не умеет? у каденса есть некие вычислительные кластера (географически ближайший в Лондоне), которые они за денежку сдают HDL моделировщикам — yes   (01.08.2007 15:46:16 87.236.81.130, 217 байт)
        
        Не, ну я не про то, я чтоб для дома, для семьи :) :) — SM   (01.08.2007 16:01:9 85.21.237.237, пустое)
        
        А кто сказал, что будет лехко? :-) — AlexD   (01.08.2007 15:25:23 193.200.21.5, пустое)
        
        Честно говоря не видел. Тогда давным-давно бы все средства разработки ПЛИСов были бы разпараллеливаемыми. А стало это только появляться, да с большим трудом. — SM   (01.08.2007 15:05:49 85.21.237.237, пустое)