пятница, 6 июля 2007 г.
Столпы параллелизма. Herb Sutter on Dr. Dobb's Journal
Herb Sutter начал вести колонку по параллельному программированию в журнале Dr.Dobb's. Закончил перевод его первой обзорной и в тоже время достаточно конкретной статьи - здесь. От комментариев пока воздержусь, но было интересно :)
понедельник, 2 июля 2007 г.
AUR - The Confessor | Когда роботы как люди 2




Скетчи и чертежи лампы Гай приводит на своем сайте.
Только посмотрите на эту механику!, чем-то напоминает работы Леонардо да Винчи. Впрочем почти обо всём этом вы можете почитать в обзорах робототехнического
рунета (ссылки выше).
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
Вот несколько фотоk для затравки:
Красота! :)
Подробный обзор здесь.
Источник - www.mobile-review.com
суббота, 30 июня 2007 г.
RoboCup 2007
Интересно, что как замечают сами устроители выставки, все большую и большую роль в усепшном поведении роботов играет не механика и не электроника, а программные мозги роботов. Подчеркивается, что некоторые команды вообще практически не меняют аппаратную начинку своих железных друзей, совершенствуя лишь ПО.
Как уже отмечалось выше изюминкой данного чемпионата в этом году станут роботы размером в несколько микрон. Интересно, что эти роботы были произведены по технологии MEMS(wiki), эта же технология легла в основу ранее описанного микро пьезогенератора.
По сути дела MEMS это часть того что у нас называют нанотехнологиями. MEMS - интеграция продуктов механики и электроники на кристалле размеры, которого имеют порядок 10
Полный список стран участников представлен здесь. Присутствуют команды из Ирана, Чили, Китая..., обидно - наших нет. Насколько я понимаю некоторым аналогом RoboCup в России является фестиваль "Мобильные роботы", проводимый МГУ.
"Виброток"
В этот раз IMEC Holst Centre разработал источники питания на пьезоэлементах - переменный ток продуцируется на основе вибраций окружающей среды.

Пьезоэлектричество известно уже достаточно давно, однако для его успешного применения требуется преодолеть ряд проблем (в частности проблему резонанса пьезоэлемента - в момент резонанса продуцируемая мощность возрастает в 200 раз), что и было успешно сделано в Нидерландах. Тем более интересно, как точно была выбрана область применения для разработанного источника питания - питание беспроводных микродатчиков. Примерами таких датчиков могут служить сенсоры в крадиостимуляторах, авиационных двигателях, а также других встроенных системах малого масштаба.
Новый источник питания продуцирует мощность в 40 микроватт при частоте 1.8 КГц, что вполне достаточно для питания беспроводных сенсоров. Интересно, что общим направлением исследований IMEC Holst Centre является создание электрогенераторов превращающих градиент окр.среды любой физической природы в электрический ток.
Такие элементы питания, как собственно уже разработанный пьезоэлектрический элемент позволят целому классу систем обходится без батареек и аккумуляторов, что скажем в случае кардиостимуляторов очень важно.
Источник - EETimes
пятница, 29 июня 2007 г.
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), которая так и называется - "Многоядерные процессоры: переломный момент для программирования". Думаю ничего нового читатели моего блога в этом сообщении не найдут - почти все сообщения от разнообразных авторов и мои собственные замечания посвящены этой теме. Поэтому тезисно -
Продолжает эту тему пост Тимоти Маттсона(Timothy Mattson), озаглавленный как "Параллельные вычисления: сделаем последовательное ПО исчезающей редкостью". Маттсона, которому по работе приходится встречаться с различными группами разработчиков, занимающихся вопросами параллельного программирования, раздражает, что с аппаратчиками он может обсуждать конкретные проекты и понятные четко определенные, практические проблемы. Он говорит, что они буквально смакуют решения тех или иных проблем (we are sweating the details). Когда же он работает с программистами, то все тухло... Вместо конкретики они вынуждены барахтаться в хаосе. Причинами такого положения дел по мнению Маттсона являются следующие нерешенные вопросы:
И что же вы думали, в одном из первых сообщений этого блога вновь поднимается проблема распространения многоядерных процессоров и слабой поддержки их со стороны программистов.
Я имею ввиду заметку Али-Реза Адл-Табатабаи (Ali-Reza Adl-Tabatabai,Senior Principal Engineer in Intel’s Programming Systems Lab), которая так и называется - "Многоядерные процессоры: переломный момент для программирования". Думаю ничего нового читатели моего блога в этом сообщении не найдут - почти все сообщения от разнообразных авторов и мои собственные замечания посвящены этой теме. Поэтому тезисно -
- Раньше программист писал программу, а каждые 18 месяцев она работала почти вдвое быстрее (закон Мура). Больше такого не будет. Грубо говоря, если программист хочет, чтобы его программа работала быстрее на новом процессоре, то он должен разрабатывать её в параллельном (и масштабируемом) стиле.
- Современные языки программирования для решения задачи 1 не годятся. Они позволяют лишь использовать многопоточные библиотеки. Потоки по сути дела являются современными аналогами "goto".
- Для решения задачи 1 нужны высокоуровневые языки программирования с поддержкой параллелизма.
- И главное - скорей всего придется ломать мозги программистам, поскольку и с точки зрения современной теории, образования и с точки зрения современной практики, параллельное программирование развито не очень хорошо.
Продолжает эту тему пост Тимоти Маттсона(Timothy Mattson), озаглавленный как "Параллельные вычисления: сделаем последовательное ПО исчезающей редкостью". Маттсона, которому по работе приходится встречаться с различными группами разработчиков, занимающихся вопросами параллельного программирования, раздражает, что с аппаратчиками он может обсуждать конкретные проекты и понятные четко определенные, практические проблемы. Он говорит, что они буквально смакуют решения тех или иных проблем (we are sweating the details). Когда же он работает с программистами, то все тухло... Вместо конкретики они вынуждены барахтаться в хаосе. Причинами такого положения дел по мнению Маттсона являются следующие нерешенные вопросы:
- Нужны ли новые языки программирования? Или достаточно каким-то образом расширить существующие языки?
[от себя добавлю, что, например, Эдвард Ли предлагает альтернативное этим двум подходам решение - создание нового языка программирования, который бы не заменял старые языки, распространенные сейчас, а был бы ортогонален им. Такой язык не был бы универсальным, а наоборот был призван дополнить существующий язык, оставаясь независимым от него, подробнее здесь, стр 14.] - Способны ли языки, с поддержкой распараллеливания по данным (data parallel programming languages) удовлетворить потребности прикладных программистов? Удобны ли и понятны ли такие языки прикладных программистам, или же для них это очередной HPF (High Performance Fortran)?
- Любой масштабируемый параллельный код основан на посылке сообщений... или на общей памяти с которой работают в стиле посылки сообщений. Можем ли мы сделать посылку сообщений частью мейнстрима? Или же это слишком сложно для не HPC-программистов (HPC-High Performance Computing)?
- Фреймворки подобные Visual Basic значительно упростили создание прикладного ПО. Может ли мы использовать подобный, framework-based подход в параллельном программировании?
- Каким образом мы можем научить программистов "думать параллельно", решать задачи в параллельном стиле?
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.
Более подробно о PRAM вы можете прочесть в статье Узи Вишкина и в уже упомянутой заметке Clay Breshears.
Подписаться на:
Сообщения (Atom)