Их имелось целых два. Первый - "расшарить" доступ с телефона, благо в Петербурге уже давно наступило 3G, и скорость обещала быть достаточной. И относительно недорого - семь рублей за мегабайт. Правда, учитывая объемы одной только почты, на круг все равно получалось немало, рублей так 350-500.

Второй вариант - активировать модем Yota, давно живущий у меня в сумке, подключиться по тарифу "Yota День" (50 рублей в сутки) и надеяться, что до номера будет добивать сигнал сети. Учитывая цену вопроса, решил рискнуть и не прогадал: сеть была и в "Аэроэкспрессе" до Шереметьево-1, и в Пулково-1, и собственно в гостиничном номере. А уж когда я обновил прошивку модема (у меня, оказывается, была установлена какая-то совсем древняя, годичной давности), все заработало совсем хорошо. 50 рублей в сутки за полную безлимитку, да еще и с приличной скоростью - разве может быть что-то лучше для журналиста в чужом городе? Разве что юная поклонница, наизусть цитирующая "Заповедник" Довлатова, да и то - не во всех случаях

Показав кукиш рекламе на столе, предлагавшей подключиться к Сети при участии отеля, я все же решил посмотреть - сколько нынче лупят с нашего брата? Ведь сам номер (правильнее сказать - номерок, номеришко) стоил, страшно сказать 7000 рублей в сутки. В Европах столько берут за оч-чень хорошие четыре звезды и умело целуют заплатившего в неожиданные места. А у нас все скромненько-скромненько. Даже завтрак в эту цену не включен - за него надо накинуть сущие копейки, всего 645 рублей. Между нами говоря, в кафе по соседству за такие деньги можно наесться до отвала вдвоем...

Но мы отвлеклись. При таком уровне жадности я ждал цену на уровне 10 евро в час, или даже 20. Ну и что-то в районе соточки за сутки. Мол, открыл бумажник, землячок - не спеши закрывать, деньги это зло, очисться от него. 

Смотрю на таблицу и глазам своим не верю. Не может такого быть в нашей стране. Специально покрутил бумажку, может на другой стороне правильные тарифы, а эти - какие-то специальные, действующие только 1 мая и 31 декабря с 2 до 7 утра? Но нет, все правильно. Итак, заведение, явно не замеченное в скромности запросов, просило за 100 мегабайт трафика 150 рублей, за 200 - 250, и так далее. Я даже до конца дочитать табличку не смог, слезы умиления залили очки.

Учитывая, что нормальному человеку 100 мегабайт на 2-3 дня командировки - более, чем достаточно, гуманность расценок вызывает самый настоящий восторг. В тех же Европах, если нет бесплатного WiFi, десяточку евро в день с тебя снимут гарантированно. Так что же заставило хозяев постоялого двора в Петербурге быть такими гуманными?

Лично у меня вариант ответа один - Intel. С тех пор, как поддержка WiMax поселилась в массовых моделях ноутбуков и даже нетбуков, у командировочных из Москвы и Питера почему-то резко ослабло желание платить бешеные деньги за выход в онлайн. На 3G прошу не кивать: даже при относительно низких ставках на специальных интернет-тарифах 50 рублей в день съедаются мгновенно. Про тарифы обычные и говорить не приходится. А надо ли объяснять собравшимся - при чьей могучей поддержке WiMax проникает в мобильные компьютеры, и кто яростно разрабатывает технологию в небольшом городке Якум (Yakum), что в тридцати километрах от Тель-Авива?

Во время перелета из Санкт-Петербурга в Москву у меня родилась мечта. Вот бы придумать технологию, чтобы цены на гостиницы в северной столице стали такими же разумными, как и на Интернет. Невозможно? Ну, еще год назад и 150 рублей за 100 мегабайт казались несбыточной мечтой...

P.S. Во время недавней встречи клуба ISN в Москве мы с Дмитрием договорились о моем визите в Нижний Новгород, где тоже пишется будущее. Обещание помню и надеюсь выполнить его раньше, чем в Новгороде появится WiMax. Как-нибудь пересидим на дорогущем и допотопном 3G

#include < stdlib.h >

