IT is wonderful World

Пару слов в защиту венгерской нотации

Как вы знаете, есть два основных способа записи имен переменных short_unix_way и длинныйПутьМайкрософт, иначе называемый "венгерской нотацией" по происхождению ее изобретателя Charles Simonyi  (кстати, Первого Дважды  КосмическогоТуриста Планеты). 

Напомню, что это такое: префикс определяющий тип  переменной + имя переменной, записанной в т.н. CamelCase. Не буду останавливаться на доводах противников о нечитаемости (как мне когда-то здесь сказали это _л_и_ш_ь ВоПрОс   п р и в ы ч к и), но давайте вспомним, откуда она взялась. Идея хранить тип в имени переменной не нова, вспомните Фортран. Венгерская же нотация лишь расширяет его идеи на случай борьбы с ассемблером, там, где типизации нет, а размер имеет существенное значение. 

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

$sOrderNumber и $iOrderNumber -- имея информацию о типе, более менее понятно, что в первом случае вероятней всего речь идет о номере заказа "видимом клиенту", что-то типа "30/07/01-1", а во втором, возможно, о внутреннем id базы.

Кроме того, ошибки вида $iPage="second" становятся видны сходу. Да и пользоваться autocompete в каком-нибудь Vim/SciTe/Notepad++ становится не в пример удобнее. В большинстве случаев тип переменной, которую хотим  использовать, мы знаем, чего не скажешь об имени, которое вышло за границу экрана.

Конечно, без фанатизма,  "немые" индексы в циклах стоит оставить однобуквенными. ;-)

 p.s.

А Саймони, наверное, стоит все таки написать как космтурПланетыДважды1

RoR + J2EE

Разработали и запустили проект YellCAT Автосервисы и автозапчасти в Петербурге. Точнее запустили давно, уже более полугода назад, но сейчас уже можно сказать о некоторых итогах разработки.

Платформой был выбрал Grails -- идеологически близкий к Ruby on Rails, но имеющий в основе язык Groovy, совместимый с Java в одну сторону на уровне исходного кода, в другую - исполняемого. То есть в groove можно спокойно использовать java код, а из джавы вызывать классы groovy импортировав при этом один модуль.

Что сказать. По сравнению с php (а до этого у нас был проект "Желтые Страницы Украины" yellowpages.ua) или Java (JBoss Seam, наша система слежения за подвижными объектами fleetmanager.ru я о ней писал) скорость разработки увеличилась в 2-4 раза. Субъективно, конечно. При этом, в отличии от php доступна вся мощь J2EE платформы. Кроме того, есть приятные вещи, такие как например "задачи" -- сервисные процессы, которые выполняются вне контекста HTTP запроса. В php обычно для этого используют юниксовый cron и набор серверных скриптов, то есть что-то дополнительное, лежашее вне основного проекта.

 Из минусов отмечу достаточно больной переход c grails 1.1 на 1.2, кроме того если вы используете сторонние плагины к grails (а их,кстати, огромное количество), то надо быть готовым, что плагин более не поддерживается и конфликует с новой версией, или наоборот, его новая версия требует  новую версию фреймвека.

Совместимость на уровне исходного кода с Java дает в руки громадное количество готового кода, накопленное человечеством с середины 90х :-) В частности, столкнувшись с задачей обработки графики, я не стал особо напрягаться и использовал старый проверенный код из джава проекта.

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

Быстродействие в условиях нагрузки , понятно, на молодом проекте затруднительно, но, опять же сравнивая с подобным проектом реализованным на php, субъективно grails быстрее, однако более точные оценки я немного отложу, поскольку сейчас у нас в разработке два других проекта на этом фреймвеке, с достаточно большой посещаемостью (~50 тыс уник. пользователей в день).

 

p.s.

если кого-то интересуют точные цифры -- welcome )

В продолжение темы о госзакупах

Вот уже и народное творчество появилось http://www.youtube.com/watch?v=TWKnhu2qqOY

 

 

Учет рабочего времени с Google Docs

Достаточно часто перед разработчиком (чаще, конечно, перед фрилансером) встает задача учета времени, потраченного на проект. Задача осложняется тем, что работа ведется на разных компьютерах и в разное время. Вэб, а в данном случае гугл докс, дают возможность достаточно просто вести этот учет, отмечая начало и конец работы над задачей. Далее будет много картинок, объясняющих как именно можно это сделать без лишних усилий.Итак, идем в Google Docs и создаем новую форму

