Рассказ _adept_'a о ICFPC-2006

Набрел в сети на отличный рассказ _adept_'а об участии его команды в этом международном конкурсе функциональных программистов. Если кто не читал - рекомендую, захватывающая вещь:) (Кстати, вчера начался ICFPC-2007)

Альтернативный HPC или новый PU

Уже несколько лет в сфере высокопроизводительных вычислений (HPC, High Perfomance Computing) не смолкают разговоры о реконфигурируемых вычислителях (RPU,reconfigurable processing unit) и об общецелевых вычислениях на граф.процессорах (GPGPU). И если о GPGPU говорят достаточно часто и много, то про RPU, вроде бы как известно поменьше. В журнале IT Business Edge появилась обзорная заметка о реконфигурируемых вычислениях (всего 7 абзацев). Вкратце идея RPU заключается в следующем: использование ПЛИС(FPGA) в качестве сопроцессоров. Т.е. к обычному CPU цепляются несколько ПЛИС и все это вместе называется реконфигурируемыми вычислениями. Почему "реконфигурируемыми" - дело в том, что ПЛИС позволяют изменять(говорят ещё перепрограммировать,перепрошивать, конфигурировать) свою структуру в процессе работы. Таким образом, мы можем во время работы нашего приложения специализировать ПЛИС-сопроцессоры для решения наших конкретных задач в данный момент времени. Всё это позволяет достигать значительного прироста производительности. (На некоторых узкоспециализированных задачах(поиск шаблонов в ДНК или задачи распознавания (кстати, тоже по сути дела поиск шаблонов)) RPU дают прирост производительности в 1000 раз по сравнению с вычислениями на обычных CPU). Необходимо конечно отметить, что программирование ПЛИС дело не простое и не каждую программу можно легко и просто заточить для исполнения на ПЛИС. В этой области активно используются такие языки параллельного программирования как VHDL и Verilog. В роли интерфейсов CPU <-> RPU(FPGA) могут выступать, в том числе Ethernet и PCI. Кроме того, сами ПЛИС за счет все той же перепрограммируемости позволяют разработчикам быстро создавать дешевые прототипы своих разработок и экспериментировать с ними (конечно, это требует определенных навыков и знаний, а под час и, если хотите, мастерства. собственно также как и везде).
В области GPGPU разработок (коими я сам практически не занимаюсь) мое внимание привлекла заметка в блоге John West-а (www.IncideHPC.com) о том, что NVidia создала плугин для MATLAB на базе своей CUDA SDK (фреймворк для программирования Nvidia-GPU на языке C). Этот плугин позволяет здорово ускорить процессы вычислений в среде MATLAB. Приводятся цифры - несколько дней моделирования однородных двумерных турбулентных потоков при разрешении 1024х1024 без CUDA и 4-е часа при её использовании. И это ещё не придел, заявляют представители NVidia.

Их меньше чем LISP-программистов!...

Их никто не видел и некоторые считают что их просто нет! Но они есть и они приближаются :) Кроме шуток - я говорю о программистах на языке Rebol. (Первой ассоциацией, возникшей у меня при прочтении названия этого языка было название другого языка - Refal. Подумалось даже, что программистов на Refalе может быть меньше, чем Rebol-программистов, но об этом как-нибудь в другой раз). Я совершенно случайно набрел на этот язык и был приятно удивлен -

1. Год создания: 1997
   
2. Парадигма программирования: мультипарадигменный
   
3. Специализация: клиент-серверное взаимодействие и распределенное хранение информации
   
4. Основан на таких языках как Lisp, Logo, Self, Forth - (это было для меня просто ударом - Лиспо-Форт, вещь очень сильная - достаточно почитать посты русских лисперов-хаскеллистов или фортисов - первые ловко моделируют микропроцессорную технику и играючи расправляются с теорией категорий, монадами и системами типов, вторые используют язык, который легко заменяет ASM и C в микроконтроллерах(sic!) и создают аппаратную реализацию ФОРТ-процессора на ПЛИС). Про Logo и Self скажу только, что первый - дедушка языков программирования, каких свет не видовал, а второй основан на одной из не очень известных ООП-идей - на прототипах.
   
5. Цитата от автора языка - Карла Сасенрата(Carl Sassenrath)
   
   

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

   
   
   
6. Run-time: 1 exe файл - 300kB (+650kB кросс-платфоременный GUI)
   
7. Далее коротко по пунктам в wiki или на офф.сайте.
   

Сообщество русских Rebol программистов составляет, по мнению его членов - 50 программистов.
Думаю интерес этот язык может вызвать не только у любителей "альтернативных" языков программирования, но и у тех кто занимается распределенной обработкой данных - например, мне до сегодняшнего дня было не известно о существовании языковых средств, специализирующихся на решении этой задачи.

Масштаб

Масштаб - это когда для того чтобы определить есть ли у фотона заряд [или это электрически нейтральная частица] нужно построить радиотелескоп диаметром больше диаметра Земли. Брет Алтшуль построил и теперь он знает - заряда у фотона нет!

Продолжим космическую тематику - известно, что после нахождения в невесомости на протяжении 6 месяцев мышцы даже подготовленного космонавта начинаю атрофироваться, даже несмотря на занятия на разнообразных тренажерах и т.п. Полет до Марса занимает 30 месяцев - как вы понимаете, если покорители Марса вернуться на Землю, то они в лучшем случае проведут остаток своих дней в инвалидных колясках... но зато они побывают на Марсе...
Но не все так печально, как заявили представители NASA вчера им удалось разработать имплантант для человеческого мозга, который влияя на определенные участки серого вещества космонавтов заставляет их ощущать силу тяжести. Такие имплантанты создавались и ранее (были даже проведены серии экспериментов над улитками (ссылка в тему)). Насовские имплантанты сделаны на основе нанотрубок и представляют собой электроды. Электроды уже с давних пор используются для стимуляции нервной системы (или её разрушения), однако по заявлению Джун Ли(Jun Li), ученого из NASA, основным недостатком обычных металлических электродов является их планарность и большой размер - человеческий мозг и его сеть нейронов отторгают, по словам Ли, такие электроды. Нанотрубные же электроды, которые сделаны в NASA имеют гораздо меньшие размеры (сравнимые с размерами нейронов) и трехмерную структуру.

Источники - Элементы, EETimes

Небольшой обзор по Искусственному интеллекту

[(disclaimer) | Данный обзор не является сколько-нибудь полным и отражает виденье автором ситуации на данный момент]

Видимо неделя такая - меня тянет выплеснуть накопившуюся информацию по разным темам... В этот раз увидел вопрос "есть ли чего новенького в области ИИ" и не смог удержаться :) Надеюсь покажется интересным:

---

Srv:Нашел лекции по ИИ годов 97-99, книги... ну вроде как понятно, что это .. там еще про сети есть... интересно его как-нибудь применяют сегодня, кроме как для полетов на Марс и интеллект противника в игре и т.д.?

Безусловно:

советую прочитать это
http://www.raai.org/about/persons/osipov/pages/ai/ai.html
Автор этой работы - Осипов Г.С. - читал у нас лекции в этом году, поэтому могу сказать, что он "в теме" и информация по ссылке достаточно актуальная. Там не только про применения, но и обзор состояния области ИИ на сегодняшний день. Только необходимо понимать, что ИИ — это экспериментальная наука, занимающаяся решением проблем, для которых отсутствует (принципиально или практически) алгоритм решения. Не больше, но и не меньше. (Он нам на лекции так и сказал — "Протезы мозга это не к нам" :) )

Сам сайт www.raai.org - сайт Российской ассоциации искусственного интеллекта, Осипов её возглавляет.

Из реальных, практических применений:

1. Автономные транспортные средства (проект DARPA Grand Challenge)
   
2. Автономные подводные транспортные средства (пример)
   
3. Беспилотные вертолеты и самолеты (WITAS,DCOPE)
   
4. Интеллектуальные агенты космического назначения (например, известный DEEP SPACE ONE)
   
5. Диалоговые мобильные роботы (ну это у японцев посмотрите собачки ("АйБо") всякие и т.д.| Роботы футболисты и прочие участники ежегодных соревнований RoboCup) Есть и интересные "креативные проект", например AUR (робот лампа)) Или использование роботов-саперов военным в Ираке.
   
6. Поиск значения и смысла (извлечение информации из текста и семантический поиск, например Российская поисковая система Exactus(по ссылке действующий прототип системы и описание)). Или, например, сайт ежегодного семинара и соревнований по вопросам поиска (в том числе семантического).
   