void test()
{
  const size_t Gbyte = 1024 * 1024 * 1024;
  size_t i;
  char *Pointers[3];

  // Allocate
  for (i = 0; i != 3; ++i)
    Pointers[i] = (char *)malloc(Gbyte);

  // Use
  for (i = 0; i != 3; ++i)
    Pointers[i][0] = 1;

  // Free
  for (i = 0; i != 3; ++i)
    free(Pointers[i]);
}

Данный код корректно выделит память, запишет в первый элемент каждого массива по единице и освободит занятую память. Код совершенно корректно работает на 64-битной системе.

Теперь удалим или закомментируем строчку "#include < stdlib.h >". Код по-прежнему будет собираться, но при запуске программы произойдет ее аварийное завершение. Поскольку заголовочный файл "stdlib.h" не подключен, компилятор языка Си считает, что функция malloc вернет тип int. Первые два выделения памяти, скорее всего, пройдут успешно. При третьем обращении функция malloc вернет адрес массива за пределами первых 2-х гигабайт. Поскольку компилятор считает, что результат работы функции имеет тип int, он неверно интерпретирует результат и сохраняет в массиве Pointers некорректное значение указателя.

Для лучшего пояснения приведу ассемблерный код, генерируемый компилятором Visual C++ для 64-битной Debug версии. Вначале рассмотрим корректный код, который будет сгенерирован, когда присутствует объявление функции malloc (подключен файл "stdlib.h"):

Pointers[i] = (char *)malloc(Gbyte);
mov   rcx,qword ptr [Gbyte]
call  qword ptr [__imp_malloc (14000A518h)]
mov    rcx,qword ptr [i]
mov    qword ptr Pointers[rcx*8],rax

Теперь рассмотрим вариант некорректного кода, когда отсутствует объявление функции malloc:

Pointers[i] = (char *)malloc(Gbyte);
mov    rcx,qword ptr [Gbyte]
call   malloc (1400011A6h)
cdqe
mov    rcx,qword ptr [i]
mov    qword ptr Pointers[rcx*8],rax

Обратите внимание на наличие инструкции CDQE (Convert doubleword to quadword). Компилятор посчитал, что результат содержится в регистре eax и расширил его до 64-битного значения, чтобы записать в массив Pointers. Соответственно старшие биты регистра rax будут потеряны. Если даже адрес выделенной памяти лежит в пределах первых четырех гигабайт, в случае, когда старший бит регистра eax равен 1 мы все равно получим некорректный результат. Например, адрес 0×81000000 превратится в 0xFFFFFFFF81000000.

К счастью данный вид ошибки легко обнаружить. Например, компилятор Visual C++ выдает два предупреждения, свидетельствующих о потенциальной проблеме:

warning C4013: 'malloc' undefined; assuming extern returning int

warning C4312: 'type cast’ : conversion from 'int' to 'char *' of greater size

А анализатор PVS-Studio 3.40 выдает предупреждение "error V201: Explicit type conversion. Type casting to memsize.".

class Example
{
public:
  unsigned m_value;

  Example() : m_value(0) {}

  unsigned GetValue()
  {
    return ++m_value;
  }

  unsigned GetSum()
  {
    unsigned sum = 0;
    #pragma omp parallel for
    for (ptrdiff_t i = 0; i < 100; i++)
    {
      #pragma omp atomic
      sum += GetValue();
    }
    return sum;
  }
};

Данный пример содержит ошибку состояния гонки (Race condition), и возвращаемое ей значение может меняться от запуска к запуску. Если вы попробуете приведенный пример, и результат все время будет верен, то можете изменить функцию GetValue, как показано ниже, чтобы ошибка проявлялась более четко:

unsigned GetValue()
{
  Sleep(0);
  m_value++;
  Sleep(0);
  return m_value;
}

В коде с помощью директивы atomic защищено увеличение переменной "sum". Но директива atomic не оказывает влияние на вызов функции GetValue(). Вызовы происходят в параллельных потоках, что приводит к ошибкам при выполенения операции "++m_value" внутри функции GetValue.

Помните, что функции, используемые в выражениях, к которым применяется директива atomic, должны быть потоко-безопасными (thread-safe). Директива atomic распространяется только на операции следующего вида:

• x binop= expr
• x++
• ++x
• x--
• --x

Здесь х - скалярная переменная, expr - выражение со скалярными типами, в котором не присутствует переменная х, binop - не перегруженный оператор +, *, -, /, &, ^, |, <<, or >>. Во всех остальных случаях применять директиву atomic нельзя.

В приведенном примере директива atomic обезопасит операцию "sum +=", но не обезопасит вызов функции GetValue. Для исправления показанной ошибки необходимо использовать критическую секцию или иные способы для защиты переменной m_value.

Обнаружить подобные ошибки может помочь, такой инструмент как VivaMP, входящий в состав PVS-Studio. В данном случае, он диагностирует ошибку следующим образом: Error V1205: Data race risk. Unprotected concurrent operation with the ‘m_value’ variable. При этом ошибку можно обнаружить еще на этапе написания кода, так как VivaMP представляет собой статический анализатор кода и не требует запуска приложения.

Под Windows 7 (лицензионной! с автографом Балмера!) поставил любезный сердцу Moyea Flash Video MX Pro, которым мы жмем ролики для сайта. Запустил Task Manager и помянул негромким добрым словом "экспертов", рассказывавших мне про "операционную систему из Кемерово". Нет, сама-то операционка нормальная, и на SSD пуляет - мое почтение. Но тупая софтина упорно использует только ЧЕТЫРНАДЦАТЬ процентов процессорных мощностей, тогда как даже под Vista было двадцать. Наверное, надо что-то подкрутитьв настройках, но такое несерьезное отношение "по умолчанию" огорчило. Ну шутка ли, 10-минутный ролик пережимается с той же скоростью, что и 44-минутная серия "Доктора Хауса" из шестого сезона нормальной программой.

А, хватит о грустном.

Вчера, когда поставил новую видеокарту, решил погонять какую-нибудь игру. Под "семеркой" еще ничего поставить не успел, просто "экзешником" сейчас запускаться неприлично, уговорил только C&C Generals. В общем, оторвался от процесса только в два часа ночи. Яростная штука! Вроде бы 11 февраля 2003 года вышла, по игровым меркам -  в позапрошлом веке! Однако же прекрасно понимает разрешение 1600х1200 и безо всяких патчей работает с самым современным на данный момент семейством чипов Nvidia. Правда, зараза такая, грузит только одно ядро процессора, но для старушки это простительно.

Доиграл, выключил компьютер и пришла в голову мысль. Наверное, банальная, но всё же.

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

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

Он не жалеет ни о чем, он держит дома шесть альбомов  ГО и  пять албомов БГ.
И вроде бы он не предатель, он по своему прав.
Ведя мемуары за чашечкой кофе: "Моим детям о вчерашнем дне",
Каждый ловит свой собственный кайф.

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

Возможно, поэтому я регулярно устанавливаю все новые версии C&C, а играть продолжаю в "Генералов". Там, конечно, магии поменьше, чем в первых частях, но все же есть. В отличие от.

Интересно, может ли в наше время вообще появиться индустрия, где будут заправлять такие вот веселые маньяки, как в свое время в игровой? Я бы с удовольствием дожил

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

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

Можно говорить о том, что наш наши КБ и НИИ безинициативны и не делают использовать доступные вычислительные мощности. Но вот вам обратный пример: Институт объединенных ядерных исследований при выполнении зарубежных заказов по проектированию циклотронов был вынужден использовать обычный персональный компьютер, неизвестно, чем бы завершились проекты, но ребятам удалось использовать видеоадаптер для значительного ускорения вычислений в рамках проекта "CBDA: Cyclotron Beam Dynamics Analysis". С другой стороны университетские кластеры просто простаивают. К примеру, кластер МГТУ им. Баумана загружен всего на несколько процентов, по словам инсайдеров.

В России есть отдельные проекты, которые пытаются решить эту задачу, например, CAEBeans под руководством проф. Л.Б. Соколинского, ЮУрГУ. Другой пример: проект MathCloud Алексея Тарасова из ИСА РАН.

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

