- Крюшо, в чем дело?
- Мы только что приехали!
- Вижу. А перед этим?
- А перед этим выехали..
(Жандарм и инопланетяне)

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

В этот раз речь пойдет об уже набившей оскомину диагностике “Mismatched Allocation/Deallocation”, которую выдает Inspector XE при анализе ошибок памями (Memory Checking). Простые жители Сан-Тропе недоумевают, почему в списке подозреваемых оказываются совершенно невинные объекты. В их действиях, видимо, совершенно нет ничего криминального. Ну посудите сами, где здесь нарушения и почему Инспектор подозревает в несовпадении парных операций выделения и уничножения объекта памяти в куче?

	Ray *p = NULL;
	const int nsize=4;
	CMemAllocTestDlg dlg;
	m_pMainWnd = &dlg;
	INT_PTR nResponse = dlg.DoModal();

	if (nResponse == IDOK){
		p = new Ray[nsize];	}
	else if (nResponse == IDCANCEL){
	}

	if (p != NULL)
		delete [] p;

Первой зацепкой в данном запутанном деле должно стать то, что в отчете Memory Checking анализа в поле Allocation Site (место выделеня памяти) указан не пользовательский модуль с кодом p = new Ray[nsize], а отладочная версия модуля mfc100.dll – его видно, если пойти вверх по стеку вызовов в Инспекторе. Это очень важная зацепка. Иногда ее может не быть, если например библиотека MFC, которая используется в приложении, расположена где-нибудь в нестандартном месте или вообще отсутствует в системных путях, и приставлена к программе в какой-нибудь директории.

Далее, пользуясь этой зацепкой, раскручиваем стек вызовов с помощью республиканской гвардии, то есть отладчика. Остановим выполнение программы на строчке с вызовом оператора new, и «прыгнем» в этот вызов. И что мы видим? Оказывается, коварные инопланетяне подменили всем известного и знакомого горожанина new своим железным макросом NEW_DEBUG,

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

который, если ему постучать кулаком по спине, отзовется гулким эхом _malloc_dbg (оканчивающийся вызовом имплементации функции malloc() с помощью HeapAlloc() в malloc.c):

Да, Инспектор прост и логичен: он, исследуя (следы преступления) исполнение кода сопоставил два оператора, которые выделяли и уничтожали объект. В первом случае new оказался подозрительным, был опрошен с пристрастием, и признался что он malloc. А вот во втором от встречает delete[], интерпретировал его как деаллокатор, о чем смело и рапортовал шефу.Он не стал раскручивать стек, так как внутренняи имплементация оператора его не интересует (а зря, так как имплементация delete тоже оканчивается вызовом HeapFree()).

Как не попасться Инспектору и избежать задержания и доставления в участок? Довольно просто. Нужно переопределить оператор new для ваших модулей, или убрать переопределение, которое установили инопланетяне при генерировании шаблона проекта в Visual Studio. Кстати, необходимо помнить, что заголовочный файл "afxtempl.h" тоже переопределяет этот оператор.

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

Cсылки на прошлые посты об Инспекторе:
Имеет ли Инспектор право на ошибку?
Куда смотрит Инспектор?
Когда Инспектор слишком строг
Когда Inspector мышей не ловит
Разгадываем загадку многопоточности
Загадочная многопоточность и Parallel Inspector

Спустя 6 лет после сильнейшего цунами, обрушевшегося на остров Ява, туристы снова потянулись на этот удивительный индонезийский остров. Все возвращается на круги своя. Многие пользователи старого доброго VTune Performance Analyser наверняка помнят, что в нем поддерживался анализ Java-приложений, хотя этот тип профилировки имеет довольно специфичное назначение. С выходом нового поколения продуктов Parallel Amplifier и VTune Amplifier XE, поддержка Java как-то исчезла из списка приоритетных задач и не была востребована пользователями. Но сейчас возник новый интерес к профилировке производительности «чистых» Java и особенно гибридных Java + нативных C/C++ приложений. Поэтому этот инструмент снова появляется в VTune Amplifier XE в дополнение к поддержке jit-компилированных приложений.