7. Точно забыл ещё чего-нибудь

А уж если начнете гуглить, то усё капут вам без семантического поиска и извлечения информации из дебрей современных ИИ-проектов :) Причем разумеется все эти проекты комплексные — тут и моделирование (кстати вот Intel, тоже решил заняться RMS-системами (Recognition, Minig, Synthesis)), и встроенные системы, и кластера, и лингвистика и психология, механика, электроника...

Закон Мура помер - да здравствует закон Мура!

Когда разговор заходит о параллельном программировании частенько можно слышать такие фразы как -

Нам нужно параллельное программирование, потому что закон Мура больше не действует!
Закон Мура прекращает свое существование - халява кончилась!
Производители процессоров достигли предела тактовой частоты и закон Мура вскоре перестанет быть актуальным!

Не правда ли? (если честно, я и сам частенько грешу подобными заявлениями).
Однако, на самом деле, все эти заявления не верны - закон Мура продолжает работать - и конца и края, как говорится, этому не видно.
Дело в том, что обычно считается, что закон Мура звучит так:

Тактовая частота процессоров будет удваиваться каждые 24 месяца.
(The clock speed of chips doubles every 24 month. )

или так

Производительность процессоров удваивается каждые 2 года.
(The computing power of chips doubles every 24 month. )

Но на самом деле, если мы прочитаем статью Гордона Мура (которая кстати находится в музее выч.технологий Интел - а именно здесь), то мы увидим, что правильная формулировка закона Мура такова:

Плотность транзисторов в процессоре удваивается каждые 24 месяца.
(The density of transistors on chips doubles every 24 month.)

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

p.s.
закон Мура перестанет действовать когда в процессорах не будет транзисторов - например их нет в квантовом компьютере ;)

Источник - Thinking Parallel

Небольшой обзор по параллелизму (в России)

[(disclaimer) | Данный обзор не является сколько-нибудь полным и отражает виденье автором ситуации на данный момент]

На Realcoding.ner в комментариях к моему переводу статьи Саттера появлился такой вопрос

Nuzhny: Насколько я понял, ты серьёзно этим занимаешься. Видел несколько твоих тематических переводов на rsdn'е. Интересно было бы узнать, насколько близки работы мировых разработчиков и разработчиков с того же parallel.ru.

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

---

Nuzhny: Насколько я понял, ты серьёзно этим занимаешься. Видел несколько твоих тематических переводов на rsdn'е. Интересно было бы узнать, насколько близки работы мировых разработчиков и разработчиков с того же parallel.ru.

За весь Parallel.ru я не скажу, а как пример близости технологий, разработанных у нас и на западе, могу привести язык MC# (проект в котором сейчас работаю).
Язык базируется на C#. В основе модели MC# положено Join-исчисление (которое на западе было реализовано в JoCaml, MS Research Polyphonic C#(который стал частью MS C_omega), и в Nemerle на макросах).
Run-time языка MC# основан на .NET FW(\Mono). В определенном смысле MC# - развитие майкрософтовского Polyphonic C# на случай как локальных, так и распределенных вычислений. Так что в этом смысле работа находится в русле (в мейнстриме :)).
К тем категориям, которые выделили Callahan\Sutter можно добавить ещё рад столпов, которые лежат в другой, ортогональной столпам Каллахана плоскости. Это:

1. Встроенные системы (нпр., DSP\ПЛИС\FPGA)
   
2. Многоядерные ПК\Суперкомпьютеры (точка соприкосновения с Callahan\Sutter и Воеводиным)
   
3. Кластера\GRID-системы
   

Очевидно, что эти столпы также являются категориями параллелизма, как и столпы Каллахана.

В области встроенных систем у нас есть успехи, например - НТЦ Модуль _ разработал собственный DSP процессор и совместно с Samsung-ом запустил его производство. Процессор может быть использован и для параллельных вычислений, только параллелизм там основан нейронных сетях. (по крайней мере, такие заявления делались при анонсировании НТЦ Модуль технологии NeuroMatrix)
Или даже вот этот пример ("народная" разработка Форт(Forth) процессора на ПЛИС) показателен.

Нельзя не сказать также о GPGPU технологиях,..., хотя видимо можно и не сказать, поскольку в России насколько я знаю, нет проектов подобных MS Research Accelerator GPGPU (исполнение managed-программ на процессорах графической карточки). Недавно (месяца 4 назад) мой науч.руководитель был на конференции в Москве (к сожалению, название забыл, возможно, DSPA 2007), рассказывал, что там ребята из МГУ делали презентацию нейросети на базе GPGPU, так что скорей всего российские GPGPU проекты есть, просто они не известны мне. (Вспомнилось, кстати, что Тони Хоар заканчивал МГУ, так что у нас в России база для параллелизма оч.хорошая :)

Вообще сейчас все труднее и труднее делить разработки на наши и "ихние", вот например, такие продукты Intel VTune\ThreadAssistant\ и п.р., которые, безусловно, имеют прямое отношение к параллелизму (многопоточности), разрабатываются в центре Intel в Нижнем Новгороде нашими программистами. Есть, разумеется, и сугубо наши, российские разработки - например, алгоритмы параллельных подстановок(это из области мелкозернистый параллелизм(Fine-grained parallelism), нечто близкое к клеточным автоматам), над проблемами которых в частности работает О.И.Бандман в Новосибирском научном городке.

На западе понятно дело куча(кучища!) проектов, посвященных параллелизму, меня заинтересовал проект Ptolemy (университет Беркли, один из авторов - Эдвард Ли) - среда моделирования разнообразных моделей параллельных вычислений. У нас, к сожалению, насколько я знаю таких проектов нет, а ведь именно моделирование и рассмотрение применимости разнообразных моделей вычислений, позволило бы создавать как удачные языки параллельного программирования, базирующиеся на той или иной модели, так и технологии вообщем. Сейчас же отсутствует даже классификация моделей параллельного программирования, что показывает незрелость ещё пока, не системность данной области, имхо.

Столпы параллелизма. Herb Sutter on Dr. Dobb's Journal

Herb Sutter начал вести колонку по параллельному программированию в журнале Dr.Dobb's. Закончил перевод его первой обзорной и в тоже время достаточно конкретной статьи - здесь. От комментариев пока воздержусь, но было интересно :)

AUR - The Confessor | Когда роботы как люди 2

В то время как Аккела объявляет тендер на создание MMORPG (которая станет центром целого онлайного мирка с сопутствующими сервисами), пока ученые Института Крейга Вентера проводят первую в мире успешную пересадку генома одной бактерии другой (что позволяет полностью передать свойства вида первой бактерии второй), пока Нидерландские умы заняты повышением в 100 раз скорости чтения\записи наших с вами винчестеров, Guy Hoffman из MIT Media Lab создал себе нового друга - робота настольную лампу. Да, да, да об этом уже писали много и часто (вот, например, тут, тут, и тут). Широко известными фактами является то, что эта лампа способна отслеживать движения человека и освещать тот участок пространства, с которым человек непосредственно взаимодействует, а также то, что она способна отыскивать предметы по просьбе человека и фокусировать на находке узкий пучок света. Видео работы смотрите здесь. Ниже даны несколько кадров:









Скетчи и чертежи лампы Гай приводит на своем сайте.

















Только посмотрите на эту механику!, чем-то напоминает работы Леонардо да Винчи. Впрочем почти обо всём этом вы можете почитать в обзорах робототехнического
рунета (ссылки выше).

---

THE CONFESSOR | Робот на сцене

Я хочу обратить Ваше внимание на другой аспект этой работы - спектакль "The Confessor"("Исповедник") в котором Лампа (или AUR, как называет своего робота сам Хоффман) играет одну из главных ролей. Автор спектакля - Rony Kubat из MIT Dramashop's Playwrights in Performance, режиссер - Kate Snodgrass. Запись генеральной репетиции спектакля здесь(!~12MB, посмотрите, оно того стоит). Рони Кубат постарался создать свое произведение именно с учетом робота в главной роли. Другой менее известной работой Рони и AUR является пьеса "Talking to Vegetables" ("Ведя беседу с овощами").
Эта работа ведется Гаем Хоффман в рамках исследований по человеко-робототехническому взаимодействию (Human-Robot Interaction, wiki, pdf(100kb)). По сути дела такие проекты сейчас уже не новость, ведь если человек собирается жить с роботами рука об руку через каких-то 5-7 лет, то лучше подготовиться к этой встрече заранее.