При анализе библиотеки TBB ей были заданы «вопросы» в форме разных алгоритмов вычисляющих числа Фибоначчи. В результате было высказано предположение, что TBB не делает алгоритм параллельным. И это, несмотря использование ядер? Парадоксально? Странное на первый взгляд утверждение базируется на том, что параллельный рекурсивный алгоритм, созданный на базе аналогичного последовательного алгоритма, должен иметь вычислительную сложность, выражаемую линейной зависимостью - O(n). Но с какой такой бухты-барахты мы это взяли? …

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

На рис.1 приведена блок-схема императивного алгоритма вычисления чисел Фибоначчи, исходный код которого на языке С++ приведен в листинге 1. Для построения эквивалентной модели в форме конечного автомата проведем процедуру разметки блок-схемы точно так же, как это было показано в первой части для параллельного рекурсивного алгоритма. Сама разметка показана там же на рис.1, а граф эквивалентного автомата на рис.2. На рис.3 приведен граф автомата, который эквивалентен последовательному рекурсивному алгоритму.

float fib (int n)
{
  int i;
  float y, fib1, fib2;
  if (n <= 1) return y=1;
  for (fib1 = fib2 = 1, i=2; i <=n; i++)
  {
    y = fib1+fib2; fib1 = fib2; fib2 = y;
  }
  return (y);
}
// Листинг 1. Программа для вычисления чисел Фибоначчи

Рис. 1. Блок-схема размеченного императивного алгоритма вычисления чисел Фибоначчи

Рис.2. Граф автомата императивного алгоритма

Рис.3. Граф автомата последовательного рекурсивного алгоритма

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

В таблицу 1 сведены результаты тестирования обычных и автоматных алгоритмов. В ее первой строке – номер числа в ряду Фибоначчи, в следующих двух - реальное время работы обычных алгоритмов, а в четвертой и пятой - дискретное время их автоматных аналогов. Графики эффективности, приведенные к времени 20-го числа обычного императивного алгоритма (первое значение во второй строке таблицы) показаны на рис.4. Из их полного совпадения следует, что выбранная модель и методика построения эквивалентных моделей не влияют на его вычислительную сложность. Напомним, что под вычислительной сложностью понимается зависимость времени работы алгоритма от значения входных данных.

Таблица 1
20 21 22 23 24 25 26 27 28
0,002 0,002 0,002 0,003 0,003 0,003 0,003 0,003 0,003
0,572 0,931 1,499 2,427 3,948 6,376 10,307 16,636 26,997
79 83 87 91 95 99 103 107 111
65672 106262 171638 278204 450146 728354 1178504 1906862 3085370


Таблица 2
20 21 22 23 24 25 26 27 28
0,002 0,002 0,002 0,003 0,003 0,003 0,003 0,003 0,003
0,572 0,931 1,499 2,427 3,948 6,376 10,307 16,636 26,997
59 62 65 68 71 74 77 80 83


В целях наглядности включим в новую таблицу времена обычных алгоритмов из таблицы 1 и дискретное время работы параллельного рекурсивного алгоритма. Графики вычислительной сложности, приведенные ко времени императивного алгоритма, по данным таблицы 2, представлены на рис. 5. Их вид убеждает, что вычислительная сложность параллельного алгоритма имеет тот же вид, что и вычислительная сложность последовательного императивного алгоритма. Просто параллельный алгоритм в абсолютном выражении тратит на вычисление меньше времени. В данном случае условного времени – дискретного.

Рис. 4. Графики эффективности алгоритмов (Ряд 1,2 – обычные, Ряд 3,4 – автоматные)

Рис.5. Графики вычислительной сложности алгоритмов (Ряд 1, 2 – обычные, Ряд 3 – параллельный рекурсивный)

