Я еще в 1992 г. писал в еженедельнике СофтМаркет, что достала перестановка таймеров ПК два раза в год. Сейчас у меня 2 ПК: на одном 6 ОС, на другом – 4 и какие глюки каждый раз! А еще кучка: 2 видео-рекордера, 2 будильника, 2 наручные часы. Спасибо, что на соковыжималке, стиральной машинке и холодильнике часов нет. А у кого сомнения – welcome: goto на рувики в статью «Летнее время» – там множество ссылок, когда все прочтешь, то становится непонятным, откуда взялась сама идея перевода часов каждые полгода – не иначе как диверсия марсиан! Хорошо хоть Центр Управления Полетами (ЦУП) не переходит на летнее время, а то бы ракеты падали в 2 раза чаще.

Когда утром человек выходит из дома [начинается новый проект], и видит, что на улице гололёд [в случае с разработкой ПО он там всегда], он начинаете движение очень осторожно, привыкая к поверхности. Причём даже если вчера [в прошлом проекте] был точно такой же гололёд, начало движения ничем не отличается - каждый раз он заново привыкает к тому, чтобы идти по льду.

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

Итак, наш герой вышл из дома, сделал несколько неуклюжих шагов по ненадёжной поверхности, и, набрав некоторую скорость (морозец всё-таки [менеджмент оделяет повышенным вниманием]), продвигается к остановке [промежуточный релиз]. (Причём чем сильнее мороз, тем сильнее обычно хочется ускориться. Однако говорят, что когда становится слишком холодно, и человек начинает замерзать, он впадает в сонное состояние)

И тут он (всегда!) поскальзывается [в проекте возникают проблемы; технические / организационные / социальные - какие угодно]. В зависимости от того, насколько сильно человек поскользнулся и от его чувства равновесия [опыта ведения проектов] есть три возможных развития событий.

Первый. Человек совсем не имеет опыта ходьбы по льду. В этом случае лучшее, что он может сделать, это хорошо упасть [как можно раньше обнаружить, что проект не может быть завершён с приемлемыми показателями и закрыть его, потратив минимум сил и средств].

Второй. Если человек чувствует себя более или менее уверено, то он, как правило, быстро сбавляет скорость, начинает махать руками и по всякому кривляться, и наконец замирает в какой-нибудь неестественной позе [в моменты кризисов формы организации проекта могут принимать весьма причудливые формы; главное тут - остановить раскачивание проекта, потом можно вернуться к привычным способам работы]. Выждав мгновение и восстановив равновесие, он возвращается в нормальное положение и снова набирает скорость.

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

Что делает в такой ситуации нормальный обыватель вроде меня? Плюхается плашмя, скребёт лицом по этому самому льду, встаёт, ругаясь на чём свет стоит, и, отряхиваясь, идёт ждать следующего автобуса [например, следующего финансового квартала - для запуска разработанного бизнес-ПО]. Однако Лёша занимался рукопашным боем и дзюдо, и то, что он сделал, глубоко меня поразило. Он, уже падая, успел повернуться перпердикулярно направлению нашего бега, сгруппировался, упал, прокатился по льду, раз или два провернувшись вдоль оси тела, и, резко подскочив, продолжил бег, почти не потеряв скорости. Не успел я замедлиться, чтобы подождать упавшего друга, как пришлось его догонять.

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

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

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

Впрочем, обо всем по порядку.

При анализе довольно больших проектов (а в реальной жизни маленькие проекты вообше никого не интрересуют) пользователь получает довольно большое количество ошибок Uninitialized Memory Access (доступ к непроинициализированной памяти), при условии, что выбран уровень mi4. В некоторых случаях эти ошибки не отражают реальных проблем кода (benign errors) и могут восприниматься как false positives диагностики инструмента. Однако, тысячи таких ошибок в отчете могут скрыть несколько реальных проблем  (real errors), которые тоже обнаружены в приложении.

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

Рассмотрими простой примерчик.

int main() {
	char *foo = (char*)malloc(100);
	char *bar = (char*)malloc(100);
	memcpy(bar, foo, 100);

	free(bar);
	free(foo);
	return 0;
}