p.s.
Помните мультик от Pixar про ламп-футболистов, или даже собственно сам логотип Pixar - настольная лампа, думаю определенные параллели тут можно провести...и так думаю нетолько я.

Погодная станция «Кристалл». Изящество практичности

Сегодня рассказали про интересный гаджет от Oregon Scientific - это часы + погодная станция + внутренний термометр.

Вот несколько фотоk для затравки:


Красота! :)

Подробный обзор здесь.
Источник - www.mobile-review.com

RoboCup 2007

C 1 по 10 июля этого года в Атланте пройдет очередной чемпионат роботов RoboCup 2007. В этом году на ряду с роботами футболистами, роботами спасателями и домашними роботами будут выступать роботы размер которых исчисляется микрометрами.
Интересно, что как замечают сами устроители выставки, все большую и большую роль в усепшном поведении роботов играет не механика и не электроника, а программные мозги роботов. Подчеркивается, что некоторые команды вообще практически не меняют аппаратную начинку своих железных друзей, совершенствуя лишь ПО.

Как уже отмечалось выше изюминкой данного чемпионата в этом году станут роботы размером в несколько микрон. Интересно, что эти роботы были произведены по технологии MEMS(wiki), эта же технология легла в основу ранее описанного микро пьезогенератора.
По сути дела MEMS это часть того что у нас называют нанотехнологиями. MEMS - интеграция продуктов механики и электроники на кристалле размеры, которого имеют порядок 10-6 метра и выше (т.е. до "нано" не дотягивает). Наиболее широко MEMS применяется при производстве сенсоров. Пример такого MEMS-робота вы можете видеть на рисунке (с ним рядом пристроилось какое-то насекомое, комар, вроде бы :) ) Примеры других микророботов показаны здесь.
Полный список стран участников представлен здесь. Присутствуют команды из Ирана, Чили, Китая..., обидно - наших нет. Насколько я понимаю некоторым аналогом RoboCup в России является фестиваль "Мобильные роботы", проводимый МГУ.

"Виброток"

Нидерландское подразделение Holst Centre европейского исследовательского центра IMEC уже давно известно своими перспективными разработками (или как сейчас модно говорить, инновационными разработками) в области микроэлектроники. Интересно, что Holst Centre удается настолько верно предугадать направление развития области на год или два вперед, что её разработки практически всегда находят коммерческое применение.
В этот раз IMEC Holst Centre разработал источники питания на пьезоэлементах - переменный ток продуцируется на основе вибраций окружающей среды.

Пьезоэлектричество известно уже достаточно давно, однако для его успешного применения требуется преодолеть ряд проблем (в частности проблему резонанса пьезоэлемента - в момент резонанса продуцируемая мощность возрастает в 200 раз), что и было успешно сделано в Нидерландах. Тем более интересно, как точно была выбрана область применения для разработанного источника питания - питание беспроводных микродатчиков. Примерами таких датчиков могут служить сенсоры в крадиостимуляторах, авиационных двигателях, а также других встроенных системах малого масштаба.
Новый источник питания продуцирует мощность в 40 микроватт при частоте 1.8 КГц, что вполне достаточно для питания беспроводных сенсоров. Интересно, что общим направлением исследований IMEC Holst Centre является создание электрогенераторов превращающих градиент окр.среды любой физической природы в электрический ток.

Такие элементы питания, как собственно уже разработанный пьезоэлектрический элемент позволят целому классу систем обходится без батареек и аккумуляторов, что скажем в случае кардиостимуляторов очень важно.
Источник - EETimes

Intel. Блог новый, проблемы теже

В семействе блогов Intel пополнение - появился новый блог http://blogs.intel.com/research/. Новый блог наряду с ISN blog(Intel Software Network) создает хорошее с точки зрения программиста впечатление о компании... не такое hardware-ное что ли :)

И что же вы думали, в одном из первых сообщений этого блога вновь поднимается проблема распространения многоядерных процессоров и слабой поддержки их со стороны программистов.
Я имею ввиду заметку Али-Реза Адл-Табатабаи (Ali-Reza Adl-Tabatabai,Senior Principal Engineer in Intel’s Programming Systems Lab), которая так и называется - "Многоядерные процессоры: переломный момент для программирования". Думаю ничего нового читатели моего блога в этом сообщении не найдут - почти все сообщения от разнообразных авторов и мои собственные замечания посвящены этой теме. Поэтому тезисно -

1. Раньше программист писал программу, а каждые 18 месяцев она работала почти вдвое быстрее (закон Мура). Больше такого не будет. Грубо говоря, если программист хочет, чтобы его программа работала быстрее на новом процессоре, то он должен разрабатывать её в параллельном (и масштабируемом) стиле.
   
   
2. Современные языки программирования для решения задачи 1 не годятся. Они позволяют лишь использовать многопоточные библиотеки. Потоки по сути дела являются современными аналогами "goto".
   
   
3. Для решения задачи 1 нужны высокоуровневые языки программирования с поддержкой параллелизма.
   
   
4. И главное - скорей всего придется ломать мозги программистам, поскольку и с точки зрения современной теории, образования и с точки зрения современной практики, параллельное программирование развито не очень хорошо.
   

Продолжает эту тему пост Тимоти Маттсона(Timothy Mattson), озаглавленный как "Параллельные вычисления: сделаем последовательное ПО исчезающей редкостью". Маттсона, которому по работе приходится встречаться с различными группами разработчиков, занимающихся вопросами параллельного программирования, раздражает, что с аппаратчиками он может обсуждать конкретные проекты и понятные четко определенные, практические проблемы. Он говорит, что они буквально смакуют решения тех или иных проблем (we are sweating the details). Когда же он работает с программистами, то все тухло... Вместо конкретики они вынуждены барахтаться в хаосе. Причинами такого положения дел по мнению Маттсона являются следующие нерешенные вопросы:

1. Нужны ли новые языки программирования? Или достаточно каким-то образом расширить существующие языки?
   [от себя добавлю, что, например, Эдвард Ли предлагает альтернативное этим двум подходам решение - создание нового языка программирования, который бы не заменял старые языки, распространенные сейчас, а был бы ортогонален им. Такой язык не был бы универсальным, а наоборот был призван дополнить существующий язык, оставаясь независимым от него, подробнее здесь, стр 14.]
   
   
2. Способны ли языки, с поддержкой распараллеливания по данным (data parallel programming languages) удовлетворить потребности прикладных программистов? Удобны ли и понятны ли такие языки прикладных программистам, или же для них это очередной HPF (High Performance Fortran)?
   
   
3. Любой масштабируемый параллельный код основан на посылке сообщений... или на общей памяти с которой работают в стиле посылки сообщений. Можем ли мы сделать посылку сообщений частью мейнстрима? Или же это слишком сложно для не HPC-программистов (HPC-High Performance Computing)?
   
   
4. Фреймворки подобные Visual Basic значительно упростили создание прикладного ПО. Может ли мы использовать подобный, framework-based подход в параллельном программировании?
   
   
5. Каким образом мы можем научить программистов "думать параллельно", решать задачи в параллельном стиле?
   

PRAM. Немного подробностей

На этой, уже подходящей к концу, неделе про многоядерность и параллельное программирование говорили часто и много (не все к сожалению удалось осветить в блоге). Тем кого заинтересовало сообщение о "многопроцессорном чуде" из Мирланда советую прочитать комментарий Clay Breshears на ISN. В кратце он критически оценивает подход Узи Вишкина к параллельному программированию. Как мы уже знаем, Узи большой поклонник PRAM-подхода. В дополнении к статье на Вики, Clay Breshears отлично объясняет сущность PRAM - по сути PRAM это абстракция, которую в нашей литературе называют концепцией неограниченного параллелизма. Концепция родилась на заре суперкомпьютеров и смысл её предельно прост - будем рассматривать параллельную машину как систему с неограниченным множеством процессоров, каждый элемент которого подсоединен к RAM памяти с бесконечно малым временем доступа. Между RAM и процессорами находятся модули контроля доступа (memory access unit (MAU)). Эти модули "рулят" операциями чтения(Read(R)) и записи(Write(W)) - в зависимости от типа MAU разрешает(Concurrent(C)) или запрещает(Exclusive(E)) параллельное выполнение чтения\записи. Соответственно мы имеем 4 типа MAU. До недавнего времени PRAM оставался лишь концепцией, но усилиями Узи Вишкина PRAM обрел форму языка программирования (XMT-С). Фишка, как говорится в том, что в PRAM синхронизация (или точнее то, что в многопоточном программировании называется потокобезопасностью) возлагается на программиста - скажем если мы используем CREW-MAU (Concurrent Reading Exclusive Writing), то программист должен таким образом составить алгоритм, что уж если алгоритм выполняет параллельную запись в память, то запись эта должна вестись по разным адресам(в разные ячейки памяти). Выглядит страннова-то. Чтобы не показалось, что PRAM это совсем оторванная от жизни модель, отмечу, что разумный подход к PRAM предполагает составление библиотек таких распараллельных алгоритмов и их последующее использование, т.е. в этом плане PRAM ближе к OpenMP\IntelTBB, а не скажем к акторной модели параллелизма или ещё какой-либо модели параллельного программирования, целью которой является взаимодействие\интерактивность\повышение пропускной способности системы, а не пиковая производительность.
Более подробно о PRAM вы можете прочесть в статье Узи Вишкина и в уже упомянутой заметке Clay Breshears.