Из совпадения вычислительной сложности алгоритмов следует, что, не зная какой алгоритм – рекурсивный или императивный реализует «черный ящик», сложно определить устройство внутренностей «ящика». Можно было бы судить по реальному времени, т.к. параллельный по идее должен быть быстрее. Но, это еще, как говорится, не факт! Может быть, правда, пока? Однако, если известно точно, что «ящик» реализует рекурсивный алгоритм, то линейный характер вычислительной сложности говорит о том, что oн параллельный, а если экспоненциальный (аппроксимация с помощью функции СТЕПЕНЬ(число; степень из Excel приводит к зависимости – O(2^(N/1,44)) – последовательный.

… Но если вернутся к цели нашего исследования – анализу вычислительной сложности алгоритмов, то проблема, безусловно, не в том, что TBB замедлила в данном конкретном случае работу алгоритмов в реальном времени. В теории анализ алгоритмов не связывают с реальным временем, а рассматривают условное время. Например, когда «зернистость» будет соответствовать требованиям TBB (в пределах 1000 инструкций на такт условного времени), то, скорее всего, время работы уменьшится и возможно даже, как в случае с числами Фибоначчи, пропорционально числу ядер. Проблема в другом: свойства алгоритма, как показало тестирование, остались прежними – последовательными! Но смысл введения множества ядер не только и не столько в простом увеличении скорости работы программ, а в увеличение скорости за счет качественно иного программирования – параллельного. А последнее, если верить теории, должно привести к изменению его вычислительной сложности. Пока мы этого не наблюдаем (или не можем увидеть?).

Так может ли речь идти о параллельном алгоритме, если его свойства остаются последовательными? Для внешнего наблюдателя, играющего, например, в упомянутую выше имитацию, подобное «распараллеливание» эквивалентно простому увеличению тактовой частоты «ящика» – при увеличении скорости его работы, и уменьшении – при увеличении времени работы. Напомним, что в случае TBB скорость для однопоточной параллельной версии сначала уменьшилась в 66 раз, а потом для двух ядер увеличилась в два раза, т.е. в конечном итоге уменьшилась в 33 раза при сохранении вычислительной сложности (?).

Но тогда, если следовать правилам «игры» или, что точнее, теории алгоритмов, речь должна идти скорее о неких ухищрениях, в каких-то случаях повышающих, а в большинстве, как можно предположить, скорее понижающих, скорость работы программ. При этом сама причина уменьшения скорости в том, что под упомянутые требования зернистости подпадает лишь малая часть параллельных алгоритмов.
Оценивая результаты тестирования алгоритмов, можно также возразить – просто мало ядер! Настолько мало, что их число никак не сказывается на свойствах алгоритма. Но будет ли достаточно 4-х, 8-ми и т.д. ядер? И, действительно, для параллельного рекурсивного алгоритма почти любое доступное их число сейчас и даже предполагаемое в будущем – капля в море, т.к. речь должна идти о сотнях тысяч ядер!

Оценку вычислительной сложности параллельного алгоритма можно и даже нужно выполнять исходя из понятия виртуального параллелизма. В этом случае и время должно быть виртуальным или условным. В автоматной модели условное/виртуальное время – это дискретное время. А как узнать виртуальное время (в теории, напомним, чаще говорят об относительном времени) работы многопоточного алгоритма? Подсчитывать число инструкций, в том числе и выполняемых параллельно?...

PS: Тестирование параллельного рекурсивного алгоритма на MC# убеждает, что и он имеет вычислительную сложность, как и у последовательного рекурсивного алгоритма.

Первое, что бросается в глаза, в этом якобы Си-подобном языке, это объявления переменных и типов. Здесь добавлены новые ключевые слова и все перевернуто с ног на голову, команда Go, утверждает, что так удобнее. Но поначалу такое нововведение вызывает только раздражение. Теперь, чтобы объявить переменную i типа int, придется выдать конструкцию:

var i int;

Другие примеры:

var p *int; //указатель
var str string; //строка

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

Арифметике указателей, напротив, придется сказать "до свидания". Гуглы решили, что так безопаснее, да еще и проще будет реализовать сборщик мусора. Ага, в Go появилось и это чудо. Гугл декларирует Go как быстрый язык поддерживающий параллельное программирование. Как сборщик мусора будет сочетаться с этими декларациями? Весьма, весьма интересно. Одно правда, для ряда параллельных задач сборщик мусора упрощает дело. Бывает так, что приходится писать пользовательские менеджеры памяти, только, чтобы память можно было освобождать в условиях общей памяти и многопоточности. С другой стороны, сборщик мусора может серьезно сказаться на эффективности. Задачи дискретной оптимизации, к примеру, весьма активно используют память и сборщик мусора тут может сыграть дурную шутку. Но пока это лишь предположения.

Разработчики Go так и не смогли обойтись без синтаксического сахара в объявлениях переменных, следующие 2 объявления равнозначны:

var i int = 0;
i := int(0);

Оператор := позволяет задавать тип переменной, исходя из типа присваиваемого значения.

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

const NewLine = "\n";

Можно объединить определения нескольких констант следующим образом:

const (
	NewLine = "\n";
	MagicNumber = int(7);
)

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

Функции в Go достаточно интересны. Они выдерживают общий стиль объявления новых типов, и на этот раз ключевым словом является func:

func lisa(grade int) {...} // по правилам Си: void foo(int i) {...}
func bart(shorts string) string {...} //const char *bart(const char *str) {...}

Все это конечно замечательно, но есть одно дополнение, которое позволит обходится без boost::tuple в качестве возвращаемого значения:

func homer(beer string) (int, double) {...} //аналог в Си: эээ...
		//int homer(const char *beer, double *result) {...}

В общем, несколько возвращаемых значений не новинка и поддерживаются в том же Руби, но какого их нет в таком вроде новом языке как C#? И в C++ их тоже не хватает. Стандартная ситуация: возврат кода ошибки и основного результата.

Пожалуй не буду дальше испытывать ваше терпение, и некоторые более интересные типы вроде исключений и определений новых типов я оставлю до следующей записи.
P.S.:Для тех, кто как и я страдает без подсветки синтаксиса в Go, могу предложить файл определений для библиотеки GtkSourceView-2.x, если вы скопируете его в папку /usr/share/gtksourceview-2.0/language-specs/ (путь может меняться в зависимости от дистрибутива Linux), то такие приложения как gedit, будут поддерживать подсветку синтаксиса Go: go.lang.

• Сайт языка программирования Go

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

Джо Кукан – хорошо, Анатолий Вассерман – отлично, Дмитрий Пучков – еще лучше… Жаль только ничего большого и светлого в репортажах с выставки я так и не увидел (да простят меня фаны C&C). Сдается мне, что подобные выставки скоро превратятся в то, во что уже превратились промо-компании отечественных фильмов: побольше звезд на предварительных показах и неприятно красивые гламурные девицы с восторженными отзывами в новостях тщетно пытаются компенсировать убогий сюжет и жалкую игру актеров. Пятидесятикратное падение продаж, говорите? Ну-ну…

Думаете, что я собрался брюзжать по этому поводу? Совсем нет! В сети есть и хорошие вести: не успел маленький стартап PlayFish дожить до своего двухлетия, как был приобретен Electronics Arts. Цена вопроса - $400.000.000. Зачем великой и могучей EA понадобился английский PlayFish? Тем паче на фоне кризиса индустрии? Да все просто – PlayFish специализируется на примитивных играх для социальных сетей. Ну, вы понимаете… Всякие там виртуальные животные, фермы, рестораны и т.д. Не понимаете? Значит у вас нет FaceBook-зависимых друзей и знакомых. А вот у меня есть. Приехав с работы домой, такие люди первым делом бегут к компьютеру, потому что им срочно нужно полить капусту. Или вынуть жаркое из духовки. Или еще что-то там переставить, прополоть, посадить, подать, и т.д.

По разным оценкам число игроков в «социальные игры» составляет от 50.000.000 до 80.000.000 человек. ЕЖЕДНЕВНО. Погуглите число игроков в WOW и вы удивитесь еще больше.

Впрочем, PlayFish – детский лепет. Настоящий монстр этого дела - Zynga. Не слышали? Farmville, Mafia Wars, Restaurant City. Тоже не слышали? Зря. GTA IV со всеми своими йогами, играющими по 40 часов без перерыва – просто кучка маргиналов в сравнении с Farmville. И я лично знаю нескольких многодетных отцов и домовладельцев, которые вплотную приближаются к 300-му уровню в Mafia Wars.

В чем фишка? Социальные игры органично вклинились в функциональность и социальность социальных сетей : игроки сами занимаются раскруткой игр в среде своего общения; ведь почти все их действия «светятся» в лентах. Игроки сами вербуют новобранцев: чем больше у тебя компаньонов, тем быстрее ты набираешь очки. И что самое интересное: им даже не нужно создавать сообщество, ведь они УЖЕ в сообществе.

Конечно, если играть по-честному, то, достигнув 300-го уровня можно упустить последний шанс стать многодетным отцом . Спасибо разработчикам, - если очень уж хочется, то нужный скарб можно прикупить. Это я сейчас про игру ;). Впрочем, детей я слышал, тоже можно купить :). Ох уж мне этот материальный мир! Впрочем, выбор за нами – можно купить и то и то, если денег хватит.