WH -- рабочее название документа
Project 1 -- название проекта, здесь для примера, его можно пропустить или добавить несколько разных, но тогда в последующих пунктов придется сделать фильтр по ним, с другой стороны кажется разумной идея иметь по одному документу на проект.
Start/Finish - -1/1 -- используем именно цифровые значения, для последующего подсчета
What -- краткое описание выполненного (опционально)

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

Результаты заполнения формы сохраняются в гугл докс в таблицу с именем, соответствующем форме.

Для обработки данных поступим следующим образом. В колонку E (здесь и далее предполагаем, что вы сохранили предложенные мной поля) вводим формулу =A2*D2 (умножаем дату на маркер начала или конца, фокус в том, что дата эта double число, с которым можно работать подобным образом)

и размножаем полученную формулу на все ячейки (или до скольких дотянемся :) )

В колонку F вводим формулу подсчета часов =SUM(E2:E100)*24 (результаты в колонке Е в целых частях дней)

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

Исправим такое значение по памяти (в долях дня)

И отметим на всякий случай цветом.

Дополнительно украсим результат округлением %) =Round(SUM(E2:E100)*24,1)

Google и OpenId

Уже и не совсем новость, но поскольку в тот момент наш itblogs лежал, пишу сейчас. Google дал возможность авторизоваться через OpenId используя ваш гугл аккаунт. Раньше это тоже можно было сделать, но с некоторым "подпрыгом с переворотом" -- создать блог на blogger и там включить поддержку OpenId. Теперь надо сделать другой финт( да-да, впрямую без дополнительных телодвижений ничего не работает). Надо создать ваш профиль: http://www.google.com/profiles (правда сейчас "страница не найдена" почему-то, хотя, у гугла это часто со своими сервисами, вот его же кэш http://74.125.77.132/search?q=cache:YWKoJ9a4yGAJ:www.google.com/profiles+google+profiles&cd=1&hl=ru&ct=clnk&gl=ru). После создания вашего профиля, авторизация по openid становится доступной, например, http://www.google.com/profiles/denis.moskvin.

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

 

p.s.

вот рабочая ссылка для создания профиля http://www.google.com/profiles/me/editprofile

Lean практика

Разбавим молчание хотя бы небольшой репликой. 

Попалось на глаза описание еще одной практики управления проектами -- "Kanban": "пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP."

Подробнее по ссылкам:

http://team.custis.ru/2009/07/kanban-vs-scrum.html

http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf ( -- к сожалению, в Chrome редактор постов мишиного сервера работать нормально отказывается, так что, простите , без <a href... )

 

К вопросу о

...качестве?

Десять лет назад мы сделали систему поддержки пользователей для одного из сотовых провайдеров Петербурга (если кому интересно, это легко можно посмотреть на сайте моей компании). Система работает до сих пор и используется, и мы бы не узнали об этом, если бы не очередное обновление железа, и нужен был новый ключ. То есть версии Windows шли, сменяя друг друга, 2000, XP, 2003, Vista, 7ка (на подходе), а код работал не требуя поддержки (с небольшим апдейтом данных в силу объективных причин роста городской инфраструктуры).

Это был первый серьезный опыт работы компании над заказным проектом, причем в "эпоху краха доткомов".

"Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию." – Второй закон Вейнберга

Не все так грустно, я вас уверяю ;-)

Кто работает в Майкрософт?

Честно говоря, я не понимаю. МС -- это огромная компания, инновационный лидер во многих отраслях, но в вэбе они находятся в положении догоняющего, причем  последние 10 лет. Помню карикатуру еще 1997 года из журнала Byte (?) с изображением толстой гориллы с чемоданом с надписью Visual Basic спешащей на уходящий поезд под названием Web.

Что изменилось? Hotmail наконец обзавелся  AJAX интерфейсом, но если в Gmail кнопка Back в браузере возвращает вас из открытого письма в выбранную папку (Stared, Inbox, Sent), то на Hotmail.com вы попадаете на страницу приветствия. 

И дело не в программистах. Юзабилисты в МС есть? Тестеры? Или "и так сойдет"? Тогда 10и летняя игра в салочки совершенно не удивительна. 

 p.s.

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

Конец истории в ... 2014

Почему я так думаю? Просто из сопоставления двух малозначительных документов.

1 Перечень зарезервированных доменных имен http://www.cctld.ru/ru/docs/aktiv_8.php

2 Информация для пользователей СочиРу http://www.sochi.ru/pages/?id=331 

Процитирую:

Уважаемые клиенты и пользователи интернет-портала www.SOCHI.ru!

Администрация интернет-портала СочиРу извещает, что администратором доменного имениwww.sochi.ru с 20.08.2009 года является АНО "Оргкомитет "Сочи 2014".

