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

В далеком 2008 году мои коллеги уже обращались к авторам сообщества с призывом придумать надпись для футболок, но чем закончилось дело я не знаю.

Итак, в этот раз всё серьезно и более свободно.

Наверняка, у вас есть идея для клёвой футболки блогера/участника ISN. Мы можем воплотить ее в жизнь!

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

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

Самую лучшую идею мы воплотим в жизнь (а это значит, что более 50 человек будут носить на себе ваше творение), а автору идеи, а также самому активному на наш взгляд участнику, отправим свежеиспеченные футболки, как только они приедут к нам из типографии.

Таймлайн: обсуждение лучшей футболки не закончится никогда, но выбирать лучший вариант мы будем 9 марта, сразу после праздников (чтобы веселее было )

До встречи в форуме!

P.S.: Тому, кто догадается, почему мы не предлагаем публиковать картинку в комментариях к этой записи, плюс в карму

P.P.S.: Не воспринимайте последний вопрос серьезно, ответ лежит на поверхности и не отличается уникальностью

Numa система на MTL.

На MTL стоит 256 ГБ оперативной памяти, но в системе 4 процессора Xeon, каждый из них имеет прямой доступ только к своим 64 гб оперативной памяти, а доступ к остальным 192 гб занимает вдвое больше времени.

node 0 size: 64485 MB
node 1 size: 64640 MB
node 2 size: 64640 MB
node 3 size: 64640 MB

node distances:
node 0 1 2 3
0: 10 21 21 21
1: 21 10 21 21
2: 21 21 10 21
3: 21 21 21 10

Распределение процессоров по узлам(40 - 79 есть только на логин сервере, где включен HT):

node 0: 0-9, 40-49
node 1: 10-19, 50-59
node 2: 20-29, 60-69
node 3: 30-39, 70-79

Естественно хочется избегать ситуаций, когда процессор лезет в чужую память. Возможно, OpenMP разбирается с такими проблемами автоматически, но своё решение я писал с помощью pthreads и для них решение проблемы оказалось следующим:

1. При вызове malloc отображение виртуальной памяти на физическую ещё не строится.
2. Когда какой-то процессор обращается к куску памяти, для которого отображения ещё нет, это отображение строится на память в Numa узле этого процессора.
3. Поэтому выгодно генерировать в каждом потоке ту часть матрицы, которая будет им чаще всего использоваться, осуществить эту параллельную генерацию нам позволяет наличие периода в матрице. В общем случае пришлось бы делать memset своего куска матрицы в каждом потоке, и только потом генерировать всю матрицу в каком-то одном потоке.
4. Для того, чтобы потоки не бродили по процессорам и тем более по numa узлам, нужно их привязать к конкретным процессорам. Например, можно привязать поток номер k к процессору номер k, это даст ещё одно преимущество - мы будем знать у каких потоков есть разделяемый кэш и можем более эффективно распределять операции. В случае pthreads привязка потока к процессору осуществляется при помощи библиотеки sched.h:

CPU_ZERO(&affinity);
CPU_SET(args->thread_number, &affinity);
sched_setaffinity(0, sizeof(cpu_set_t), &affinity);

Блочный метод.

Даже разобравшись с Numa системой, векторизация не даст никакого ощутимого выигрыша, пока мы не начнём по максимуму использовать кэш. Если написать стандартный метод Кадана в 3 цикла, то по сути никакие уровни кэша, кроме L3, программа использовать не будет. Естественно эта ситуация нас не устраивает, хочется изменить порядок, в котором мы обрабатываем элементы матрицы, чтобы каждый элемент, который мы положим в кэш, оставался там как можно дольше. Например, можно сделать метод Кадана блочным, т.е. выбрать некоторые размеры блока A и B, и работать с блоком, как с неделимой операцией, алгоритм в таком виде примет сложность 0.5 * (N/A)^2 * (M / B) * (A^2 * B). Естественно, сложность осталась прежней, но (A^2 B) - операции, в которых процессор не будет лезть дальше собственного кэша, и естественно эти операции будут работать эффективнее, чем если бы процессор всегда лез в оперативную память или L3 кэш. Осталось заметить только то, что блоки нужно заводить не одной операцией malloc(), а каждый поток должен сделать malloc() своих блоков. В Linux malloc() автоматически округляет выделенную память до ближайшей степени двойки, что позволит нам избежать эффекта false sharing.