Куда-катиться-мир ?!

1. Глобальный форум от Гугл - "Вопросы и ответы"

2. Создатели фильма "Великие Тайны Воды" (помните по ОРТ шел одно время) создают фильм о Дарвине в том же стиле... - открытое письмо Александра Макарова.

Мне лично по душе прищлось это:

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

Он обратил внимание на то, что в наши дни, к сожалению, вышли из моды две старые, банальные идеи: 1) Истина существует, и целью науки является ее поиск; 2) В любом обсуждаемом вопросе профессионал в нормальном случае более прав, чем дилетант. Им сегодня противостоят новые, гораздо более модные положения: 1) Истины нет, есть множество мнений; 2) Ничье мнение не весит больше, чем мнение кого-то иного. «Девочка-пятиклассница имеет мнение, что Дарвин неправ, и хороший тон состоит в том, чтобы подавать этот факт как серьезный вызов биологической науке»

Многоядерность. Несколько событий в области

Несколько не особо связанных событий, на которые тем не менее хотелось обратить внимание:

1. Свершилось: Intel начинает глобальную обучающую программу, призванную научить-таки программистов многопоточному программированию для многоядерных компьютеров. О недостатках этого подхода достаточно много и понятно говорит Эдвард Ли. Например, здесь.

2. Студенты университета Мериленд(США,Maryland) возглавляемые профессором Узи Вишкиным(Uzi Vishkin) создали прототип материнской платы для поддержки множества процессоров, суммарная производительность которых будет эквивалентна 64 ядерному процессору. Технических подробностей данной системы не приводится. Что ещё больше заинтриговало специалистов в области параллельного программирования. В частности Clay Breshears (Intel) в очередной раз поднимает вопрос о том, что если уж студенты способны создать такой вычислительный агрегат, то значит основные проблемы в будущем будут лежать не в области аппаратного обеспечивания(проектирования микропроцессоров), а в области параллельного программирования. Как пишет Lorin Hochstein (магистр из университета Мериленд) Узи Вишкин ярый поборник модели параллельного программирования PRAM, под его руководством был даже создан диалект С для PRAM-машины. И созданный в Мериленде прототип процессора явлется частью PRAM-исследований Вишкина.

Источники - InsideHPC, Clay Breshears ISN Blog

Встроенная многоядерность и кубик Рубика

Производители встроенных систем (и специализированных процессоров (DSP, коммуникационные, мультимедийные процессоры и т.д.) больше не могут наращивать тактовую частоту своих выч.устройств из-за все тех же проблем с выделяемой мощностью и энергопотреблением. Поэтому они решили пойти по проторенной дорожке и наращивать производительность за счет многоядерности. Собственно логичное развитие событий, просто не где не встречал документального подтверждения такого положения дел, а тут как раз появился обзор на EETimes.
Зачем наращивать выч.мощность? Ученые из Северо восточного университета США наглядно продемонстрировали ответ на этот вопрос: Производительность нужна для того чтобы доказать, что кубик Рубика можно собрать за 26 шагов, а не за 27(как было доказано в 1997 году). Для решения этой задачи, кубик-рубикистам потребовалось 128 процессоров, 20 терабайтов дискового пространства и 7 терабайтов оперативной памяти. На решение задачи было потрачено 8000 часов процессорного времени и 200.000 зеленых долларов США.
Источник - Clay Breshears's ISN Blog

Про языки программирования и их создание

В достаточно, надеюсь, известной статье "A view from Berkeley", в которой приводится обзор современного состояния и проблем параллельного программирования, выдвигается гипотеза, что при создании новых языков и моделей программирования мы в первую очередь должны руководствоваться не математическими абстракциями (машина Тьюринга, лямба Черча) и не эффективностью аппаратного исполнения той или иной конструкции языка, а результатами исследований в области психологии. Только простой и интуитивно понятный (надежный, если хотите) язык параллельного программирования будет инструментом, с помощью которого программист сможет обуздать параллелизм. Видимо эти же идеи подтолкнули Marc Ordinas к написанию своей статьи Programming language interaction (в принципе ничего нового, но может показаться интересным), а okante к созданию языка Д.

И ещё на закуску-
Заметка про первый в мире язык программирования - небольшой пост про язык Plankalkül. Источник - Алена С++.

Рефакторинг Линукса ради энергосбережения

Следуя общей тенденции энергосбережения и снижения потребляемой мощности, разработчики Linux модернизируют ядро этой операционной системы. Собственно очевидно, что снижение энергопотребления является конкурентным преимуществом как для серверных систем (ибо сервера работают 24х7 и даже незначительное снижение потребления электроэнергии экономически выгодно), так и для встроенных систем (меньше потребляем - дольше работаем). По словам Линуса Торвальдса основные изменения в Linux уже проведены, остались незначительные доработки. Одним из методов снижения энергопотребления вычислительной системы является устранение её тактируемости (tickless) и именно этот метод будет применен в случае Linux.

Источник - ZDNet

Пентагон покидает OnLine

Непрекращающиеся хакерские атаки вынудили Пентагон и Министерство Обороны США отключить 1500 Пентагонских ПК от Интернета. В этот четверг Роберт Гейтс (МО США) заявил, что email серверы Пентагона подверглись атаке и некоторые элементы "email-системы Пентагона" были выведены из строя. Разумеется самоизоляция Пентагона от Интернета продлится совсем не долго, а лучшие умы Америки уже ведут борьбу с этими дерзкими хакерами... бла-бла-бла :). Кстати сам Р.Гейтс email'ом не пользуется и вообще старается держаться по дальше от всех этих high-end технологических штуковин.

Источник - EETimes

Вейвлеты и их приложения. Обзор

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

Ужасный Google или Непростое поглощение PeakStream

Не так давно мы уже писали о том, что Google приобрел PeakStream, несколько заметок по этому поводу появилось и в российской web-периодике - здесь и здесь. Теперь же хочется представить вашему вниманию альтернативный взгляд на это событие от западного аналитика Эшли Ванса.

---

Кому нужны нефть и газ, когда есть google-ads?

Дерзкое, если не сказать эксцентричное, поглощение стратапа PeakStream компанией Google должно было напугать основных участников микропроцессорного рынка, производителей серверов и прочего железа. Google, занимающаяся прежде всего рекламой, сожрала ценную компанию, продукты которой имели потенциально большую важность для ИТ-индустрии в целом. При этом целью пожирателя было простое удовлетворение собственных потребностей и ничто иное. В результате был нанесен существенный урон, я бы даже сказал, удар по разработчикам высокотехнологичных серверных приложений, последствия которого ещё только предстоит пожинать в течение нескольких следующих лет.

Мы уверены, что такие поглощения будут продолжаться и дальше, если индустрия будет столь недальновидна. Стратап PeakStream, существующий на рынке около 2 лет, занимался разработкой инструментов, облегчающих распараллеливание однопоточных приложений на многоядерных x86 процессорах Intel и AMD, а в будущем и на GPGPU() карточках от Nvidia и AMD\ATI.

Защитники PeakStream’a и его технологий, а также технологий, которые разрабатываются сейчас пока ещё независимой компанией RapidMind, говорят об этих компаниях как об ангелах воплоти, которые уберегали программистов от жесткого ручного хардкодинга многопоточных моделей. Критики же такого подхода говорят о том, что такие технологии по сути дела являются морфием для программистов, что они реально не решают стоящих перед ИТ-сообществом проблем и что такая халява все равно долго не продержится.