Для пользователей и клиентов мы будем работать по новому доменному имениwww.SOCHI.com

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

Для пользователей интернет-адресов имя@sochi.ru,  а также доменных имен третьего уровня имя.sochi.ru сообщаем, что срок работы всех зарегистрированных интернет-адресов, по соглашению с АНО "Оргкомитет "Сочи 2014", будет продлен до 01.12.2009 года.

 

Обычно, домены приуроченные к событию и в городе именуют как имя + год или имя+ событие. Так было, к примеру, с spb300.ru, в разработке которого принял участие ваш покорный слуга, однако очевидно госчиновникам известно что-то большее. 

 

p.s.

В сети, впрочем, есть обращение администрации города о "пошли на просьбу коллег из Олимпийского комитета и желаем продвижения бренда "Олимпиада Сочи 2014" в России и на мировом уровне!", речь, однако, не об этом. 

о суперкомпьютерах 10 лет назад

---

Суперкомпьютерные системы

 

"Суперкомпьютер – это устройство, сводящее проблему вычислений к проблеме ввода/вывода" (c) Ken Batcher (шутка из USENET news:comp.parallel).

Суперкомпьютеры – кто это?

На самом деле, пожалуй, нет точного определения, что же такое суперкомпьютер. Понятно, что классу супер-ЭВМ принадлежат лишь те компьютеры, которые имеют максимальную производительность в настоящее время. Сегодняшние персоналки соизмеримы по вычислительной мощности с суперкомпьютерами 70-х.

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

Экспорт компьютеров производительностью от 2 до 7 тысяч MTOPS требует от поставщика "уведомления и консультаций" с министерством торговли.

Поставка компьютеров с быстродействием свыше 7 тысяч MTOPS невозможна без получения экспортной лицензии (правда, в последнее время в прессе мелькали сообщения о намерении повысить планку до 12300 MTOPS).

Здесь требуются некоторые пояснения по поводу единиц измерения:

- MTOPS – число теоретических операций в секунду;

- MIPS -- миллион команд в секунду;

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

Одним из основных тестов, определяющих производительность системы, является LINPACK – пакет фортран-программ для решения систем линейных алгебраических уравнений. Алгоритмы линейной алгебры весьма широко используются в самых разных задачах, поэтому измерение производительности на LINPACK представляет интерес для многих пользователей. Сведения о производительности различных машин на пакете LINPACK публикуются сотрудниками Аргоннской национальной лаборатории (США) Jack Dongarra, Hans Meuer и Erich Strohmaie и периодически обновляются.