Что же это дало?

По сути описанные выше 2 оптимизации не дают огромного прироста в скорости, но после них становится возможной эффективная векторизация, которая и даст желаемый прирост в скорости, в моём случае - в 3 раза. Так же стоит отметить, что при небольших периодах есть гораздо более эффективные методы, например за O(m^3), которые используют гораздо меньше памяти. Данные оптимизации рассчитаны скорее на задачу в общем случае, нежели на конкретную постановку.

Источники:

1. Об оптимизации вычислительных приложений для многопроцессорных систем с общей неоднородной памятью
2. Memory in a Linux/NUMA System

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

В качестве примера рассмотрим массив А размера N и некоторый алгоритм на ней:

for (int i=0; i<N; ++i)
     // Do something with A[i]

Казалось бы, что всё отлично. Но, допустим, мы решили распараллелить этот алгоритм на n-ядерном процессоре с помощью любой технологии типа OpenMP, TBB. Тогда при достаточно больших N получится, что первый поток работает над куском массива от 0 до 100000, второй - от 100000 до 200000, и т.д. На самом деле мы можем не получить никакого прироста в скорости, потому при таком подходе в кэш процессора будут поочерёдно загружаться/выгружаться данные, локальные для первого потока, потом для второго, потом снова для первого и т.д. Гораздо лучшим подходом будет переписать код следующим образом:

for(int t=0; t<N/tileSize; ++t)
    for(int i=tileSize * t; i < tileSize * (t+1); ++i)
        // Do somethin with A[i]

Здесь также будем параллелить цикл по i. Визуально вместо одного простого цикла получили 2 вложенных, однако, очевидно, что они выполняют одинаковое число операций, с той лишь разницей, что теперь все данные, необходимые в цикле по i, находятся "недалеко" друг от друга. Понятие "недалеко" регулируется параметром tileSize. Теперь, удачно подобрав этот параметр, можно добиться того, что все элементы массива А, нужные в цикле по i, сразу попадут в кэш процессора и таким образом все потоки будут работать с одним и тем же куском памяти, который не нужно будет постоянно загружать или выгружать из памяти.

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

Более приближенные к практике примеры можно найти на вики http://en.wikipedia.org/wiki/Loop_tiling
Вот и всё на сегодня, всем удачи в параллельных алгоритмах!

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

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

В данном направлении я вижу 3 подхода:

1. Сгенерировать некоторый набор данных и отдать программам в качестве входных. Но тут возникает следующая проблема: если данные для обработки являются достаточно большими по объему, то время работы программы может упереться в считывание данных для обработки (не будем забывать, что операции с жестким диском являются достаточно медленными и парсинг данных тоже занимает время). И в таком случаем победителем может оказаться не тот, кто сделал лучшее решение задачи, а тот, кто смог лучше распарсить данные.
2. Предоставить алгоритм некоторого псевдослучайного генератора входных данных, который на основе пары параметров генерирует все необходимые данные. При этом использовать особенности генерации запретить сложно, в силу того что полученный код может быть очень запутанным и проверить его достаточно затруднительно. Данный метод лишён недостатка предыдущего, однако, тоже не идеален. При выборе псевдослучайного алгоритма генерации у него могут оказаться особенности, о которых организаторы даже не подозревали. И в итоге можно получить от конкурса не совсем ожидаемый результат. В частности лучшие решения вообще не будут применимыми на исходной задаче. При этом изменение алгоритма генерации может достаточно сильно рассторить участников, которые использовали его недостатки. Например в конкурсе Acceler8 2011 такой неожиданностью оказались проблемы с генерацией матрицы линейным конгруэнтным методом. В результате чего при больших размерностях задачи, матрицы в большинстве случаев получалась вырожденной и решалась в разы проще. Кстати данная проблема, в той или иной мере, осталась и после изменения способа генерации.
3. Попросить участников написать функцию/класс принимающую входные данные и возвращающая результат. Данный подход позволяет организаторам засекать время непосредственное время исполнения программы и использовать различные алгоритмы генерации данных, или же даже ввод из файла не влияя на решения участника. Но у него есть другие недостатки, а именно - если данные достаточно большие, то участник лишён возможности расположить их удобным для его алгоритма образом (т.к. 2 копии данных могут просто не влезть в память), а также данный метод не подходит для случаев когда данные просто не влазят в память и их необходимо обрабатывать по частям. В частности это может лишить участника некоторых полезных оптимизаций.