Согласно нашим данным, на протяжении двух последних месяцев PeakStream вела активные переговоры о поглощении с несколькими крупными игроками ИТ-рынка. Мы не можем назвать полный перечень этих компаний, но разумно предположить, что в этот список вошли Intel, AMD, Nvidia, Sun Microsystems, IBM, HP и Microsoft. Неправда ли, именно производители ПО и микропроцессоров выглядят наиболее подходящими кандидатами на заключении такой сделки, поскольку они могли обеспечить значительную поддержку инструментам PeakStream’a и как следствие оказать благотворное влияние на индустрию в целом.

Вместо этого инженеры PeakStream’a отправились оказывать благотворное влияние на Google.

Недавно из достоверных источников нам стало изветсно, что Google не собирается заниматься распространением и продажей инструментов, разработанных PeakStream. Причина, думаю, вам понятна – основной бизнес Google сосредоточен в области рекламы и поисковых сервисов.

Вдобавок ходят слухи, что развитие GPGPU технологий не интересует Google, а ведь именно GPGPU инструментарий был изюминкой PeakStream. Вместо этого компания, съевшая талантливых параллельных программистов, собирается пустить их в оборот при разработке многопоточного кода для x86 процессоров.

Нам удалось проследить судьбу некоторых из бывших пикстримщиков, которые теперь работают в Google. Один из них также как и раньше работает над JIT’ом для многоядерных процессоров. Другой работает над компилятором для x86 платформы, а ещё один переключился на алгоритмы генерации случайных чисел с использованием GPU и CPU с упором на HPC(high performance computing) область.
Приобретение Googl’ом этих талантливых инженеров – это ещё один пример хитрого шага этой умной компании, которая все больше и больше обгоняет Yahoo! и Microsoft. Нет, ну вы можете всерьез представить, что Yahoo! или Microsoft будут приобретать компанию, наподобие PeakStream, для того чтобы улучшить свои поисковые сервисы или лежащие в их основе файловые системы. Вряд ли мы когда-либо станем свидетелями столь удивительных событий.

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

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

И вот теперь Google запросто покупает недешевую PeakStream как будто бы просто потому, что пикстримщики могут ей пригодиться. Такая покупка про запас. Если бы у Google было столько денег лет пять назад, то вполне возможно, что VMware стала бы просто одной из примочек к Goobuntu, к счастью этого не случилось и сейчас VMware по сути дела дефакто одна из самых применяемых на практике систем виртуализации. И кто знает, может быть в следующем году Google захочется купить Sun, чтобы заполучить нескольких талантливых Java программистов или заграбастать Red Hat, для того чтобы Linux в Google работал получше, да постабильнее.

Вообщем если нас послушать, то покупка PeakStream’a совсем не рядовое поглощение, однако с другой стороны теперь на рынке осталась всего лишь одна компания подобного профиля(single-threaded-to-multi-threaded code) - RapidMind.

Думается, что производителям серверов больше бы понравилось, если бы в этом сегменте рынка была хоть какая-нибудь конкуренция. Она, как известно, всегда способствует прогрессу, а именно этого сейчас так не хватает в нише инструментов для «упрощенного» параллельного программирования. Если бы PeakStream остался в живых, то года через два мы вполне бы могли наблюдать кучу HPC приложений, заточенных под GPGPU или многоядерные процессоры. Это позволило бы находить больше нефти и газа, создавать более безопасные автомобили, в конце концов, это сказалось бы и на наших с вами бюджетах тоже.

Вместо этого производители серверов вынуждены молиться на RapidMind, которой предстоит в одиночку решить все эти сложные проблемы, если конечно её не купит ещё какой-нибудь Google. И тогда уж точно в пору будет создавать супер-пупер машину, которая будет денно и нощно обучать программистов практике параллельного программирования.

Если же вы думаете, что все это пустой треп, то просто сохраните эту заметку и вернитесь к ней, когда вы будете платить по 10 баксов за литр бензина в 2009 году, просто потому что Exxon не смогла обнаружить новые запасы нефти. Вы припомните мои слова, когда будете болезненно хихикать, глядя на кучу бесполезных графических карточек, валяющихся без дела в углу вашего офиса.

Что ж можете и дальше наслаждаться быстрым поиском от Google, не думаю, правда, что это вам поможет.

Источник - The Register

Наши на WTF