Так о чем это я? Да о том, что по самым скромным оценкам доход Zynga в текущем году - $100.000.000. Пятидесятикратное падение продаж, говорите? Ну-ну…

Написав весь этот текст, я задумался. Полтора года назад я сделал осторожный прогноз развития рынка игр. Цитирую: "А не прозевали ли разработчики игр (и мы, производители платформ) еще один тренд рынка? Не случиться ли так, что когда массовые игры будут производится из расчета в 1000$ на "low-end" железо, массовые потребители будут обладать железом всего за $400, включая монитор?". И что характерно: прогноз-то я сделал, но этим ограничился. Может зря? Быть может наше горе – от ума? Может зря вся эта многопоточность, фотореалистичная графика, искусственный интеллект ларраби (ой )? Может лучше не про C++, а про Flex? А? Что скажете?

Не, вы не подумайте, что это провокация. Действительно хотелось бы обсудить. Мы тут все люди совсем неглупые… Быть может именно сейчас кому-то в голову придет идея на сто миллионов? Чур я в доле.

Всем удачи!

И вот - гран финале. Сегодня Google объявила о выходе собственного языка программирования Go. Начался обратный отсчет времени до тотального покорения галактики.

Я сейчас сижу на сайте http://golang.org/, читаю документацию и паралелльно общаюсь со знатоками. Не скрою, мне трудно, потому что никакой я не программист  - так, тестировщик. Пока на вид ничего страшного: в FAQ много уклончивых формулировок и маркетингового бла-бла, и по соседству признается, что даже в самой великой и ужасной Google до массового использования мегаязыка пока не дошло.