Теперь немного о возможных применениях данных методов и потенциальным решениях их проблем:

1. Отлично подходит для сложных задач с малым входом.
2. Можно решить часть потенциальных проблем увеличив число алгоритмов генерации данных. Действительно подходит для задач с огромными данными.
3. Отлично подходит для большого класса потенциальных задач.

Удачного проведения конкурсов!

Описание проблемы

Итак, необходимо сгенерировать последовательность

x[n+1] = (a * x[n] + b) % m, где x[0] = (a * seed0 + b) % m.

Тут a, b, seed0 и m - параметры генерации. Рассмотрим здесь лишь случай НОД(a-1, m) = 1. Случай, когда НОД(a-1, m) делит b, может быть сведён к предыдущему, а все остальные дают вырожденную длину цикла. Последний случай тоже интересен, но его анализ будет предложен к самостоятельному анализу читателя, дабы не загромождать пост. Более подробно о различных параметрах генерации и аспектах практической реализации можно прочесть в работе [1]. Далее обсуждаемый алгоритм генерации будем называть алгоритмом Лемера (согласно [1] впервые он был предложен Д. Х. Лемером).

Цель данного поста - показать возможность параллелизации генерации, а также указать практические аспекты реализации.

Параллельная генерация

Дальнейшие соображения верны в случае НОД(a-1, m) = 1. Более того, все выкладки приведены для простого m. В случае составного m, m-1 необходимо заменить значением функции Эйлера от m - это также сделано для простоты.

Модификация задачи
Здесь будут использованы результаты из прикладной алгебры без формулировок и доказательств, однако источника [1] вполне достаточно, чтобы разобраться. Впрочем, автор надеется, что читатель сможет ограничиться нижеприведенными короткими рассуждениями.

Рассмотрим следующее элементарное алгебраическое преобразование:

y(n) = (x(n) + c) % m

При этом выберем такое c, чтобы выполнялось

y[n+1] = (a * y[n]) % m

Из алгоритма Лемера получим

(x[n+1] + c) % m = (a * x[n] + a * c) % m

откуда сразу получим выражение для с:

c = (inv(a - 1) * b) % m

Здесь inv(a - 1) - означает обратный элемент к a - 1 по модулю m: ((a - 1) * inv(a - 1)) % m = 1. Несложно показать, что

inv(a - 1) = ((a - 1)^(m - 1)) % m

Таким образом, c может быть найдено за log(m), поскольку inv(a - 1) может быть найден за log(m). Эти очевидные размышления приведены для того, чтобы показать, что подготовительные вычисления не сводят на нет предложенную вычислительную схему.

Наконец, окончательная формула для вычислений x[n] следующая:

y[n+1] = (y[n] * a) % m = (y[1] * a^n) % m

и

x[n] = (y[n] + (-c)) % m = (y[n] + m - c) % m

Тут (-c) = m - c. А c = ((a - 1)^(m - 1) * b) % m, как показано выше.

Параллелизация
Пусть мы хотим распараллелить вычисления на k процессоров. Вычислим m - c, а также y[1], y[2], ..., y[k] и ak = (a^k) % m.

Разделим всю задачу на k задач: i-тая задача заключается в вычислении x[i+k], x[i+2*k], ... . Для подсчёта каждого следующего элемента необходимо единственное умножение по модулю m: y[i+k] = (y[i] * ak) % m, и сложение x[i+k] = (y[i+k] + (m - c)) % m.