Надеюсь многие из вас читают WTF (Worse Than Failure или в другом прочтении What's the F*ck). Для тех кто по каким-то непостижимым причинам этого не делает предлагаю обратить внимание на перевод этой статьи. Автор Алекс Пападимулис, перевод от замечательного переводчика Евгения Виговского.

C# на Linux и не Mono!

Сегодня компания Mainsoft анонсировала релиз своего продукта Mainsoft for Java EE 2.0 (раньше он назывался Visual MainWin for J2EE). Этот инструмент (а по сути кросскомпилятор) позволяет создавать приложения на C# и Visual Basic, компилировать их под JVM и запускать на Linux. В принципе мы и раньше могли запускать .NET приложения на Linux с помощью Mono, однако теперь за дело взялся и Mainsoft. Без помощи Mono-вцев тут правда не обошлось...
Гарантируется поддержка .NET FW 2.0, ASP.NET 2.0, Microsoft's Visual Studio 2005 IDE.

Источник DDJ.com

Google купил Peakstream

На днях Google заявил о поглощении компании Peakstream. Стартап Peakstream занимался разработкой инструментария для параллельного (многопоточного) программирования. Аналитики склонны расценивать этот шаг Google как ещё один стимул к продвижению параллельного программирования в мейнстрим. О деталях и целях поглощения официальные лица Google ничего не сообщают. Интересный комментарий этой новости вы можете найти в блоге Джо Лендмана, известного вам по моим прошлым постам. Примечательной также является точка зрения Адама Беберга (тех.директор Mithral Communications & Design), который считает, что главной проблемой многоядерных процессоров станет низкий спрос на них со стороны основного покупательского сектора ПК (домашние пользователи). Беберг считает, что Intel с сотоварищами будет крайне сложно убедить пользователей в полезности многоядерности.

Источник - EETimes

Bots on The Ground | Когда роботы как люди

«Нашел мину – наступи на неё» - эффективные способы разминирования ©.

Результаты такого разминирования могут разочаровать некоторых из нас… Однако вместо человека на мину может наступить и робот, у которого ног будет больше чем у сороконожки. Оторванная нога у робота и одноногий человек разница более чем ощутима, не правда ли ?! Именно поэтому Марк Тилден, робототехник лаборатории Лос-Аламоса, сделал такого робота. После чего он провел серию испытаний своего многоногого
робота-сапера в Аризоне. Думаю, Вам будет интересно узнать - как это было.

Рассказывает Марк Тилден:

«Робот, полтора метра высотой, похожий на насекомое, отлично справился с работой в реальных условиях. Каждый раз, когда он находил и подрывал мину, он терял одну из своих ног, а затем старался перегруппироваться таки образом, чтобы доползти на оставшихся ногах до базы, оставляя при этом на земле дорожку, ведущую к взорванной мине. В конце концов, у него осталась всего одна нога, но он продолжал тащить свое тельце на базу. Это было восхитительно! Машина отлично работает.
Правда, полковник, наблюдавший за тестированием робота, приказал прекратить испытания. Я спросил его – «что случилось? Вроде бы все отлично работает…»
Оказалось, что полковник, военный, между прочим, человек не мог спокойно наблюдать за тем как робот, словно раненый солдат волочит свое истерзанное взрывами тело по земле и раз за разом отправляется на верную смерть. По его мнению, такие эксперименты бесчеловечны».

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

















Но что ещё более поражает, так это не технически разнообразные возможности роботов, а их влияние на своих хозяев… Под час солдаты награждают своих подопечных пурпурными сердцами или присваивают им очередное звание. «Мы называли его сержант Тейлон,» рассказывает Михаил Максон сержант 737 инженерной роты. «Мы всегда хотели, чтобы именно Тейлон сопровождал нас во время операции. Когда он был с нами –все шло отлично. Он всегда все здоровски делал. Несколько раз рядом с ним разрывались снаряды, а он все продолжал работать. Однажды, когда Тейлон зазбоил, его заменили каким-то другим роботом – этого новичка разнесло на кусочки в первую же операцию. Казалось, мы все предчувствовали, что без Тейлона произойдет что-то нехорошее». Солдаты присвоили Тейлону звание сержанта, это почетное звание, которые получают не все солдаты, ведь сержант обычно - лидер подразделения. Кроме того Тейлон был награжден тремя медалями «Пурпурное сердце».

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























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

В этот день в мастерскую Богоша заглянул солдат из EODa (саперы). Солдаты и их роботы из EOD занимаются уничтожением черной смерти иракских дорог – самодельных фугасов. Этот солдат держал в своих руках небольшую коробочку. Это было все что осталось от робота - робота, которого ребята называли Скуби-Ду (Scooby-Doo).

«От Скуби осталось действительно немного» - вспоминает Богош - «Лучше всего сохранилась голова робота – коробочка с камерой, примерно 6х6х8 см. С одной стороны этой коробочки виднелись надписи, нанесенные краской – солдаты записывали успешные миссии, выполненные Скуби. Видать, этот робот был действительно дорог для них». Было видно, что сапер, хозяин Скуби, был сильно расстроен. «Казалось он потерял лучшего друга», вспоминает механик - «он говорил, что ему не нужен новый робот - ему нужен его Скуби».

«Иногда они слишком привязываются к роботам, словно к собакам» - говорит Богош - «Видя как надежно роботы выполняют свою работу, как они идут на выполнение задания и как они возвращаются, солдаты постепенно начинают воспринимать их как часть команды. Почти всегда у робота есть имя, а когда с ним что-то случается вся команда переживает за его судьбу… Солдат чувствует, что он может положиться на робота, и это связывает их ещё крепче».
«К тому же каждый робот немного отличается от других роботов, в каждом из них есть что-то личностное, персональное… К примеру, любой робот ведет себя по своему, вы приноравливаетесь к его поведению, когда используете его. Иногда робот словно пританцовывает, когда что-то делает, иногда начнет выдавать такие выкрутасы, что по неволе задумываешься о его скверном характере». После выполнения задания операторы всегда делятся друг с другом впечатлениями о том, как их роботы выполняли то или иное задание… вы понимаете, они говорят, о том как роботы выполняли задания, никак оператор управлял роботом, а как сам робот что-то делал! Помниться был один случай, когда одному из роботов взрывом повредило гусеницу, дак солдат-оператор выполнил задание и после дотащил робота на себе, рискуя погибнуть вместе со своим железным другом. Это было возвращение героя…»
«Я не знаю, правда это или нет, но говорят, что неподалеку от нашего лагеря на реке Тигр, оператор часто выводил своего робота на рыбалку. Он усаживал робота с удочкой в тенечке, а сам уходил… правда, клева обычно в том месте не было…»

Продолжение следует…

Источник - Washington Post
Автор - Joel Garreau, Washington Post Staff Writer
Перевод мой.

.NET на микропроцессоре Blackfin

Сегодня Microsoft и компания Analog Device анонсировали версию .NET Micro Framework для процессоров Blackfin (AD). Теперь у разработчиков появился удобный каркас для разработки мультимедиа и прочих специализированных приложений. Более того, разрабатывая ПО для Blackfin программисты смогут использовать MS IDE Visual Studio.
Каркас .NET Micro Framework – это платформа, разработанная Майрософтом для устройств, базирующихся на 32-х разрядных процессорах, с учетом жестких требований к памяти, потребляемой мощности и прочих ресурсов. Процессоры Blackfin имеют как 16-и, так и 32-х разрядную архитектуру и, в том числе, предназначаются для управления обработкой мультимедиа данных в реальном времени.
Кроме полноценной интеграции с Visual Studio .NET Micro Framework поддерживает эмуляцию целевого устройства для тестирования разрабатываемой функциональности и отладки.
«Мы рады, что именно Blackfin стал первым DSP с .NET Micro Framework на борту, » заявил Джерри МакГуйер(Jerry McGuire), вице-президент General Purpose DSP Group компании Analog Device. «Мы уверены, что этот продукт поможет разработчикам в создании новых интересных приложений процессора Blackfin, эффективных как с точки зрения производительности, так и с точки зрения цены и потребляемой мощности. Для примера, скажу, что в рамках одного из наших проектов мы использовали Windows SideShow для отображения информации о настройках мобильных ПК и прочих портативных устройств, таких как плейры и т.д, даже когда эти устройства работали в «спящем» режиме».

Среди прочих достоинств Micro Framework можно подчеркнуть столь необычное для embedded-платформ наличие сборщика мусора и встроенной обработки исключений. Native-код будет по прежнему доступен с помощью Interop-механизмов.

Источник - Dr. Dobb's Portal

По пивку?

Уже давно в сети существуют разнообразные плугины (или гаджеты, кто как их называет), которые можно повесить на страничке своего блога и позволить своим читателям перечислить немного денег на счет владельца блога (это не намек!:)). Обычно эти плугины выглядели как кнопки с надписями типа "Поддержите нас!", "На хостинг", "На развитие сайта", и т.д. Но кто?, кто скажите мне будет отдавать свои кровные на развитие чужого сайта?! Теперь же любой может проявить свои компанейские, дружеские чувства, купив понравившемуся автору блога кружечку пивка. Именно такую услугу с недавних пор предоставлять сервис PayPal и плугин "Buy Me a Beer". Популярность этого плугина по мнению его автора очень высока.

Источник - Quick Online Tips

Google+Параллелизм: экспансия продолжается

2 дня назад на Thinking Parallel появилась занятная статья - "How Much of the Industry Will Go Parallel?" - "Насколько параллелизм востребован IT-индустрией сегодня ?", в которой Michael Suess высказывает свои предположения по этому поводу. Нужно сказать, что Michael Suess вообще достаточно интересная личность, и с точки зрения параллельного программирования тоже ;) (особенно мне ценен его цикл интервью, ru: здесь и здесь). Дак вот Михаил считает, что параллельное программирование будет интересно прежде всего двум группам разработчиков. К первой группе относятся те, кто вечно борется с нехваткой ресурсов и производительности - это все возможные разработчики игр, систем моделирования, систем обработки сигналов и информации. Ко второй же ещё более малочисленной на сегодняшний день группе относятся разработчики, которые захотят использовать многоядерный параллелизм для придания своим приложениям большей интерактивности и других(не известных на сегодняшний день) преимуществ и фишек. Среди прочих Михаил приводит такой пример - вы ведете конференцию по ICQ\Skype, а параллельно с этим сторонняя утилита распознает некоторые ключевые слова в вашем диалоге и подыскивает информацию, которая может потенциально вас заинтересовать... скажем вы часто говорите про параллельное программирование - вот вам свежая подборка с тематических новостных сайтов и блогов, обсуждаете девушек - вот вам... ну вообще додумаете сами).

---

И все бы, как говориться, ничего, но вот только сегодня получаю подтверждение, что параллелизмом интересуются не только ресурсо-фобы(первая группа), но и Google. Новое приложение этой компании можно смело отнести к каркасу, который призван поддерживать вторую группу "параллельных разработчиков". Новый продукт называется Google Gears и призван помочь разработчикам в создании нового(в какой-то степени) класса приложений - offline-online application. Эти приложения работают в рамках браузера, но при этом для их работы не обязательно требуется доступ в интернет (т.е. для выполнения некоторых функций им может быть нужен доступ в сеть, но вообще они могут работать и без него). Краткое описание этой новинки от Google находиться здесь. И так, этот библиотечный каркас включает в себя:

• Локальный сервер - используется для кэширования и обслуживания ресурсов, которые нужны приложению для работы (HTML, JavaScript, рисунки, видео и т.д.). Приложение получит доступ к ним локально, если доступ к удаленному серверу отсутствует.
  
• БД - для хранения всего этого дела и прочей информации приложения
  
• и самое интересное Пул процессов(worker thread pool). Концепция пула процессов далеко не нова - это некоторое хранилище процессов, которые выделяются по требованию приложения. Дак вот Google встроил такой пул в свой каркас, как раз для того чтобы упростить разработку интерактивных (т.н. насыщенных параллелизмом) приложений. Полное описание worker thread pool API находится здесь. Вкратце скажу, что процессы, которые выделяются из пула, могут взаимодействовать только через посылку сообщений. Сообщения представляют собой строки, если нужно передать не строку, требуется предварительная "сериализация". Отдельно отмечу, что в пуле хранятся не потоки операционной системы, а т.н. легковесные процессы, что в сочетании с использованием сообщений для взаимодействия таких процессов делают всю систему похожей на Erlang-овские системы.
  

Такие дела, да чуть не забыл, все это великолепие за лицензировано как Open Source.

Плоский MS