Итак, что же позволяет нам сделать профилировка Java-приложений. Основное назначение профилировки – это выявление функций или участков кода, которые больше всего занимают процессорное время, и определить, насколько эффективно они это делают. Не смотря на то, что код выполняется под управлением Managed Run Time Environment, оперирование данными в памяти может быть также неэффективным, как и в нативных приложениях. Например, учитывать кэш-иерархию системы памяти и скорость доступа к массивам в основной физической памяти системы можно и нужно при написании Java-кода. В этом смысле профилировка Java-приложения почти ничем не отличается от профилировки C/C++ приложения, кроме, наверное, того, что показатели производительности теперь надо отображать относительно исходного кода, который виртуальная машина (JVM) выполняла как ей заблагорассудится (либо скомпилировала, либо интерпретировала), и еще в специальном виртуальном адресном пространстве.

Тем не менее, в результате Hotspot-анализа мы получаем список самых «горячих» функций-методов, выполнявшихся в приложении, с временными характеристиками, а также стеки их вызовов. Обратите внимание, что распределение нагрузки по потокам тоже отображается в результатах, а именованые потоки помогают определить, где выполнялся «тяжелый» код.

Не секрет, что в приложениях, где некоторый функционал требует максимальной производительности на платформе, часто прибегают к такой хитрости: наиболее критичные участки программы пишут и компилируют на низкоуровневых языках, например на С или даже на ассемблере. Это делают чтобы задействовать некоторые архитектурные особенности процессора, например векторный вычислитель. Часто такие функции и являются хотспотами, так как берут на себя львиную долю вычислительной нагрузки. Но иногда нам необходимо определить, откуда они были вызваны, что может оказаться проблемой в гибридном коде, потому что часть алгоритма вычисления реализована в Java-коде, а С-код вызывается с помощью интерфейса JNI.

В результатах Hotspot-анализа вы увидлите, что VTune Amplifier XE «сшивает» стеки вызовов сделанных из Java-кода, и перенаправленных в нативный C-код. Впрочем, и обратные вызовы из С-модуля в Java будут отображены на панели стеков.

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

Тем, кто любит поковыряться в недрах процессорного конвеера и вычислительных блоках, предлагается Hardware Event-based Sampling анализ, который позволяет собирать процессорные аппаратные события, и по их соотношениям или метрикам (как встроенным, так и пользовательским) судить о тех или иных проблемах в очереди исполнения команд. Все результаты в виде Hardware Events и метрик доступны на уровне методов и исходного кода Java-программы.

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

Иногда JVM предпочитает некоторые не часто вызываемые методы проинтерпретировать, так как компиляция требует большего времени. Символы таких функций мы пока не умеем надежно определять, поэтому они будут заменены на символ “!Interpreter” в стеке вызовов. Если вам необходимо увидеть эту функцию в стеке, заставьте JVM скомпилировать все методы опцией “–Xcomp”. Хотя и в этом случае нет гарантии появления символа в стеке, так как некоторые функции могут быть «заинлайнены».

Есть ли еще какие-либо ограничения в анализе Java-приложений? Конечно же есть. Поддержать все многообразие Java Runtime Environment (JRE) довольно сложно, поэтому мы остановились на поддержке Oracle* Java 6 и 7. Кроме того, профилировка полностью поддержвается в рамках Hotspot-анализа, и анализа на основе Hardware Event-based Sampling (например Lightweight Hotspot), а Cuncurrency-анализ ограничен тем, что некоторые встроенные в Java примитивы синхронизации (которые не вызывают напрямую объекты синхронизации ядра ОС) мы не сможем распознать, вследствие чего, некоторые временные характеристики могут быть искажены. Тоже самое относится и к Locks&Waits анализу. Пользователь пока не может прикрепиться инструментом к jre-процессу во время исполнения и у нас нет специальных библиотек, поддерживающих User API для управления коллекцией в коде Java-приложений. Но особо настойчивые могут попытаться «прикрутить» обычный API для С-программ, обернув соответствующие _itt вызовы JNI-функциями.

Ну и маленький совет тем, кто профилирует Java-приложения под Linux: на linux x86 платформах используйте клиентскую JVM, а не серверную, или специфицируйте опцию “–client” в командной строке.

Об эти ошибки пришлось изрядно поломать голову, прежде чем я сообразил, что мы имеем дело с OpenMP run-time от Microsoft*. Вернее я не сообразил, мне подсказали.

Что ж, в удаленном анализе приложения клиента есть свои недостатки. Именно поэтому сообщение Инспектора при старте анализа в окне вывода я не видел, да и про и свою же статью по этому поводу успешно забыл (да, так бывает).

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