Таким образом и формируется так называемый Top500 (http://www.top500.org/) – список 500 самых мощных компьютеров мира, компиляцией которого указанные авторы занимаются. Итак, на первую половину 1999 года (10 июня 1999 года) -- это первая десятка:

- 2121,3 GFLOPs (максимально полученная производительность по тесту LINPACK) – Intel ASCI Red Sandia National Labs (http://www.sandia.gov/ASCI/Red.htm), США, 1999. Кстати, это первый в мире компьютер, преодолевший планку в 1 TFLOPS (1068 GFLOPS, 1997 год);

- 1608 GFLOPs – SGI ASCI Blue Mountain Los Alamos National Laboratory (http://www.lanl.gov/Internal/projects/asci/bluemtn/bluemtn.html), США, 1998;

- 891,5 GFLOPs – SGI T3E1200 – Правительство США, 1998;

- 873,6 GFLOPs – Hitachi SR8000/128 – Токийский Университет (http://www.cc.u-tokyo.ac.jp/), Япония, 1999;

- 815,1 GFLOPs – SGI T3E900 – Правительство США, 1997;

- 690,9 GFLOPs – SGI ORIGIN 2000 Los Alamos National Laboratory/ACL (http://server.acl.lanl.gov/),США, 1999

- 552,92 GFLOPs – SGI T3E900 – United Kingdom Meteorological Office Bracknell (http://www.met-office.gov.uk/), Великобритания, 1997;

- 547 GFLOPs – IBM SP Silver – IBM (http://www.ibm.com/), США, 1998;

- 515,1 GFLOPs – SGI T3E900 Naval Oceanographic Office (NAVOCEANO) (http://www.navo.hpc.mil/), США, 1999;

- 509,9 GFLOPs – SGI T3E1200 – UK Centre for Science (http://www.csar.cfs.ac.uk/), Великобритания, 1998.

Здесь можно отметить лидерство компании SGI/Cray. Так, в первой десятке списка компьютерам SGI принадлежит 7 мест, в двадцатке – 14 мест, а в первых 50-ти позициях SGI занимает 31 место.

Первое место среди них принадлежит системе SGI ASCI Blue Mountain c производительностью 1,6 TFLOPS, содержащей 5040 микропроцессоров R10000 с тактовой частотой 200 МГц.

Установленные в России суперкомпьютеры пока не попали в список 500 мощнейших. Что же у нас? Вот первая десятка по данным Лаборатории параллельных информационных технологий научно-исследовательского вычислительного центра Московского государственного университета им.М.В.Ломоносова:

- Межведомственный Суперкомпьютерный Центр (http://www.jscc.ru/) – HP 9000 V-class –15360 MFLOPs;

- Институт высокопроизводительных вычислений и баз данных (http://www.csa.ru/) – Parsytec CCe – 12000 MFLOPs;

- Институт прикладной математики им М.В. Келдыша РАН (http://www.keldysh.ru/) – HP 9000 S-class – 11520 MFLOPs;

- Институт математического моделирования РАН (http://imamod.ru) – Parsytec CC – 6400 MFLOPs;

- Институт проблем химической физики РАН (http://www.icp.ac.ru/) – SNI RM600 E60 – 6400 MFLOPs;

- Объединенный институт ядерных исследований (http://www.jinr.dubna.su) – HP 9000 S-class – 5760 MFLOPs;

- Институт высокопроизводительных вычислений и баз данных (http://www.csa.ru/) – Parsytec CC/PP – 4800 MFLOPs;

- Институт высокопроизводительных вычислений и баз данных (http://www.csa.ru/) – Parsytec PowerMouse – 4800 MFLOPs;

- Институт физики высоких энергий (http://www.ihep.su) – DEC AlphaServer 8200 – 3600 MFLOPs;

- Институт проблем химической физики РАН (http://www.icp.ac.ru/) – SNI RM600 E20 – 3200 MFLOPs;

Суперкомпьютеры – что это?

В принципе, на сегодняшний день можно выделить следующие основные группы суперкомпьютеров -- векторные, параллельные и их комбинации.

Векторные

Несколько лет назад векторные суперкомпьютеры были очень популярны.

Рассмотрим векторный суперкомпьютер на примере системы Convex C-3440:

- 4 векторных процессора;

- 1 процессор ввода-вывода;

- объем физической памяти – 512 Мб;

- объем виртуальной памяти до – 4 Гб;

- объем памяти на жестких дисках – 4,5 Гб;

- 9-дорожечный накопитель на магнитной ленте;

- Ethernet (10 Мбит/сек) – интерфейс;

- DAS FDDI (100 Мбит/сек) – интерфейс;

- 16-канальный мультиплексор.

Пиковая производительность этого суперкомпьютера – 800 МFLOPs.

Основной выигрыш достигается за счет использования векторного процессора. В отличие от обычного, он имеет 128 (сто двадцать восемь) 8-байтных регистров, и за один такт может сложить один вектор с другим, просуммировать, умножить и т.д.

На тестовых задачах производительность потрясающая, но когда дело доходит до реальных задач, все несколько хуже. Реально мы получали выигрыш на задачах газодинамики в 1,5...2 раза.

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

Параллельные

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

- MPP -- компьютеры с моделью разделенной памяти;

- SMP -- компьютеры с моделью общей памяти.

Существует также нечто среднее между SMP и MPP. Это так называемые NUMA-архитектуры. У них память физически распределена, но логически общедоступна.

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

Массивно-параллельные системы (MPP)

Архитектурно система состоит из однородных вычислительных узлов, включающих (минимально):

- один или несколько центральных процессоров;

- оперативную память (прямой доступ к памяти других узлов невозможен);

- сетевой адаптер (коммуникационный процессор).

Яркий пример такой архитектуры – лидер Top500 – SGI/CRAY T3E.

Существуют два основных варианта установки операционной системы:

- полная ОС работает только на главной машине, а на каждом узле работает облегченная версия операционной системы, которая обеспечивает работу ветви параллельного приложения (Cray T3E);

- на каждом узле работает ОС (чаще всего вариант UNIX), например IBM RS/6000 SP под управлением ОС IBM AIX.

Программирование для таких систем производится в рамках модели передачи сообщений (MPI, PVM, BSPlib).

Симметричные мультипроцессорные системы (SMP)

Архитектурно система состоит из нескольких однородных процессоров и блока общей памяти (который, в свою очередь, аппаратно может состоять из нескольких блоков меньшего размера). Процессоры подключаются к памяти при помощи общей шины (2...4 процессорные) или при помощи коммутатора (например, серверы на базе процессоров Intel – IBM, HP, Compaq и пр..)

Такой компьютер обычно работает под управлением единой ОС (UNIX – для процессоров Alpha или Intel – для Windows NT).

ОС в таких системах автоматически распределяет процессы по CPU (если не затребовано явное распределение). Наиболее близким аналогом SMP можно считать двухпроцессорные PC под управлением WinNT. Программирование для таких систем производится в рамках модели общей памяти. Используются интерфейсы WinAPI threads, POSIX threads или специальные средства, например OpenMP. Модель общей памяти позволяет строить разработчикам компиляторов достаточно эффективные средства автоматической оптимизации под такую архитектуру.

Системы с неоднородным доступом к памяти (NUMA)

Архитектурно такая система состоит из однородных базовых модулей, которые, в свою очередь, состоят из небольшого числа процессоров и блока памяти. Эти модули объединяют при помощи коммутатора в единый комплекс, в котором аппаратно поддерживается единое адресное пространство (например SGI Origin2000, Sun HPC 10000). Такой компьютер обычно работает под управлением единой ОС. Однако существуют варианты, когда отдельные узлы работают под управлением "различных" операционных систем. Так, например, в NUMA-Q 2000 (http://www.sequent.com/products/highend_srv/numa.html) различные части работают под управлением WinNT и Unix.

Параллельные векторные системы (PVP)

Основным отличием таких систем является наличие векторных процессоров (см. ранее) в узлах параллельной архитектуры. Реально это новый виток развития векторных компьютеров – гибрид векторного и параллельного подходов. Сейчас такие системы получают всё большее распространение.

Обычно архитектура таких суперкомпьютеров представляет собой объединение нескольких векторных узлов (1...8 процессоров, работающих в модели общей памяти) в один компьютер при помощи высокоскоростного коммутатора (здесь просматривается аналогия с MPP). Так реализованы системы NEC SX-4/SX-5, Fujitsu VPP.

Остановимся теперь подробнее на следующем типе – кластерных систем (суперкомпьютер-конструктор "сделай сам").

Архитектурно узлы таких систем представляют собой рабочие станции или просто персональные компьютеры. Связи узлов осуществляются при помощи стандартной сетевой технологии (например Ethernet). При такой реализации системы в кластере могут участвовать компьютеры разной мощности или разной архитектуры. В этом случае их называют гетерогенными кластерами (например NT-кластер в NCSA, Beowulf-кластеры). В качестве ОС чаще всего используются Linux/FreeBSD или Windows NT вместе со специальными средствами поддержки параллельного программирования и распределения нагрузки.

Программирование в кластерах аналогично MPP (чаще всего используется MPI или PVM), однако рамки применения таких систем сильно ограничены. Одна из причин – сравнительно малый объем памяти, доступный одному узлу. Кроме того, передача больших объемов данных между узлами может вести к потере производительности из-за низкой пропускной способности сети.

Следует отметить низкую стоимость подобных систем. Сейчас практически любая лаборатория, имея несколько ПК, объединенных в сеть, может построить такую систему для решения сложных задач. При этом возможно построение "виртуального" кластера – т.е. кластера, узлы которого могут одновременно использоваться и как рабочие станции. Например, использование пакета WinMPI (http://dsg.dei.uc.pt/wmpi/intro.html) позволяет создать кластер на базе компьютеров под управлением Windows 95/98/NT, не внося существенных изменений в систему. Данный пакет берет на себя функции распределения подпроцессов в сети и обмена данными между узлами. Кстати сказать, не так давно (год-полтора назад) в США был скандал, связанный с экспортными ограничениями на суперкомпьютеры. Объектом разбирательства стала как раз система класса Beowulf (см. ниже), собранная на базе процессоров PII-400 и работающая под управлением операционной системы Red Hat 4.5. Как оказалось, система, состоящая из 15 машин, уже легко преодолевала установленный барьер производительности. Однако после судебного разбирательства ограничения на эту систему были сняты.

В качестве примера рассмотрим NT-кластер системы NCSA (1998 г.) http://access.ncsa.uiuc.edu/News/980407.Compaq.html. Кластер состоит из 128 двухпроцессорных машин с процессорами Intel. Используются компьютеры двух типов – Compaq Professional Workstation 6000 model (Pentium II/333MHz) и HP Kayak XU PC workstation (Pentium II/300MHz). Для связи используется сетевое оборудование Myrinet компании Myricom. Система работает под управлением пакета HPVM (Illinois High Performance Virtual Machine) (http://www-csag.cs.uiuc.edu/projects/hpvm.html), включающего в себя реализацию MPI.

Beowulf

В 1994 г. в Center of Excellence in Space Data and Information Sciences (http://cesdis.gsfc.nasa.gov/) – подразделении NASA – Томас Стерлинг и Дон Беккер построили кластерную систему, состоящую из шестнадцати процессоров класса i486DX4, соединенных посредством сети Ethernet. Этот проект получил название Beowulf (http://www.beowulf.org/gallery/wiglaf.jpg).

В 1998 г. в Лос-Аламосской национальной лаборатории Michael Warren с коллегами построили суперкомпьютер Avalon (http://cnls.lanl.gov/avalon/). Этот компьютер представляет собой Linux-кластер на базе процессоров DEC Alpha/533MHz (140 процессоров). Его производительность по LINPACK – 48,6 GFLOPS, что позволило ему занять 160-е место в Top500 (рядом с 152-процессорной системой IBM SP2).

Из наших аналогичных систем можно отметить, например, проект Паритет (http://www.csa.ru/CSA/MICRO/mikro1.htmr).

Конфигурация отдельного узла этого проекта:

- процессоры: 2 x Intel Pentium II (450 МГц);

- HDD – 10 Гб (Ultra Wide SCSI);

- RAM -- 512 Мб.

Конфигурация всей системы:

- процессоры – 8 x Intel Pentium II (450 МГц);

- суммарный объем дискового пространства -- 40 Гб (Ultra Wide SCSI);

- суммарный объем оперативной памяти – 2048 Мб.

Каждый узел снабжен двумя сетевыми интерфейсами – адаптером Fast Ethernet и адаптером Myrinet. Кроме того, входной узел системы имеет дополнительную сетевую карту, обеспечивающую доступ во внешнюю сеть. Пиковая производительность – 3,2 GFLOP/сек.

Следует сказать, что кроме Beowulf существуют и другие интересные кластерные проекты, например Condor (http://www.cs.wisc.edu/condor/), позволяющий использовать простаивающие рабочие станции, или Berkeley NOW (Network Of Workstations) (http://now.cs.berkeley.edu/) – технология аналогичная Beowulf, разработаная в университете Беркли. На этом кластере, состоящем из100 рабочих станций на процессорах UltraSPARC, была достигнута производительность в 10 GFLOPS (1997 г.).

Об этих и других технологиях можно прочитать на сайте Лаборатории параллельных информационных технологий научно-исследовательского вычислительного центра Московского государственного университета им.М.В.Ломоносова (http://parallel.srcc.msu.su).

Языки и интерфейсы программирования

Рассмотрим средства написания параллельных программ. Их условно можно разделить на две группы:

- специальные языки или расширения существующих, в конструкцию которых введены операторы, предназначенные для распараллеливания программ;

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

Обычно производитель той или иной суперкомпьютерной системы предоставляет соответствующие средства для конкретной платформы. Это, например, система Parix на компьютерах компании Parsytec или управляющие директивы для компилятора на векторных компьютерах компании Convex. Однако очевидно, что использование средств, ориентированных на конкретную платформу, затрудняет, а подчас делает невозможным перенос программы на другой компьютер.

Существует довольно много специальных языков программирования, ориентированных на параллельные компьютеры. Среди них хотелось бы отметить:

- Ada (Ada-95) – официальный язык программирования министерства обороны США;

- Modula-3 – наследник Modula-2 и Pascal;

- Fortran 90,95 – развитие языка Fortran 77. Fortran 90 включает в себя возможность оптимизации (с использованием векторной и параллельной архитектур) работы с массивами, а в Fortran 95 включены средства для оптимизации циклов и еще некоторые усовершенствования;

- HPF – усовершенствование языка Fortran 90. В него включены средства (часть как -- операторы и функции языка, часть – как директивы компилятора) для распределения данных по процессорам. Этот язык успешно развивается – на сегодняшний день существует версия 2.0 (http://www.crpc.rice.edu/HPFF/versions/hpf2/hpf-v20/index.html);

- HPC, HPC++ -- языки, похожие на HPF, содержащие в основе C/C++.

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

Рассмотрим подробнее некоторые существующие программные интерфейсы:

- RPC – удаленный вызов процедур. "В чистую" используется редко, чаще служит основой для следующих двух;

- DCOM – распределенная компонентная объектная модель. Применима только на платформе Windows NT. Позволяет создавать программу, основанную на компонентах (программных модулях), распределенных в сети и запускаемых в адресном пространстве другого компьютера;

- CORBA – объектный брокер запросов. Технология, во многом аналогичная DCOM, но поддерживаемая большим числом операционных систем.

Надо отметить, что данные интерфейсы на суперкомпьютерах пока применяются очень редко. В инженерных и научных расчетах большей популярностью пользуются следующие:

- PVM -- Parallel Virtual Machine. Это интерфейс, созданный в рамках исследовательского проекта. Достаточно прост и легок в освоении, но и возможности его ограничены по сравнению с MPI;

- OpenMP -- стандарт для программирования в модели общей памяти. Существуют библиотеки OpenMP для Fortran и C/C++. В OpenMP организационно входят спецификации набора директив компилятора, процедур и переменных среды;

- MPI – Message passing interface (взаимодействие через передачу сообщений). MPI предоставляет программисту единый механизм взаимодействия ветвей внутри параллельного приложения независимо от машинной архитектуры (однопроцессорные/многопроцессорные с общей/раздельной памятью), взаимного расположения ветвей (на одном процессоре/на нескольких) и API операционной системы. Кроме того, существуют библиотеки MPI для Fortran и C/C++ и версии практически для всех платформ и операционных систем (коммерческие и свободные). Фактически, на сегодняшний день это стандарт параллельного программирования. MPI быстро развивается – MPI-I был принят в 1997 г., и вот уже на подходе версия MPI-III. Существует также большое количество библиотек, базирующихся на MPI, например P4 – библиотека, состоящая из макросов и процедур, которые позволяют писать программы для компьютеров с распределенной памятью, используя посылку сообщений и эмуляцию общей памяти. Версии этой библиотеки разработаны для Fortran и C/C++ и практически для всех платформ.

При написании статьи были использованы материалы:

- Института высокопроизводительных вычислений и баз данных

(http://www.csa.ru);

- Лаборатории параллельных информационных технологий научно-исследовательского вычислительного центра Московского государственного университета им.М.В.Ломоносова (http://parallel.srcc.msu.su)

- Журнала ComputerWorld (http://www.osp.ru/cw/)

 

О рекламе в блогах

У Андрея Александровича возник вполне естественный вопрос, "как строить отношения". Я не блоггер, и дел с мелкими рекламодателями никогда не имел, поэтому и ответа у меня нет (есть, конечно ,другие: о "поиске и замене в группе файлов", о том, куда исчезают сайты, превращенные в "ссылкопомойку" из поисковой выдачи, и как блокируют сайты, даже по прямому переходу, распространяющие вирусы). Но спрашивали не об этом, поэтому и говорить, вероятно, не стоит. Зато вчера мне попался на глаза плакат у нас в Петербурге. Думаю, это лучший ответ из всех возможных.

 

 Андрей Александрович, 

 

 

С Уважением. 

:-) 

Немного о ...

Линукс. Совершенно частный случай. Компания разрабатывает достаточно сложные интернет/интранет решения. Понятно, что имеет весь чудесный браузерный зоопарк на входе. Внимание вопрос. Что дешевле, купить Windows и воспользоваться родными пакетами или устанавливать и настраивать несколько версий Internet Explorer, Chrome, Safari под Linux при том, что даже в случае корректной работоспособности нельзя гарантированно утверждать об аутентичности их работы в подобном окружении? Словом, кто-то может воевать за СПО, а кто-то просто работать, пользуясь своими конкурентными (sic!) преимуществами.

:-) 

Первый звонок от Ларри Элиссона

Как пишет Слэшдот (http://tech.slashdot.org/story/09/05/29/1711203/Java-Gets-New-Garbage-Collector-But-Only-If-You-Buy-Support  к сожалению, прямо сейчас ссылка недоступна) новая машина сборки мусора в Java будет доступна только компаниям, имеющим подписку на саппорт.

Oracle показывает зубки? Как скоро ждем закат MySql ? 

Хороший подарок в кризис от Евросоюза.

BBC сообщает, что Евросоюз оштрафовал Intel на 1,06 млрд. евро.

"...исполнительный орган Евросоюза пришел к заключению, что в период с 2002 по 2007 годы Intel платил производителям и продавцам за то, чтобы они отдавали предпочтение чипам, производимым именно этим гигантом, а не его конкурентом, другой американской фирмой, Advanced Micro Devices (AMD), занимающей второе место в списке крупнейших мировых производителей процессоров.
По итогам разбирательства, проводившегося по жалобе AMD, эксперты Еврокомиссии выяснили, что многие гиганты - такие как Acer, Dell, HP, Lenovo и NEC - получали скрытые вознаграждения за то, что в производимых ими компьютерах использовали чипы Intel.
Кроме того, следователи пришли к выводу, что компания Media Saturn, которой принадлежит крупнейший в Европе розничный продавец электроники Media Markt, также получала деньги за то, что ее магазины торговали только компьютерами с чипами Intel.
"Intel наносил ущерб миллионам европейских потребителей, на протяжении многих лет совершая преднамеренные действия с целью выдавливания конкурентов с рынка компьютерных чипов, - заявила комиссар Евросоюза по вопросам конкуренции Нейли Крус. - Нельзя терпеть столь серьезное и последовательное нарушение антимонопольных правил ЕС". Помимо штрафа, Еврокомиссия предписала руководству Intel "немедленно прекратить незаконную деятельность в случае, если она до сих пор продолжается".

За откаты, значится. В два раза больше чем Майкрософт. Хм...

 

http://www.bbc.co.uk/russian/business/2009/05/090513_intel_fined.shtml

2 ORM or ! 2 ORM ?

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

Поэтому, пытаясь учиться на собственных ошибках, я хочу привести статью Сергея Тарасова, с которой я в принципе согласен, но хотел бы услышать мнения тех, кто работал с тем же Hibernate или SQL alchemy достаточно плотно (Сергей, я честно пытался выбрать кусочек, но она настолько прекрасна в своей целостности, что... извини, словом ;-) ).

На архитектурных картинках обычно рисуют красивые схемы по разделению слоев представления, бизнес логики и данных. Голубая мечта начинающего разработчика - использовать одну среду для разработки всех слоев и забыть про необходимость знаний реляционных СУБД, сведя их назначение к интеллектуальной файловой системе. Слово SQL (сиквел) вызывает негативные ассоциации, а уж про триггеры или процедурные расширения оного и говорить не приходится. И тут приходят добрые дяди, с книжками Фаулера и других полубогов под мышкой, заявляющие новичкам примерно следующее: "Парни, реляционные СУБД - пережиток эпохи 30-летней давности. Сейчас все строится на ООП. И есть чудесная штука - отображение с реляций на объекты (object relation mapping). Начните использовать ее и забудьте про жестокое наследие прошлого!"

Парни принимают предложение. Дальше эволюция разработки системы примерно следующая.

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

Начинаем строить предметную модель. Добавляем классы, свойства, связи. Генерируем структуру БД или подцепляемся к существующей. Строим интерфейс управления объектами типа "создать, выбрать, модифицировать, удалить" (CRUD: create, retrieve, update, delete). Все достаточно просто. По крайней мере кажется немногим сложнее, чем работа с DataSet. Тем кто о них знает. Так как многие и не подозревают о существовании табличных форм жизни данных в приложении кроме DBGrid.

Как только разработчики реализовали CRUD-логику, начинается основное действо. Безболезненно использовать сиквел уже нельзя. Надо использовать собственный язык запросов ORM. Нестандартный, кривой, созданный в так называемом эволюционном дизайне. То есть по принципу добавления новых фишек по мере надобности. Если он, язык, вообще имеется в данном ORM, конечно. К тому же вдруг оказывается, что собственный язык запросов генерирует далеко не самый оптимальный сиквел.

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

Однако, запросы типа "выбрать сотрудников, зарплата которых в течение последнего года не превышала среднюю за предыдущий год" уже вызывают проблемы на уровне встроенного языка. Тогда разработчики идут зачастую единственно возможным путем: выбираем коллекцию объектов и в цикле ее фильтруем руками, вызывая методы связанных объектов. Количество небольших SQL-запросов к СУБД при такой обработке коллекций может исчисляться десятками тысяч. 

Примерно так же это делалось с табличными данными разработчиками на Clipper в конце 80-х годов. Там это называлось "навигационная обработка". Думаю, термин уместен и здесь.

Суть в том, что в эпоху перехода с Клиппера на РСУБД многие приложения и их разработчики продолжали использовать навигационный подход. И приложения работали медленно, зачастую блокируя многопользовательсткий доступ. Потому что для эффективной работы с РСУБД нужно использовать Р(реляционные) подходы. Множественные подходы. Множественные не в смысле "много подходов", а ориентированные на обработку множеств. Предполагающие хотя бы минимальную тренировку мозгов разработчика на задачки из теории множеств.

Дорогие коллеги, учите матчасть. И будет сиквел вашим верным другом на долгие времена.

Сергей Тарасов, 06.04.2009

 

p.s.

Кстати, а что MS LINQ 2 SQL таки похоронила?

p.p.s.

Не устаю удивляться справедливости законов гегелевской диалектики. "Отрицание отрицания" и спиральное развитие во всей красе.