MS разработал новый тип пользовательского интерфейса для PC - стол, на крышке которого размещен здоровенный тачскрин (сенсорный экран). Называется это чудо инженерной мысли - Surface (Поверхность\Плоскость) Наблюдаются следующие отличия от стандартных интерфейсов, основанных на тачскринах:

1. Экран Surface способен распознавать несколько одновременных нажатий (можно работать обоими руками)
   
2. Большой размер Surface и его горизонтальное расположение позволяют работать сразу нескольким пользователям одновременно
   
3. Surface способен узнавать ранее запомненные предметы, которые положили на поверхность экрана и совершать при их возникновении предопределенные действия. Так, например, компания T-Mobile, уже заказавшая несколько Surface предполагает расположить их в сети своих магазинов. Покупатель сможет подойти к стойке с Surface и когда он положит на неё свой мобильник, Surface по коду мобильника распознает марку и модель телефона и отобразит на экране совместимые с этим телефоном "прошивки", игры, рингтоны и пр. Затем пользователь ухватившись за одно из изображений этих продуктов перетащит их на свой телефон и продукт будет "перелит" в телефон, скажем, по WiFi.
   

Источник - incideHPC

Безопасность Vista

Известный центр тестирования CRN Test Center провел ряд испытаний системы безопасности новой операционной системы MS Vista, по результатам которых было заявлено, что система безопасности Vista ничуть не лучше аналогичной в XP. Грубо говоря те известные дыры, которые были в XP, благополучно по наследству перешли в Vista.
Обзорная статья - здесь.
Слайды иллюстрирующие тестирование - здесь.

Источник - EETimes

SSE из управляемого кода

Ещё с 90х годов процессоры Intel и AMD поддерживают в некоторой степени SIMD параллелизм в форме MMX и SSE. Несмотря на то, что большинство наших программ ориентированы на MIMD вычисления, исследования SIMD параллелизма ведутся ещё с начала 80 х. Вообще это направление выглядит весьма перспективным, хотя и не настолько разрекламированным как многоядерные процессоры. В частности идеи векторизации весьма популярны среди суперкомпьютерного сообщества и сообщества FORTRAN программистов. Интерес к этой теме подогревается также GPGPU сообществом (см., например, здесь и здесь), что в сочетании с многоядерной чехардой, дает интересную почву для размышлений.

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

Поскольку мы не можем прямо исползовать SEE инструкции в управляемом коде, нам придется вначале создать небольшую DLL. Назовем её “vecthelp.dll” и экспортнем из неё всего одну функцию:

#include 
const int c_vectorStride = 4;
extern "C" __declspec(dllexport)
void VectMult(float * src1, float * src2, float * dest, int length) {
    for (int i = 0; i < length; i += c_vectorStride) {
        // Vector load, multiply, store.
        __m128 v1 = _mm_load_ps(src1 + i); // MOVAPS
        __m128 v2 = _mm_load_ps(src2 + i); // MOVAPS
        __m128 vresult = _mm_mul_ps(v1, v2); // MULPS
        _mm_store_ps(dest + i, vresult); // MOVAPS
    }
}

“VectMult” принимает два указателя на массивы float-ов – “src1” и “src2” – каждый из которых имеет размер “length” и затем сохраняет результат их перемножения в массив “dest”. Обратите внимание мы перемещаемся по массиву с шагом 4 (c_vectorStride = 4). На каждой итерации мы загружаем 4 смежных элемента массивов “src1” и “src2” в XMMx регистры. Именно это делают SSE-инструкции “_mm_load_ps” . Затем с помощью “_mm_mul_ps” мы перемножаем эти 4 элемента параллельно. После этого результат сохраняется в массиве “dest”. Предполагается, что длина массивов кратна 4.

Теперь чтобы использовать этот параллельный умножитель из управляемого кода мы вынуждены использовать P/Invoke. Да при этом ещё нельзя забывать о том, что SSE работает с 16 байтным выравниванием(alignment), поэтому нам придется немного поколдовать, чтобы заставить CLR выдать нам его. Я размещают массив в стэке, чтобы не делать pinning массива(запрет на автоматическое перемещение переменной в памяти, без пиннинга сборщик мусора при устранении фрагментации памяти может произвольно менять адрес переменной, разумеется он автоматически перенастраивает все ссылки на новое местоположение переменной, но при интеропе это не допустимо и нужно либо делать пиннинг, либо размещать переменную в стэке). При больших массивах правда может возникнуть переполнение стэка. Короче это просто пример:

using System;
unsafe class Program {
    [System.Runtime.InteropServices.DllImport("vecthelp.dll")]
    private extern static void VectMult(float * src1, float * src2, float * dest, int length);

  public static void Main() {
   const int vecsize = 1024 * 16; // 16KB of floats.
   float* a = stackalloc float[vecsize + (16 / sizeof(float)) -1];
   float* b = stackalloc float[vecsize + (16 / sizeof(float)) -1];
   float* c = stackalloc float[vecsize + (16 / sizeof(float)) -1];
   // To use SSE, we must ensure 16 byte alignment.
   a = (float *)AlignUp(a, 16);
   b = (float *)AlignUp(b, 16);
   c = (float *)AlignUp(c, 16);
   // Initialize 'a' and 'b':
   for (int i = 0; i < vecsize; i++) {
       a[i] = i;
       b[i] = vecsize - i;
   }
   // Now perform the multiplication.
   VectMult(a, b, c, vecsize);
   ... do something with c ...
   }
   private static void * AlignUp(void * p, ulong alignBytes) {
     ulong addr = (ulong)p;
     ulong newAddr = (addr + alignBytes - 1) & ~(alignBytes - 1);
     return (void *)newAddr;
   }
}

Хотелось бы конечно, чтобы при этом результирующая производительность возросла в 4 раза. К сожалению P/Invoke делает свое черное дело и прирост производительности будет заметен только на больших массивах. Интересно многим ли из вас нужно вычислять произведение 16MB массивов. Кто-то безусловно занимается этим, но не думаю, что таких людей много. Однако даже за вычетом издержек на P\Invoke в итоге мы получаем 2 кратный прирост производительности на небольших массивах, 3х кратное увеличение на массивах большого размера.
Очевидно, что в будущем поддержка векторных операций в процессорах будет только расти и следовательно эти цифры изменяться в большую сторону. Возможно, даже когда-нибудь мы сможем пользоваться SSE, не прибегая к интеропу. Представьте – на 32х ядерной машине, если на каждом ядре будет стоять 16-ти позиционное векторное АЛУ, то мы в итоге получим 32х16 (512) потенциал для параллельного исполнения кода…, конечно, если мы сможем разбить нашу задачу на 512 независимых подзадач. Популярность GPU отчасти обусловлена более «широким» АЛУ, которыми они снабжены. Может быть как-нибудь я расскажу как можно сложить два массива параллельно с использованием пиксельных шейдеров и DirectX.

(с)Джо Даффи. Перевод мой.

Источник - Блог Джо Даффи (Joe Duffy)

Вторая жизнь Интел

Некоторое время назад MS открыла остров под названием “Visual Studio island” в онлайн-игре Second Life. На острове было несколько занимательных головоломок и прочее... Корпорация Intel видимо решила не уступать софтверному гиганту и также открыла собственное представительство в Second Life. В частности вчера проходила виртуальная конференция - ISN Lunch on Second Life, о чем незамедлительно известили блоггеры из Intel Software Network. Скриншот этой конференции вы можете видеть слева, а видео доступно на этой страничке.

Источник - ISN

Лед тронулся…?

Производитель процессоров больше не может ждать, когда мы – программисты начнем разрабатывать параллельный софт, для того чтобы многоядерные процессоры стали по настаящему востребованными. Об этой тенденции говорил Эдвард Ли (университет Беркли) в своей статье «Проблемы с потоками»:

“Интересно, что сами производители процессоров ратуют за многопоточное программирование, стараясь всячески продвинуть его в программистские массы. Их действия обусловлены тем, что с их точки зрения многопоточное программирование позволит использовать параллелизм (многоядерность), который они собираются продавать.
Так, например, Intel проводит активную компанию по поддержке обучения студентов многопоточному программированию. Если эта компания будет иметь успех, то следующее поколение программистов будет ещё более рьяно использовать потоки, что приведет к ещё более удручающим последствиям.”