Итак, с чего же начать? Прежде всего необходимо скачать и установить последнюю версию Intel® Composer XE 2011 (пакет, в который входит профессиональная версия C++ компилятора Intel). Кстати, можно обойтись и более бюджетным Intel® Parallel Composer 2011.

Дальше я приведу пошаговую инструкцию, применительно для С/С++ проекта, разрабатываемого в Microsoft* Visual Studio 2008. В проекте необходимо произвести изменения в установках среды разработки, которые позволят импользовать библиотеку совместимости OpenMP от Intel. Для 64-битного проекта, в Debug-режиме, при динамической линковке OpenMP-библиотеки необходимо сделать следующее:

1. Определите символ _OPENMP_NOFORCE_MANIFEST в свойствах проекта (Property Pages): C/C++ >Preprocessor > Preprocessor Definitions

2. В свойствах проекта установите путь к библиотеке Intel OpenMP: Linker > General > Additional Library Directories установите <Intel_Сomposer_installation_path>\compiler\lib\intel64\

3. Сделайте библиотеку Intel OpenMP доступной для отладки: Debugging > Environment установите PATH=%PATH%;<Intel_Сomposer_installation_path>\redist\intel64\compiler\

4. Добавьте имя библиотеки Intel OpenMP в опции линковщика и исключите библиотеку Microsoft OpenMP которая используется по-умолчанию:
Linker > Input > Additional Dependencies установите libiomp5md.lib
Linker > Input > Ignore Specific Library установите vcompd.lib

5. Удостоверьтесь, что установлена опция поддержки OpenMP в проекте: C/C++ > Language > OpenMP Support установите Yes(/openmp)

6. Удостоверьтесь, что установлена опция многопоточной библиотеки run-time: C/C++ >Code Generation > Runtime Library установите Multi-threaded Debug DLL (/MDd)

Вот и все. Проект можно продолжать компилировать с использованием компилятора Visual C++, при этом управлением OpenMP-потоками займется библиотека Intel OpenMP run-time, а Intel Inspector будет выдавать более-менее вменяемые результаты анализа ошибок многопоточности.

- Слава Богу, дело ведёт инспектор Лестрейд. Газеты пишут - лучший инспектор.
- Инспектор Лестрейд - самодовольный осёл, миссис Хадсон.
- Так пишет «Таймс»…

Несколько моих последних записей, посвященных Инспектору, раскрывали некоторые «особенности» и стиль его работы. Больше всего внимания на страницах вечерних газет уделялось его эффективности обнаружения ошибок памяти. Надо сказать, что в Скотланд Ярде его считают не таким уж и плохим профессионалом. Да что там неплохим, лучшим.. Однако находятся выскочки, которые считают себя гениальными и незаслуженно лишенными славы на страницах уголовных хроник. В прошлом, они не раз пытались копнуть под Инспектора и опорочить его профессиональную репутацию. Что ж посмотрим, что они нам предъявляют на этот раз.

На этот раз суть претензий к Инспектору состоит в том, что он не обнаруживает утечки памяти в глобальных, либо статических объектах, которая была выделена в «куче», то есть с помощью операторов malloc или new. Другими словами, если глобальный или статический объект, содержащий в себе указатели на память, выделенную в «куче», не позаботится об ее освобождении, то Инспектор не находит в этом ни какого криминала.

Вот небольшой пример:

namespace{
  struct GObj {
    GObj():m(new int()){
    }
    ~GObj()
    {
    // так делают настоящие джентльмены
    // delete m;
    }
  int * const m;
  };

  static GObj obj;
}

int main()
{
  GObj obj;
  // ой, мы забыли освободить память
  return 0;
}

Слово Инспектору:

Инспектор обнаруживает утечку памяти, и даже указывает функцию конструктора сруктуры, где память была выделена:

Однако, в виду простоты кода, нам не сложно заметить, что, если пройти по стеку вниз, то диагностика утечки соответствует созданию объекта в obj в функции main():

- А как же объект, созданный глобально? Почему в нем не обнаружена утечка?
- Элементарно, Ватсон. Глобальные и статические объекты существуют в памяти и после выхода управления из функции main(), а значит потерянными не считаются.
- Что же тогда считается потерянной памятью?
- Мой дорогой доктор, настоящий детектив ищет ответ на вопрос, «какие из объектов памяти, выделенные с помощью функций malloc() или new(), которые не были освобождены с помощью функций free() или delete(), не доступны процессу по любой цепочке указателей, находящихся в глобальном или статическом объекте». Так что в этот раз наш Инспектор оказался прав.

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

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