Сложность
Сложность каждой задачи порядка m/k. Заметьте, что длина цикла не более m, поэтому достаточно сгенерировать m первых элементов, а затем скопировать повторения до конца массива. При этом, среднее значение элементов массива может быть посчитано для всего массива через сумму элементов цикла (и тех, разумеется, что, возможно, идут перед его первым вхождением в массиве), и отнято от элементов цикла перед копированием (см. детали генерации в условиях конкурса). Такой подход позволяет ускорить процесс генерации даже без распараллеливания.

Практические аспекты

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

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

Используемая литература

1. Кнут Д. Искусство программирования для ЭВМ: пер. с англ.– М.: Мир, 1977.– Т.2.

Может ли "очевидная" оптимизация кода привести к падению производительности? Как я убедился на собственном опыте - да!

Вот фрагмент программы которая ищет максимальную подматрицу методом Кадане:

for (int x = 1; x < w; x++) {
  int v = row_y2[x] - row_y[x];
  if (local_sum > 0) local_sum += v;
  else local_sum = v;
  if (local_sum <= best_sum) continue;
  best_sum = local_sum;
  best_x2 = x;
  best_y1 = y;
  best_y2 = y + span;
}

"В коде обновления лучшей суммы явно есть лишние действия" подумал я. И переписал так:

int _x = -1;
for (int x = 1; x < w; x++) {
  int v = row_y2[x] - row_y[x];
  if (local_sum > 0) local_sum += v;
  else local_sum = v;
  if (local_sum <= best_sum) continue;
  best_sum = local_sum;
  _x = x;
}

if (_x != -1) {
  best_x2 = _x;
  best_y1 = y;
  best_y2 = y + span;
}

Однако скорость работы внезапно упала на 30%. В чем дело? Смотрим на профиль исходного кода:

И на профиль полученного:

Вот оно в чем дело! Компилятор решает, что ветка кода обновления лучшей суммы стала насколько дешевой, что ее можно рассчитывать на каждой итерации цикла.

С этого момента я стал делать только одну оптимизацию за раз и постоянно проверять, что она реально приносит пользу.

Удачи!

На очередной виртуальной сессии Игорь Воробцов расскажет об Intel® VTune™ Amplifier XE 2011. Этот инструмент входит в состав пакета Intel® Parallel Studio XE 2011 и является новейшим профилировщиком производительности. Вы узнаете как о новых возможностях инструмента, так и о дополнительном функционале, специально предназначенном для разработчиков игр. Вы узнаете о такой интересной функциональной возможности, как анализ кадров для фильтрации результатов профилировки производительности с целью получения информации, на основании которой могут быть предприняты конкретные действия. Эта функция основана на потребностях видеоприложений (таких как игры) и должна соответствовать критериям задержки для каждого видеокадра. Она реализована с использованием общей методики и может быть полезна и в других приложениях, например, в симуляторах циклов.

Регистрируйтесь на сайте intelcorp.regsvc.com/E6129, чтобы изучить основные возможности и функциональность инструмента.

Если вы не смогли посетить 1-ый вебинар серии, видео-запись можно посмотреть и скачать в нашем Take 5 видео-репозитории.

Мы решили продолжить работу в этом направлении. И вот с 14 октября на ISN стартует серия из четырех вебинаров, посвященных вопросам производительности графических приложений. Презенторы – наши инженеры, которые ежегодно на Конференции Разработчиков Игр делятся экспертными знаниями и практическим опытом в сфере оптимизации приложений.

В эту пятницу Кирилл Рогожин расскажет о том, как эффективно использовать библиотеку Intel® Threading Building Blocks для распараллеливания кода. Эта библиотека призвана облегчить работу программистам и позволяет сфокусироваться на особенностях своего приложения, а не "изобретать велосипед". С TBB вы сможете сосредоточиться на основных функциях приложения, а не на организации и отладке многопоточной работы.

Через неделю, 21 октября, вас ждет виртуальная сессия, посвященная инструменту Intel® VTune™ Amplifier XE 2011, который является новейшим профилировщиком производительности. Игорь Воробцов представит новые возможности и функциональность VTune™ Amplifier, такие как временная линия потоков, статистическое дерево вызовов, мультиплексирование событий, а также ряд дополнительных функциональных возможностей, специально предназначенных для разработчиков игр, которым нужен более комплексный подход. Использование инструмента Intel® VTune™ Amplifier XE 2011 будет продемонстрировано на примере работы с игрой «Total War: Empire».