Замечу, что Intel уже достаточно давно обращает внимание на продвижение идей параллелизма (и инструментов их поддерживающих) в программистские массы. Однако, будучи участником одного из таких семинаров (СПб, окт.2006) я не заметил каких-либо действительно современных предложений от Intel по решению проблем параллельного ПО. Оговорюсь, что под «действительно современными предложениями» я имею в виду то, о чем кажется, говорят все вокруг - более выразительные средства управления параллелизмом. На семинаре же Intel говорил об использовании OpenMP, о программировании на уровне мониторов\блокировок и о поддержке многопоточного программирования в .NET. Поэтому эта новостная заметка на EETimes привлекла мое внимание:

Интервью с главой лаборатории Intel по разработке микропроцессоров в Хиллсборо (Оригон, США) – Шекхар Боркар (Shekhar Y. Borkar).

Сегодня с развитием многоядерных процессоров должность разработчика параллельного ПО становится самой востребованной в Intel’овских исследовательских лабораториях по разработке микропроцессоров. Команда, численностью 250 человек, постоянно занимается разработкой прототипов DSL-ей(domain-specific languages) для описания параллелизма, а также параллельных версий существующих языков и приложений.

«В прошлом программы все работали быстрее и быстрее с увеличением частоты процессора, однако сегодня все изменилось – у нас больше не получиться получить прирост производительности «за так», халява кончилась - говорит Шекхар Боркар - Разработка параллельного ПО и распространение идей параллелизма в индустрии - «вот основная цель моей исследовательской группы. Очевидно, что параллельность ПО будет «удваиваться» каждые два года (или что-то около этого) – согласно закону Мура». 200 из 250 разработчиков лаборатории Боркара занимаются проблемами параллельного программирования. «К примеру сейчас - говорит Боркар - мы занимаемся проблемой внедрения языковых конструкций, описывающих параллелизм по данным, в интерпретируемые языки, такие как Ruby».

Наиболее перспективной областью исследований, по мнению Боркара, являются DSL-и – небольшие специализированные языки, предназначенные для описания параллелизма в таких областях как компьютерная графика, сетевые приложения, разработка отладчиков и библиотек. К примеру, Intel сейчас занимается разработкой нового языка описания сетевых (TCP\IP) взаимодействий в «более параллельном» стиле.

Компания также ведет разработку прототипов приложений в таких областях как распознавание и рендеринг в реальном времени. Считается, что поиск параллельных решения этих прикладных задач наиболее прост (тривиален). «Все, что вы делаете при распознавании или рендеринге в играх, так это работаете с матрицами – но параллельная обработка матриц хорошо известна нам ещё со времен суперкомпьютеров» - говорит Боркар, проработавший несколько лет в суперкомпьютерном подразделении Intel, сегодня уже почившим в бозе.

В ходе нашей беседы Шекхар не раз говорил о том, что считает, что разработчики всех уровней (от архитектора ПО – до кодера) должны обратить своё внимание на проблемы параллелизма: «Вокруг наших программ колышутся обширные поля параллелизма, жаждущие начала хорошей жатвы. Мы сейчас во многом выступаем в качестве проповедников параллелизма для индустрии и университетов. Однако мы понимаем, что такие координальные изменения требуют времени – около года или двух».

Сегодня такие университеты как Беркли, Стэнфорд, MIT, Иллинойский университет хорошо понимают необходимость обучения своих студентов и бакалавров технологиям параллельной разработки. «Изменение индустрии ПО происходит уже сейчас» - считает Шекхар Боркар.

Источник – EETimes

Параллельное программирование. Что делать?

Автор - Joseph Landman(с) | scalability.org
Перевод - Петров Александр(с)

Ранее мы уже обсуждали некоторые аспекты будущего параллельного программирования и современных тенденций в области. Грубо говоря, на сегодняшний день мы можем выделить два типа параллельных систем и инструментов их создания – системы с разделяемой (общей) памятью и системы с распределенной памятью. Наиболее известными инструментами создания таких систем являются OpenMP и MPI, соответственно. Впрочем есть и другие типы систем, и соответственно другие инструменты, но наиболее широко распространены именно эти.

Проблемы?

Используя OpenMP, вы по сути дела снабжаете свой код некоторыми пометками, которые позволяют компилятору «развернуть» эти пометки в недостающий код. Т.е., другими словами, OpenMP является макрорасширением языка (языком в языке) – компилятор выполняет автоматическое распараллеливания вашего алгоритма, руководствуясь вашими пометками (иногда это вызывает интересные проблемы - пример). Однако OpenMP предполагает, что вы программируете систему с разделяемой памятью – OpenMP не способна генерировать код, предназначенный для распределенного исполнения.

Используя MPI, вы полновластно владеете своим кодом. Вы – а не компилятор выполняете основную работу, используя библиотечные функции MPI. Компилятор не способен оптимизировать (в плане параллелизма) ваш mpi-код, поскольку это всего лишь вызовы функций. Ещё хуже, что вы по сути дела находитесь в свободном плавании и вольны выбирать тот способ решения задачи, какой вам заблагорассудиться, понятно, что этот способ вовсе не обязательно будет лучшим или вообще правильным.

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

Я вовсе не хочу сказать, что OpenMP – это плохо. Мне нравиться OpenMP, но мы не сможем использовать OpenMP в распределенных системах (а именно за ними будущее высокопроизводительных вычислений). Я не хочу сказать, что MPI – это плохо, просто MPI – это довольно-таки низкоуровневый инструмент, используя, MPI вам приходиться явно прописывать все то, что обычно генерирует за нас сам компилятор.

MPI – это что-то вроде ассемблера в параллельном программировании. Поэтому используя его, нужно быть готовым к тому, что совсем не просто написать рабочий код, неп росто его отлаживать, не просто его оптимизировать. Большинство программ MPI-программистов дают лишь 10-15% прирост производительности при увеличении числа ядер. Очень редко эта цифра достигает 50+%. Проблема не в программистах (а вы как думали?!) – проблема в том, что при распараллелировании крайне тяжело выделить действительно продолжительные по времени исполнения куски кода.

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

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

Одним словом, нам стоит задуматься о программировании систем, учитывающих отсутсвие локальности. Систем, в которых начинают играть роль такие понятия как доступность ресурсов во времени. Систем, в которых даже привычная файловая система предстает перед нами в другом свете – к примеру, в таких системах нам может потребоваться описать и реализовать единую модель доступа к файловой подсистеме из любой точки нашей системы. Возможно, это является чрезмерным усложнением на сегодняшний день, но я считаю, что, по крайней мере, мы должны учитывать распределенность и "нелокальность" как часть парадигмы программирования.

Программирование масштабных многопроцессорных систем будет только усложняться с ростом их масштаба. К тому же очевидно в скором времени появиться не-SMP системы (aSMP - асимметричные многопроцессорные системы), а также системы, использующие дополнительные сопроцессоры (называемые также акселераторами или APU (accelerator processing units)). Любая из этих нелокальных систем потребует четкого представления принципов распределенного (как в пространстве, так и во времени) доступа к данным. Надеюсь мы сможем преодолеть господствующие сегодня стереотипы и найти простые способы решения этих непростых проблем.

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

Это Фортран.

Joseph Landman(с).

---

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

Реальными примерами систем, о которых говорит автор, являются Googl-овская MapReduce и системы на основе идей GPGPU (General-Purpose computation on graphics processing units (GPUs)).
MapReduce - сильно распределенная система – это кластер из 1800 узлов (в каждом по 2 Intel Xeon 2GHz), между которыми распределяются данные и задания. При таком количестве узлов одной их основных проблем кластера является его отказоустойчивость – в том, смысле, что при выходе одного узла система должна перенаправить его данные и его задания другому узлу и т.д. Система называется MapReduce – поскольку модель этой системы основана на использовании двух широко распространенных в функциональном программировании функций: Map (отображение одного множества в другое путем применения функции преобразования к элементам исходного множества) и Reduce (получение агрегированной характеристики элементов множества (нпр. их суммы)).


GPGPU cистемы принадлежат к другому классу систем, которые автор, называет APU-системы. В таких системах (аппаратно-программных комплексах, по сути) центральному процессору аккомпанирует целый ряд внешних, обычно специализированных вычислителей. Это могут быть как ПЛИСы, так и микроконтроллеры или специализированные микропроцессоры (нпр. сигнальные(DSP) процессоры). Очевидно, что такие системы прямо-таки насыщены параллелизмом (вычислителей-то много) и они не являются однородными (в отличие, скажем, от сегодняшних многоядреных процессоров). Они не являются однородными поскольку в них могут использоваться различные каналы связи между элементами системы, что влечет отсутствие локальности, о которой говорит автор. В GPGPU системах, в качестве специализированного вычислителя выступает процессор видео карточки.