Вот например:

#include <stdio.h>

namespace
{
  int * a;
}
int main()
{
  a = new int(5);
  int* b = a;

  printf("%d\n", *b);
  return 0;
// упс, попользовались памятью по
// указателю b и забыли про нее
}

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

Теперь вопрос к Титанам. Почему это так важно, соблюдение Инспектором данного правила? Ведь процесс все-равно заканчивается с выходом из функции main(), и память потеряна. В чем тут может быть загвоздка?

Следствие продолжается...

(Ричард Дейли, мэр Чикаго)

Продолжаю общаться с Инспектором и находить все новые случаи вроде бы парадоксального поведения. Теперь это будет Memory Checker. Проверяем ошибки работы с памятью, выделенной на стеке.

Собственно данная тема, возможно, будет интересна только Титанам, активно использующим фунции проверки памяти с помощью Intel Parallel Inspector. Интересно было бы узнать, возникает ли такая проблема с другими инструментами проверки памяти.

Пример, как всегда, пришел от одного из наших радиослушателей. Законопослушный гражданин недоумевает, почему Инспектор пропускает случаи вопиющего использования неинициализированной памяти без каких либо санкций. Злоумышленники, конечно, замаскировали некорректное использование переменных под объект С++ класса, но это же не должно останавливать всевидящего Инспектора. При этом, в случае простого и очевидного нарушения, Инспектор тут как тут. Может он просто недостаточно компетентен, и ему требуется внеплановая переаттестация? Пришлось провести внутреннее служебное расследование, и я хотел бы поделиться с Титанами его результатами.

Ниже представлен пример кода, в котором допущены две ошибки доступа к неинициализированной памяти в стеке. Если в первом случае с переменной x инспектор рапортует об ошибке, то в случае вызова метода GetValue(), который возвращает неинициализированную переменную fp_value член класса CTest, никакой диагностики не наблюдается.

class CTest
{
public:
	CTest(){};
	double GetValue() {
	return fp_value;
}
private:
	double fp_value;
};

int main() {

int x;
int y = x + 1;//Uninitialized Memory Read

CTest test;
double z = test.GetValue();//Инспектор не реагирует
printf("%f\n",z);

return 0;
}

Первой ниточкой, за которую мы потянули в процессе расследования, было сообщение run-time библиотеки:

Значит, по-умолчанию у нас была включена опция копилятора RTCu, которая включает run-time check. Да и в процессе компиляции мы получили соответствующее сообщение относительно переменной x.
А что же с fp_value? Придется поднять дело, то есть залезть в дизассемблер, и посмотреть, что там натворили в соседнем отделе, в Компиляторе (ну, скажем так, в смежном соседнему отделу, так как код собирался компилятором Microsoft – требование радиослушателя). А там все очень интересно:

	double GetValue() {
004114D0  push        ebp
004114D1  mov         ebp,esp
004114D3  sub         esp,0CCh
004114D9  push        ebx
004114DA  push        esi
004114DB  push        edi
004114DC  push        ecx
004114DD  lea         edi,[ebp-0CCh]
004114E3  mov         ecx,33h
004114E8  mov         eax,0CCCCCCCCh
004114ED  rep stos    dword ptr es:[edi]
004114EF  pop         ecx
004114F0  mov         dword ptr [ebp-8],ecx
	return fp_value;

При включении run-time check, библиотека сама инициализирует переменные на стеке, и поэтому Инспектор, анализирующий код в процессе исполнения, никак не реагирует, так как никаких нарушений нет.
Если посмотреть на инструкции, сгенерированные компилятором, то можно увидеть, как в регистр eax загружается шаблон инициализации 0CCCCCCCCh, а следующая инструкция rep stos dword ptr es:[edi] уже заполняет стек содержимым регистра eax. Если же мы отключим опцию проверки, Project Properties -> C/C++ -> Code Generation -> Basic Runtime Checks: Default, то Инспектор сразу же обнаруживает непорядок (уровень mi4), и сообщает об этом куда надо:

Вызов метода GetValue() в данном случае выглядит в дизассемблере следующим образом:

double GetValue() {
004112F0  push        ebp
004112F1  mov         ebp,esp
004112F3  sub         esp,44h
004112F6  push        ebx
004112F7  push        esi
004112F8  push        edi
004112F9  mov         dword ptr [ebp-4],ecx
	return fp_value;

Инструкция sub esp,44h резервирует зачем-то много места на стеке (по-моему, слишком избыточно для объекта класса), но память ничем ни инициализируется. Это и не прошло мимо внимательного Инспектора, поэтому он зафиксировал нарушение.

Однако, наш бдительный радиослушатель не унимался. Он сообщил, что если перекомпилировать пример в релизном режиме (опция run-time check при этом выключается), инспектор снова не желает замечать очевидное. Мы проверили и установили: да, не желает. Поэтому пришлось подключать наши лучшие силы, и искать правильный след с собаками.

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

int main() {
00401000  push        ebp
00401001  mov         ebp,esp
00401003  and         esp,0FFFFFFC0h 

int x;
int y = x + 1;//Uninitialized Memory Read

CTest test;
double z = test.GetValue();//Инспектор не реагирует
printf("%f\n",z);
00401006  fld         qword ptr [esp-8]
0040100A  sub         esp,40h
0040100D  sub         esp,8
00401010  fstp        qword ptr [esp]
00401013  push        offset string "%f\n" (4020F4h)
00401018  call        dword ptr [__imp__printf (4020A0h)]
0040101E  add         esp,0Ch 

return 0;
00401021  xor         eax,eax
}
00401023  mov         esp,ebp
00401025  pop         ebp
00401026  ret

Обратите внимание на связку инструкций:

sub esp,8
fstp qword ptr[esp]

Похоже, что первая резервирует место на стеке под объет класса. А вторая копирует в стек величину, находящеюся на вершине FP-стека, то есть совершенно случайное значение. Получается, что компилятор соптимизировал программу так, что и объект класса CTest test и его переменная-член класса d занимают одно и тоже место на стеке. А вторая инструкция может интерпретироваться либо как инициализация по-умолчанию объекта test, либо как присвоение значения переменной d. Ну а так как оба находятся по одному и тому же адресу в стеке, можно считать, что инструкция оптимально сразу обоих и инициализирует. От этого чтение переменной d в функции printf не приводит Инспектора к заключению, что имело место быть Uninitialized Memory Access на стеке.

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

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

Я для HPC индустрии человек скорее сторонний, хотя и участвую в различных семинарах по HPC, однако основной диапазон моих интересов лежит в области софта, а не железа. Поэтому, возможно, кому-то будет интересен «свежий» взгляд на то, что происходило на симпозиуме.

Во-первых, скажу, что это довольно закрытая «тусовка», где представлены различные участники рынка: университеты (как обладатели самых мощных кластерных установок), промышленность (как самые естественные потребители и заказчики готовых систем) и производители (как интеграторы, так и поставщики компонент, каким, например, является Интел ). Все представители занимают довольно высокое положение в своей области, и определенно имеют какое-то влияние на ход событий в индустрии. Для примера, скажу, что МГУ представлял Владимир Воеводин, заместитель директора НИВЦ.

Во-вторых, участники давно друг друга знают благодаря и этой конференции и другим, типа ПаВТ, и это была одна из задач прошлых симпозиумов – свести все три ветви заинтересованных лиц в одно место и добиться установления плотного контакта между ними. Правда на нынешнем, юбилейном (4-м, h100) симпозиуме, на первый план вышла тема софта для HPC, что безусловно является правильной тенденцией.

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

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

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

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

Представители университетов сами согласны с тем, что активных профессоров, занимающихся данной тематикой, и готовых предложить методику предподавания, в стране можно пересчитать по пальцам одной руки, и естественно это крайне удручающая ситуация. Тут можно было бы найти точку соприкосновения университетов и компаний, таких как Интел, которая готова тратить свои ресурсы на обучение преподавателей. Как положительный шаг, было озвучено успешное создание СУПЕРКОМПЬЮТЕРНОГО КОНСОРЦИУМА УНИВЕРСИТЕТОВ РОССИИ, основателями которого являются четыре ведущих (в этой теме) университета Росиии, и в состав которого входят уже более двух десятков. Президент Консорциума - ректор Московского государственного университета им. М.В.Ломоносова, вице-президент РАН, академик В.А.Садовничий. Можно надеяться, что результатом работы Консорциума станут в том числе и новые специальности, которые бы готовили профессионалов для нашей индустрии.

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

P.S. Владимир Воеводин попросил перенести его доклад на более раннее время, так как спешил закончить приготовления, связанные с мероприятием, которое произошло на следующий день. Думаю, многие видели новости.