Копирование неинициализированной памяти по указателю foo само по себе ошибкой, влияющей на корректность этого приложения, не является. До тех пор, пока память в bar не будет использована в программе, нас такое копирование не беспокоит.
Однако Инспектор все равно выдаст на уровне mi4 диакностику Uninitialized Memory Access относительно памяти в foo.

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

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

Кто может привести такие примеры, когда код содержит множество таких вот benign errors – ошибок, не влияющих на корректность исполнения приложения? Насколько часто они встречаются? Какой можно было бы предложить алгоритм логического разделения опасных ошибок и безопасных ошибок?

Титаны, ай нид хелп!

Только не закидывайте меня помидорами, что пытаюсь использовать ISN в личных рабочих целях

Поделитесь, пожалуйста, своим опытом участия в ИТ сообществах Рунета? Посещаете ли вы хабрахабр, ИТ сообщества в жж, e-xecutive, professionali и т.д.? Сегодня площадок все больше и больше, в чем их плюсы и минусы для Вас?

Спасибо.

Данный подход называют “Распараллеливание черного ящика”. Он состоит из 4х основных шагов:

• этап поиска мест, где параллелизм наиболее эффективен;
• этап программной реализации распараллеливания;
• этап отладки работы уже параллельного приложения;
• этап повышения эффективности распараллеливания.

Для каждого этапа я использовал один из компонентов инструментария Intel® Parallel Studio: Parallel Amplifier – Hotspots, Parallel Composer, Parallel Inspector и Parallel Amplifier – Concurrency и Lock and Waits, соответственно. Первому шагу я уже посвятил один из своих блогов: http://software.intel.com/ru-ru/blogs/2009/10/26/2002338/. Я планирую опубликовать блоги по оставшимся этапам. Так что у вас будет возможность задать вопросы, которые вы не задали на семинаре.

Теперь о моих впечатлениях: Не хочу обидеть Нижегородцев, но я очень рад тому, что география аудитории онлайн-семинара оказалась довольно обширной: начиная дальним востоком России и заканчивая средней Европой. Попытаюсь объяснить почему. В силу своего географического расположения, студенты Нижнего Новгорода имеют возможность как минимум 1 раз в квартал посещать технические семинары, которые проводят инженеры компании Intel «в живую». У студентов других городов такой возможности, к сожалению, нет. Мне самому повезло, так как во время учебы я принимал участие (приезжал из Уфы) в Зимней школе 2005 и в Летней школе 2007 от компании Интел, которые проходили в Нижнем Новгороде. Таким образом, к окончанию учебы я уже знал, какие знания и какой опыт от меня будит требовать работодатель.

Вести онлайн семинар оказалось гораздо труднее, чем в живую. Во-первых, во время семинара я не мог понять, насколько интересно и понятно содержание презентации и демонстраций, т.к. нет ран-тайм общения с аудиторией. К примеру, когда я вижу, что большая часть засыпает или нет вообще никаких вопросов со стороны слушателей, то я стараюсь повернуть русло в другую сторону и попытаться заинтересовать аудиторию. Если это не в 8-9 утра, конечно :). Во-вторых, это задержка видео и звукового сигнала. Когда логически переходишь к новому слайду или картинке, но аудитория еще не видит ее, это порой сбивает с мысли. Этот список можно продолжать. Но, как говорится, ”Первый блин комом”. Мы постараемся учесть все ошибки, и следующий “вебинарь” получится лучше с технической точки зрения. Предлагаю обсудить ваши впечатления. Пользуясь случаем, хочу задать вопрос: какие онлайн семинары вы бы хотели посетить?. Стоит заметить, что я уже получил запросы на подробное описание Advanced Vector Extension (AVX) и Intel® Parallel Debugger Extension (PDE).

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

Спасибо Вам, Спасибо Диме и Маше!

Add-on от Дмитрия:

Да пожалуйста! :). Пользуясь правами администратора ISN, я беспардонно влезу в эту запись чтобы еще раз поблагодарить Кирилла :). Кирилл, ты у нас первопроходец! И не только в плане самого что ни на есть первого русского вебинара. Я внимательно посмотрел на вебинары наших зарубежных коллег, и вот что оказалось: мы первые, кто показывает на вебинаре case study: не просто презентацию, а живые демки. Впрочем, довольно петь друг другу дифирамбы: недостатков тоже хватало! Как уже сказал Кирилл, ваши отзывы и пожелания принимаются в виде комментариев к этой записи. Заранее спасибо.