И вот вроде всего первый день пошел, а отзывов в Интернете уже пруд пруди. Кто-то называет странным плодом любви Python с C++. Кто-то придумал имя для людей, программирующих на нем - Goпники. Есть голоса, предрекающие кончину во младенчестве, а есть и оптимисты, гарантирующие скорый переход на Go 99,9 процентов всех программистов мира. Не 100, потому что этих фортранщиков все равно не переубедить. Они переживут даже ядерную зиму.

Скептики могут сказать, что существует несколько тысяч языков программирования, и одним больше, одним меньше - не повод тратить виртуальные чернила. Но тут ведь как в известном анекдоте: "я не знаю, кто в машине, но шофер у него Брежнев". Людские и финансовые возможности Google таковы, что если в компании решат - Go попрет стремительным домкратом. Коллеги по бизнесу сначала посмеются, потом помолчат, а потом запрутся в маленьких комнатках и начнут бояться любого звука. Помните, как хихикали над Microsoft, когда корпорация вышла на рынок приставок? Вот, недавно вышло исследование - на долю Xbox приходится уже 49% отечественного рынка, да и на мировом одни сплошные поводы для оптимизма. В общем, главное - захотеть.

Но захочет ли Google? Чтобы понять это, язык врага надо знать и понимать немного лучше, чем это под силу экс-тестировщику. Поэтому обращаюсь к вам, уважаемые коллеги. Каковы первые впечатления? Насколько доработан язык на сегодняшний день? Правда ли, что он заточен исключительно под серверные приложения, а остальным просьба не беспокоится? Что может заставить лично вас серьезно сесть на Go? И - главное - нужен ли индустрии новый язык программирования? И нужен ли ей Go?

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

Дорогой Дмитрий Оганезов! Даже если Big Brother нас таки заглотит, мы будем знать, что идея пошла в массы, и если бы не он - все бы у нас получилось. Но может еще и получится, а?