На двух последних вебинарах Виктория Жислина расскажет о том, как учитывать особенности CPU (устройство кэш-памяти, предсказание ветвлений, out-of-order исполнение, SIMD инструкции, включая Advanced Vector Extensions) для создания максимально оптимизированных приложений, а также о схеме построения игрового движка на основе задач (tasks).

Ознакомиться с расписанием и зарегистрироваться на вебинары можно на этой странице. Регистрация на последние два вебинара серии откроется в самое ближайшее время.

Регистрируйтесь, следите за обновлениями и приходите на наши виртуальные сесии. Увидимся в эту пятницу!

Мероприятие получилось одновременно и уникальным, и знаковым. Понимаю, насколько заезжены эти определения, но все же употреблю их, потому что точнее-то не скажешь. Еще ни разу на моей памяти Intel не собирала в России больших конференций для разработчиков, где бы говорилось только программных продуктах. О них обычно было вскользь, после «железа». Теперь же главной героиней стал набор программных средств Intel® Parallel Studio XE с пакетом обновления SP1, а о «железе» вспоминали только если приходилось к слову.

Открывавший конференцию Камиль Исаев, генеральный директор по исследованиям и разработкам Intel в России и СНГ, начал, конечно же, с более глобальных вещей, о чем можно было предположить еще по первому слайду презентации с названием доклада – «Вычислительный континуум и роль программного обеспечения». Камиль говорил о роли программного обеспечения в приближающуюся эру экзафлопных вычислений и о весьма ощутимом вкладе российского подразделения SSG в создание удобных и добротных инструментов для разработчиков.

Специально приглашенной звездой ISC2011 стал Роберт Гева, старший ведущий инженер Intel SSG (вот такие бывают должности). Именно он был изображен на всех баннерах конференции, которая, к слову, рекламировалась, словно рок-концерт. Если, конечно, бывают рок-концерты для программистов. С Робертом у меня связана небольшая история. Во всех материалах конференции его представляли, как американца. Однако по его английскому было очень заметно, скажем так, иностранное происхождение, а мягкое «л» заставляло вспомнить о Ближнем Востоке. Я набрался наглости, подошел к Роберту поинтересовался – откуда он родом? Ну и потом мы отлично поговорили на иврите. Некоторые участники нашего сообщества потом подшучивали – мол, откуда еще быть человеку с фамилией Гева? Так-то оно так, коллеги, но Робертов я среди израильтян-сабр прежде как-то не встречал.

В своем докладе Роберт Гева говорил о средах разработки программного обеспечения, которые поддерживают инструменты Intel, и об их будущем. Затронул общие вопросы развития программного обеспечения, особенности инструментов для высокопроизводительных вычислений и интегрированных решений. Кроме того, Гева рассказал об операционных системах Linux, Windows, Mac OS X и MeeGo и представил прогнозы Intel по каждой из них.

О других докладах я писать, пожалуй, не рискну, боясь исказить пересказом серьезный смысл, и приглашаю посетить страничку с названием каждого из них и краткой аннотацией. Знаете, что на меня произвело самое большое впечатление? Неослабевающее внимание участников. Часто ведь как бывает? Собрался народ с утра, получил раздаточные материалы и сувениры, кое-как досидел до обеда, перекусил, и ищи ветра в поле. А на ISC2011 в Москве большинство участников слушало до последнего, да и в Питере, говорят, была похожая картина.

Значит действительно интересные вопросы подняли, и рассказывали хорошо. Не комом первый блин. И если в будущем конференция распространится на Новосибирск или, скажем, Екатеринбург, я бы с удовольствием последовал за ней

Курсируя по трем десяткам павильонов IFA чувствуешь себя старателем, тщетно пытающимся отделить собственно цифровую технику от кухонных комбайнов, пылесосов, стиральных машин и электрических чайников. Нет, я понимаю, что домашние приборы тоже стали очень-очень умными, но все же, как ни крути, компьютеры их опережают в развитии побольше, чем иной человек обезьяну. Пожалуй, из тех устройств, что показывались впервые, здесь стоит упомянуть «ультрабук» Acer Aspire S3 и «четырехъядерную» звуковую карту Creative.