Ссылки по теме:
Посмотреть вебинар в записи можно здесь (извините, первые минут 5 «потерялись»).
Исходники проекта Tachyon на разных стадиях оптимизации лежат здесь.
Описание процесса сборки Tachyon.
Скачать триальную версию Intel® Parallel Studio можно здесь.

Всем удачи!

Меня зовут Виталий Дильмухаметов, я один из участников сообщества ISN. Занимаюсь разработкой программного обеспечения, в основном на платформе Microsoft .NET. С недавнего времени (а именно с октября 2009 г.) являюсь MS MVP в области Client App Dev.

Думаю, что как и многие здесь, впервые познакомился с компанией Intel, приобретя её продукцию. Тогда это был Pentium III 500МГц, который до сих пор исправно работает, уже почти 10 лет. Хорошая всё-таки машина

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

В этом блоге планирую публиковать статьи, связанные с весьма занимательной частью новой, 4-й версии .NET - Parallel Extensions. Это набор средств для упрощения распараллеливания кода управляемых приложений. Текущая версия - beta 2, релиз обещают в марте будущего года.

Мои контакты:
e-mail/msn/gtalk: vitusmail at [NOSPAM] gmail.com,
twitter: http://twitter.com/vitus74
tech blog (rus): http://blogs.gotdotnet.ru/personal/grp/

Пишите, всегда открыт для общения!

Как мы и обещали, вчера - 26 октября, официально были объявлены победители конкурса «Лето с Intel для профессионального роста». Целую неделю длилось судейство, в котором приняли участие инженеры и менеджеры Intel. Кстати, количество судей было немногим меньше числа участников. Так что оценки каждого хоть и были субъективными, но окончательные результаты на 100% объективны. Те, кто читали конкурсные работы, согласятся, что все проекты «школьников» очень интересные, поэтому выбрать лучшие из лучших было очень непросто. Мы бы с радостью вручили по нетбуку каждому участнику. Но сами понимаете, экономический кризис… да и конкурс предполагает только 3 призовых места. И победителей выбирать нам все-таки пришлось. С довольно большим отрывом определилась явная тройка лидеров:

1 место: Сергей Гризан и Максим Кривов - Разработка примера использования библиотеки Intel® Threading Building Blocks.
2 место: Сергей Лесько - Набор сервисов для предотвращения образования автомобильных “пробок”.
3 место: Наталья Зайцева - Разработка физической модели разбиения твердого тела для игрового движка.

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

Вообще, все члены судейской комиссии были приятно удивлены профессиональным уровнем участников. Кто-то оставлял комментарии к статьям на сайте, кто-то лично нам при сообщении оценок. И мне хотелось бы привести несколько отзывов о работах победителей…и не только победителей. Положительные отзывы читать всегда приятно, и, думаю, все вы с ними согласитесь. Ребята действительно просто молодцы!

Разработка примера использования библиотеки Intel® Threading Building Blocks
Читается легко. Все понятно. Глубина смысла есть, сам давно хотел сделать универсальный асинхронный ввод-вывод, а, оказывается, все уже готово. Спасибо автору!
--Николай Куртов

Набор сервисов для предотвращения образования автомобильных “пробок”
Я был идеологом данного конкурса, и как-то заранее не подумал о том, что уровень аспиранта может существенно отличаться от уровня студента. Думаю излишне даже говорить о том, что и выбранная тема, и статья, весьма актуальны и очень востребованы.
--Дмитрий Оганезов

Разработка физической модели разбиения твердого тела для игрового движка
Весьма хорошее теоретическое введение в достаточно специфическую область, а также неплохой практический результат. Возможно работа будет полезна при создании демо-приложений для Larrabee.
--Дмитрий Марочко

Инструмент для поиска потенциальных возможностей проведения кэш-оптимизаций
Еще немного - и уровень статьи для журнала
--Валерий Курякин

