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