Первый – это вариация на тему MacBook Air, только изначально заточенная под более солидные тиражи. Магний-алюминиевый сплав, интегрированный твердотельный накопитель небольшой емкости, улучшающий пользовательские впечатления от обычного HDD и, наконец, Core i3/i5/i7 второго поколения. Выглядит – ух! Единственное, что пока немного смущает – цена в России, которая поначалу составит не менее 30 000 рублей. Дороговато, чего уж говорить. Но, с другой стороны, нельзя не радоваться, что у Acer появляется действительно легкий и при этом прочный ноутбук, а то в декабре прошлого года мне пришлось изменить сложившимся издавна симпатиям и купить для командировочных нужд Lenovo ThinkPad. Впрочем, сказать о последнем хоть что-то недоброе у меня язык не повернется, машина - огонь.

Вторая новинка – Creative SoundBlaster Recon 3D. Пока ничего конкретного об этой звуковой карте сказать нельзя: в магазинах ее не продают, технические детали не обнародованы, а на выставке в нюансы звука особенно не погрузишься. Важно другое: впервые на моей памяти главным преимуществом и отличием звуковой карты маркетологи назвали… многоядерность! Так и пишут: первый в мире четырехъядерный звук, полученный на первом в мире четырехъядерном DSP. И хотя я уже давно пользуюсь интегрированными решениями, эту карту куплю непременно – уж очень интересно послушать и сравнить с предшественницей X-Fi. Да и цену на базовую модель выставили довольно гуманную, всего 90 евро. Помнится, раньше аппетиты Creative были посерьезнее.

Погуляв полдня по IFA, я садился в такси и отправлялся в крупнейшие берлинские магазины, торгующие техникой, а именно Saturn и Media Markt. Цены там, надо сказать, не самые гуманные – примерно, как у нас, а то и повыше. Но ассортимент и, главное, его расположение на прилавках, существенно отличаются. Так, у нас обычно планшеты кладут рядом с мобильными телефонами и в гомеопатических дозах. В берлинском Media Markt я насчитал аж 28 моделей, и лежали они по соседству с нетбуками. Длинный-длинный ряд, и как только планшеты кончаются – начинаются нетбуки. Различий в том, на какой платформе сделан планшет, не делается – сортировка исключительно по цене, от маленького к большому. «Атомные», понятное дело, начинаются с середины, но отличить их от собратьев на ARM почти невозможно, потому что модели на платформе Intel постоянно худеют, а конкурирующий лагерь того… поправляется. Так и лежат, все удивительно похожие друг на друга. Раньше можно было вслепую определить «атомный» планшет по температуре корпуса, но с тех пор, как ARMовцы перешли на два ядра с высокими частотами, это преимущество исчезло. Им бы, по идее, активное охлаждение ставить, да гордость не велит.

Очень забавно наблюдать за маркетинговыми опытами: например, когда планшеты одной и той же фирмы продаются под разными марками, одна из которых как бы престижнее другой. При этом все отличия исключительно на уровне логотипа и цвета корпуса. Так вот в России «престижной» выбрали одну марку, а в Германии – вторую. И в результате наша «престижная» в Германии стоит на 100 евро дешевле.

Еще в Германии очень модно «покупать немецкое», поэтому местные марки чувствуют себя довольно уверенно. Причем не только в IT – даже в продуктовых супермаркетах товар с лейблом вроде «настоящая немецкая картошечка» уходит особенно хорошо. Правда, незадолго до IFA разразился небольшой скандал: оказывается, львиная доля таких «немецких» продуктов родом из других стран и даже континентов, и в Германии их просто украсили правильной наклейкой. С компьютерами, телефонами и – особенно – жесткими дисками (их в Германии «производит» больше сотни компаний) ровно такая же история. Но «свое» берут отлично.

Вообще, по хорошему бы, провести IFA в начале октября, когда уже можно будет показывать все новинки на интеловском железе, представляемом на IDF в Сан-Франциско (13-15 сентября). Но, наверное, производители электрочайников и кофеварок не одобрили бы.

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