Извлечение семантической информации из фотографий
Идея то хороша, да путь к ее реализации весь в терниях, в частности алгоритмы детектирования-распознавания оставляют желать лучшего… это работа не одиночки. Но - желаю успеха!
--Валерий Курякин

Сервис удалённого тестирования производительности ПО на различных программно-аппаратных конфигурациях
Было бы полезно. Ставлю 5 звёзд. Сам думал о такой идее, но несколько меньших масштабов. Доступ к множеству различных платформ имеют единицы, а тестировать было бы полезно.
--Дмитрий Вьюков

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

Всем удачи и роста...профессионального, конечно

Стоит заметить, что 3 ноября будет проведен Онлайн Семинар "Intel(R) Parallel Studio Workflow" на базе Tachyon. Количество участников ограничено.
Первый Шаг в расспараллеливание - это найти наиболее часто используемый участок программы. Для этого использовался Intel(R) Parallel Amplifier. И для сравнения удобства и простоты работы Intel(R) VTune(TM) Performance Analyzer. Как Amplifier так и VTune указали на функции:
grid_intersect и sphere_intersect.

Анализ данных функций показывает, что они не совсем пригодны к распараллеливанию или тюнингу. Соответственно нужно найти либо родительские либо дочерние функции, которые содержат циклы.
Для VTune пришлось собрать профиль Call Graph, на что ушло порядка 13 минут накладных расходов (время работы последовательного варианта Tachyon 30 сек). И 1 час на анализ профиля. У Ampilfier-а использовался уже созданный профиль, что оказалось очень удобным:

В результате мы остановились на кандидате parallel_thread:

static void parallel_thread (void)
{

    unsigned int serial = 1;
	unsigned int mboxsize = sizeof(unsigned int)*(max_objectid() + 20);
    unsigned int * local_mbox = (unsigned int *) alloca(mboxsize);
	memset(local_mbox,0,mboxsize);

    for (int y = starty; y < stopy; y++) { {
        drawing_area drawing(startx, totaly-y, stopx-startx, 1);
        for (int x = startx; x next_frame()) return;
     }

}

И пока я дописываю следующий Блог, предлагаю Вам самим попытаться распараллелить.

#include <iostream>
using namespace std;

template <typename T>
void PrintTypeInfo(char const* description, T)
{
  const type_info &info = typeid(T);
  cerr << "\"" << description << "\":"
       << " type = " << info.name()
       << "; sizeof = " << sizeof (T)
       << "; alignof = " << __alignof (T)
       << endl;
}

int _tmain(int, _TCHAR *[])
{
  char c1 = 0, c2 = 0;
  PrintTypeInfo("char + char", c1 + c2);
}

Результат:

"char + char": type = int; sizeof = 4; alignof = 4

Этой осенью совместно с академической программой мы впервые решили провести конкурс среди участников Летней школы Intel. И я надеюсь, вы внимательно следите за его ходом. Хотя, судя по комментариям к статьям, из всех завсегдатаев нашего сообщества в основном только Дмитрий (ksili) и Михаил (mt2) проявляют интерес к работам «школьников».

Если вы пропустили первый пост о конкурсе «Лето с Intel для профессионального роста», еще раз напомню, что участникам предлагалось рассказать о проекте или исследовании, над которым они работали этим летом в Intel, опубликовав техническую статью на нашем сайте.

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

Кстати, в этом году среди стажеров Летней школы были также и победители конкурса идей по разработке программных сервисов «Future? At your service!». И во время стажировки они занимались непосредственно реализацией своих идей. Евгений Павлов воплощал в жизнь веб-сервис, предоставляющий возможность извлечения семантической информации из фотографий, Шудрак Максим - сервис удаленного тестирования производительности ПО на различных программно-аппаратных конфигурациях. Интересные идеи и отличные результаты, учитывая, что реализовывать свои проекты ребята начали только в Летней школе. Как полагается, им пришлось составлять и бизнес-план своего проекта, в написании которого очень большую помощь оказал Василий Гурьев. В своей статье «Бизнеc-план IT-продукта: основные проблемы и пути их решения» он рассматривает структуру бизнес-плана и наиболее частые проблемы, возникающие при его написании. Возможно и вы найдете для себя что-то новое и полезное в этом кратком руководстве.

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