Но больше всего удивил Marvell со своим процессором Armada 628, в котором 3 обычных ядра (2 на высокой частоте, одно на пониженной) плюс 6(!) дополнительных ускорителей (для 3D-графики, кодирования-декодирования видео, аудио, шифрования и обработки изображений). Вот только я не понял, из этих 6 штук - каждый со своей одной функцией, или каждый из шести может выполнять любую из этих специализированных работ.

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

Основным конкурентом ARM'у является конечно Intel Atom, ну и AMD Ontario. Так что про них тоже немного в конце статьи написано

Что сначала делает любой программист, когда ему приходится заниматься портированием? Конечно же взять и просто тупо собрать продукт в новой конфигурации (авось прокатит?)! Как ни странно, этот проект без проблем собирался, запускался и вроде даже работал. Но позже оказалось, что вовсе и не работал, и здесь надо немного пояснить специфику прокта.

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

Картинки и описание можно посмотреть на сайте программы: http://www.faultwire.com. Сама программа бесплатна, но вот владелец распространяет её только в англоязычных странах (по-крайней, мере так было полгода назад), так что возможно про неё никто из вас не слышал . Более того, если вы её попробуете запустить на системе с русским языком по-умолчанию, то она скажет вам Sorry... Но если вдруг кому-то сильно охота запустить и посмотреть, можете меня спросить - я знаю, как это ограничение обойти.

Итак, из вышесказанного главными словами являются "внедрение dll". Разбираясь, почему же на 32-битных приложениях кнопка FaultWire появляется, а на 64-битных нет (либо появляется, но тут же всё падает), я разобрался и, что такое WOW64, и в других заморочках совместного сосуществования программ разной разрядности.

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

Во-первых, что мне пришлось исправить все старые версии функций на соответствующие новые. Шутка ли - встретилась даже одна 16-разрядная версия функции (проект начинал не я). Вот примеры, которые вспомнил навскидку:

SetWindowLong --> SetWindowLongPtr 
GetWindowLong --> GetWindowLongPtr
SetClassLong --> SetClassLongPtr
GetClassLong --> GetClassLongPtr

Во-вторых, я столкнулся с несоответствием выравниваний в структурах. Эта проблема однажды тут где-то затрагивалась, на форуме или в блогах. Она возникает, когда данными обмениваются процессы с разной разрядностью. В моём случае так и было: основная 32-разрядная программа обменивается данными (в основном получает) с библиотеками, инжектированными в разные процессы - 32-х и 64-разрядные. В частности, для передачи структуры данных использовалось сообщение WM_COPYDATA. Проблема проявилась в том, что в структуре были поля типа HWND, а они в 32-битных приложениях - 32-битные, а в 64-битных - 64-битные. Поэтому, при разборе данной структуры в 32-битном процессе, то что пришло от 64-битной - портилось. Проблема была решена тем, что все такие поля сделал 64-битными (в 32-битных процессах хэндл помещался в младшие 32 бита такого поля), заменив их таким объединением:

union _hwnd3264	// for placing 32 or 64-bit HWNDs on 64-bit
{
 HWND hwnd;
 __int64 hwnd64;
};

И наконец, последняя ошибка над которой я бился. При появлении кнопки FaultWire это приложение падало с малопонятным сообщением, указанные в сообщении адреса выглядели мягко говоря странными, так как и дизассемблер и отладчик показывали там какую-то чушь (а может я начинал понемногу сходить с ума). А дело оказалось вот в чём. Поскольку в программе появляется новый элемент управления (кнопка), которого не было изначально предусмотрено, то надо обеспечить обработку всех его событий, т.к. родная оконная функция про них ничего не знает. Сделано это было очевидным способом - сабклассингом. Родная оконная процедура подменялась своей, которая обрабатывала сообщения этой кнопки, а все остальные сообщения отправляла родной процедуре. Ошибка была в строке, которая выполняла подмену:

SetWindowLongPtr(hwnd, GWLP_WNDPROC,
    (DWORD)(LONG_PTR)(((g_isVista || g_isWin7) && fDwmEnabled)
                                  ? SubClassMenuProcVista : SubClassMenuProcXP));

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

Smaller Type Check (/RTCc).

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

Есть также подобный флаг Basic Runtime Checks. Возможно я их и включал время от времени, но вот их фишка заключается в том, что работают они только в дебаге. А я в каких только режимах не запускал, с какими только параметрами... Зато например статическому анализатору найти ошибку в приведённой строке, мне кажется, было бы вполне по плечу. И запускать бы программу не понадобилось...

Я чаще запускал в релизе. Да и, вообще, поначалу (когда я взялся за проект), он мог нормально работать только в релизе. Причин было несколько, и одна из них: ошибка при работе с XML. Как я её исправил, уже неважно, но при исправлении обнаружился забавный факт. У меня тогда ещё была лицензия на Parallel Studio и я решил позапускать программу с Inspector'ом (кажется он ищет ошибки работы с памятью?) в поисках ошибки. Пробовал подключать разные версии библиотеки MSXML (известно, чьего производства ) , начиная с третьей, в надежде, что ошибка исчезнет. Ошибка не исчезла, но зато инспектор внутри этих библиотек нашёл такую тучу ошибок!..

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

Как вы думаете, какое программное обеспечение используется для этого? Я не знаю как вообще, но могу сказать как это происходит при обслуживании "Боингов". В нашей стране был недостаток в технических специалистах для обслуживания "Боингов", особенно когда их стали более-менее брать в лизинг в предкризисные времена. Поэтому приходилось прибегать к услугам иностранных фирм. И вот когда заключается договор с такой фирмой (о том, что сколько-то их специалистов будет работать в России), они выставляют условие, что в качестве такой напоминалки они используют только ПО определённой фирмы. Как правило сразу понятно, откуда ноги растут: шведская фирма пользуется услугами шведской фирмы, французская - услугами французской... Вполне возможно, что руководители и той, и другой - школьные друзья, в любом случае - не случайные люди.

Спрашивается, зачем им это? Всё дело в цене. Оплачивается такая программа, как и работа специалиста - помесячно. Мой знакомый работал с несколькими такими программами и говорит, что самая приличная из них была сделана в виде сайта и стоила 5000, кажется, евро в месяц. Самая простая стоила 1000 у.е./месяц и чтобы с ней работать надо было подключиться к удалённому рабочему столу выделенного для этого сервера. На рабочем столе один-единственный ярлык этой программы и всё. Пользовались ею не более 5 человек.

При этом все эти "системы" довольно-таки сырые. Есть чего не хватает, есть что сделано плохо. Но деваться некуда: без такой программы, обслуживать "Боинги" нельзя. Казалось бы, когда станет хватать своих своих специалистов, то и проблемы этой не станет. Можно будет сделать свою толковую программу, под себя, например силами отдела автоматизации или по заказу. И никому за неё не платить абонентскую плату. Ан нет! Мы обучаемся у зарубежных коллег не только в технических вопросах, но и экономических. А именно: там, где программа была заменена на отечественную, принцип не изменился. Программа оплачивается также помесячно, но дешевле (например, сколько-то сотен тысяч рублей в начале и потом 20000 руб/мес), а сама программа значительно хуже То есть сделали наспех, самому большому начальству в качестве преимущества указали меньшую цену, убедили заменить. И всё, дальше можно ничего не делать, только ходить в банкомат за деньгами! И поделать тут тоже ничего нельзя: программу продвигают большие люди. А технические специалисты мучаются с некачественным софтом.

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

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

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

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

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

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

Понятно, что я бы не стал всё это писать просто из желания пожаловаться на жизнь. Есть пара мыслей как бы все это улучшить с использованием новых возможностей для коммуникации. Вот бы взять весь этот процесс и перенести в интернет. И сделать более публичным. А именно, примерно так: человек постит статью, её читают, появляются какие-то отзывы, оценки, вопросы... Когда по оценкам и обсуждениям становится понятно, что статья стоящая (и, возможно, автор её исправляет, дополняет), она становится кандидатом на то, чтобы считаться прошедшей рецензирование (как говорят, "ВАКовской"). После этого её уже проверяют эксперты - известные люди, не скрывающиеся под никами, - и выносят свой вердикт.

Что получаем:

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

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

Я конечно не надеюсь, что в скором времени что-то такое можно будет сделать. Скорее всего это станет возможно, когда все члены РАН будут иметь год рождения не раньше 1970-80-хх. Т.е. будут уверенными и регулярными пользователями интернета.

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

В Windows XP и младше этим компонентом был Dr.Watson - drwtsn32.exe. В Висте и семёрке его заменил WerFault. Так вот недавно я заметил один маленький недочёт в его работе.

Я занимался портированием библиотеки с 32-х на 64 бита в Windows 7. Приложение, в которую внедрялась эта библиотека, в определённый момент падало. Я долго и всевозможными способами искал причины краша, поэтому в определённый момент обратился к информации, предоставляемой WerFault и к журналам Windows. И обнаружил, что WerFault искажает информацию об адресе места, где произошло исключение. Библиотека 64-битная, базовый адрес её загрузки - 0x180000000, т.е. выходит за рамки 32-битного адреса. Вот скрин из Иды, подтверждающий это:

Также я из библиотеки писал лог и там тоже базовый адрес логгируется как 0x180000000. Так же и в отладчике я попадал именно на такие адреса. Тем не менее вот, что я увидел в информации WerFault:

Как видим, единичка из старших 32-бит пропала! В журнале Windows видим то же значение.

Вообще в 64-разрядной Windows много компонентов являются 64-разрядными. Но вот именно этот - 32-разрядный. Интересно, как он вообще собирает информацию с 64-битных приложений, когда это необходимо? Возможно это и явилось причиной "обрезания" адреса.

Я у себя в системе нашёл два файла WerFault.exe - в папках %Windows%\system32 и %Windows%\SysWow64. Оба 32-битные. Но я даже знаю, что у меня конкретно срабатывал из папки %Windows%\system32, т.к. это тоже попало в лог.

В общем вот так. Кто использует информацию из журналов Windows - будьте бдительны

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

Зашёл на форму регистрации, ввёл тот же логин, что и здесь, на что мне было сказано, что какой-то умник такой логин уже занял. Я хотел было уже вводить другое имя, но тут заметил, что во-первых, можно восстановить пароль по логину, а во вторых, Intel® Atom™ Developer Program это part of the Intel Software Network! То есть, возможно, умник, занявший мой логин, - это я сам.

Введя логин на форме восстановления пароля, я увидел, что способа восстановления два: по секретному вопросу и высылкой пароля на почту. Я попробовал сначала первый. Я в этот момент был уже залогинен на ISN в другом окне, поэтому просто зашёл там в профиль, чтобы посмотреть свой секретный вопрос. Однако его там не оказалось, даже незаполненного. Поэтому непонятно, какой вопрос имелся в виду. Я уже как-то без особой надежды нажал кнопку восстановления пароля на e-mail и с радостью увидел, что пароль выслан на мою почту.

В письме оказался другой пароль, т.е. не тот, которым я пользуюсь, а похожий на случайно сгенерированный. Когда я им залогинился  на Intel® Atom™ Developer Program, то мне было сообщено, что это временный пароль и надо его заменить. Я решил ввёсти свой обычный пароль. Оказалось, что так нельзя. Кроме того я там увидел информацию о том, что пароли должны меняться раз в 9 месяцев. Странно, но на ISN я захожу уже очень давно с паролем, который ввёл в самый первый раз. В общем ввёл новый пароль. И мне вот сейчас интересно, не изменится ли у меня пароль на ISN? Одно изменение уже я заметил: всего баллов у меня не изменилось, а вот статусных баллов стало ноль!

Так или иначе есть и хорошая новость: оказывается, все, кто зарегистрирован на ISN, автоматически зарегистрированы и в Intel® Atom™ Developer Program. Насколько я понимаю, $99 собираются брать именно за неё.

Что касается самого магазина, то условия такие: 30% Интел берёт себе. Сейчас доступны такие среды исполнения как Windows* и Moblin*. В будущем ожидаются Java* и Adobe AIR*. Правда не знаю, это ограничения только магазина или SDK. Более подробно пока сказать не могу - ещё не вчитывался в условия.

Пользуясь случаем хочу спросить у сотрудников Интел,через что могут производиться расчёты с разработчиком и надо ли обязательно создавать какую-то организацию (ООО или ИП)? Пока вроде сайт этой программы только англоязычный, и не может ли оказаться, что все расчёты будут выполняться только через PayPal? Тогда многие российские разработчики пойдут мимо Atom App Store.

И ещё вопрос по SDK (кстати, он тоже beta). Какие скрытые возможности он даёт? Подразумевает ли его наличие также и оптимизацию программы под встроенную видеокарту Интел, которая имеется на всех нетбуках с Атомом? Я пока всё, что компилировал на моем Атоме в MSVS под Win32, без проблем запускал и на нём и на других компьютерах с Win32.

Я конечно там и сам ещё почитаю, но хотелось бы увидеть и русский коментарий.

Итак начнём. Вообще у меня уже было желание о чём-то таком написать, т.к. здесь уже вопрошали какой же язык наиболее подходит для параллельного програмирования, а какой вообще не подходит... Некоторое время назад я начал изучать язык VHDL и был одновременно обрадован и озадачен. С одной стороны, я увидел - вот он язык для программирования параллельных процессов! Это изначально заложено в самом языке. Но с другой стороны мне было странно, что никто из участников ещё его не упоминал, хотя наверняка ведь знали. Поэтому я решил поизучать его, познакомиться ближе, а потом уже написать в блоге что-то более конкретное.

А тут как раз начался массированный промоушн КА-подхода с стороны одного участника, на форуме ISN было дано несколько ссылок на статьи по теме, и я решил подключиться . Рассуждал я так: конечные автоматы, цифровая схемотехника, RS-триггеры, VHDL... всё это лежит очень близко. А значит точки соприкосновения должны быть найдены. Каково же было моё удивление, когда я в статьях, предложенных автором, не нашёл ни упоминания, ни тем более использования данного языка. Поэтому у меня первый вопрос Вячеславу: Вы знакомы с языком программирования VHDL? Если нет, то вам определённо стоит это сделать! Возможно, когда вы с ним познакомитесь, вы придёте к той мысли, что не надо придумывать никакой КА-модели параллельного программирования. Она уже существует! И реализована в языке VHDL. А ваше желание сделать добро людям трансформируется в более практичные цели:

1) сделать компилятор языка VHDL для архитектуры x86, хотя бы для одной ОС;
2) расширить стандартные возможности языка, чтобы его можно было легче использовать при написании обычных приложений (т.е. библиотеки визуальных компонентов для рисования окошечек и т.д.)

Если же вы знакомы с этим языком, то я очень удивлен, почему в статьях нет упоминания VHDL, а есть какой-то UML? Про UML уже здесь отзывались, да и так известно. Это по большому счёту язык не для написания программ, а для описания моделей. Неплохой инструмент для аналитиков, любителей порисовать картинки, но не для серьёзных программ. Как сказал герой одного фильма: "Ружья для понта, ножи для дела". Как вы поняли, UML - ружья, VHDL (ну или C++) - ножи.

Теперь немного критики по существу.

Во-первых, хотелось бы уточнить то, что касается модели. Вы, Вячеслав:
1) Хотите разработать (или уже разработали) алгоритм, который получает на входе "классический" алгоритм (одно- или многопоточный), а на выходе даёт его аналог, но который внутри действует в форме СМКА?
2) Призываете просто переделывать вручную релизации всех существующих алгоритмов на конечно-автоматную модель?
3) Утверждаете что-то третье...

Что из этого списка ваше?

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

В случае OpenMP такое размножение более простое (см. рис.)

Модель параллельных потоков OpenMP

В общем случае может быть и посложнее картинка.

Модель паралельных процессов в общем случае

Так вот в случае КА-модели данный рисунок (т.е. практически это описание модели) будет выглядеть ещё примитивнее: просто постоянно присутствуют N потоков, где N - количество автоматов. Налицо меньшая гибкость модели. Поправьте меня, если я неправ.

Модель потоков в КА-модели

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

Вот здесь я вообще подошёл к наиболее интересному для себя моменту. Охота задать ещё один вопрос Вячеславу. То, как я описал действие КА-модели алгоритма с точки зрения обычного программиста, верно? Т.е. допустим, такая модель для нужного алгоритма есть. Работа каждого автомата независима, значит логика каждого их них реализована в отдельном потоке?

Если мои домыслы верны, то чем принципиально работа такой модели отличается модели многопоточного программирования, которую вы и за параллельное программирование не считаете?

Если же я неправ и поток действительно один, то на самом деле ВОТ ОНО ноу-хау. Фишка в том, как вам удалось запихнуть синхронную работу N независимых автоматов один поток, а сама СМКА-модель - это как раз не новизна (см. выше про VHDL). Если это действительно так, то хотелось бы уточнить для каких случаев удалось добиться такого результата. Хотелось бы верить, что не только для банального RS-триггера.

Идём далее. Понятно, что рисунки выше являются неполными. Потоки не просто работают, они ещё и взаимодействуют. В классическом варианте способы взаимодействия известны: сообщения, события, синхронизированный доступ к данным в памяти какого-то из потоков. В случае СМКА-модели сложность реализации взаимодействия будет зависеть от количества автоматов и от их связности. Ну и конечно от варианта реализации, которые я указал чуть выше: 1 поток или N потоков. Если по одному потоку на каждый автомат, то немало потоков наверно получится, каждый из которых должен ПОСТОЯННО опрашивать выходы тех потоков, которые для него являются входными. Потоки получаются сильно связаными. И не у каждого автомата всего два входа как в пресловутом RS-триггере... В общем, насколько это будет эффективно работать на объемной СМКА-модели, не знаю.

Если же всё в одном потоке (типа ноу-хау), то тут всё зависит от реализации, которую я не знаю. Но вопрос в принципе остаётся тем же: как это можно реализовать для объёмного сложного алгоритма? Всегда ли это будет эффективно с точки зрения скорости?

Ещё пара замечаний (немного критики не по существу):

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

2) Задача о преступниках, описанная в одной из статей, вообще чисто последовательная по условию! К чему там городить параллельность, я не понял.

3) Кроме того, могу в качестве бонуса пояснить, почему я не "очень внимательно прочитал все статьи" (дело не во мне, а в статьях). Но лучше я сделаю это позже, и если сам автор того пожелает. Сначала, хотелось бы обсудить то, что "по существу".

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

Идея не моя, я её всего лишь вспомнил и развил. В выходившем некогда журнале Game.EXE была рубрика с письмами от читателей. В одном из них (где-то за 2004-05 год) излагалась примерно такая идея (возможно, она родилась под впечатлением от парочки новых на то время 3D-игр, но тем менее). Сейчас уровень развития движков 3D-игр таков, что позволяет генерировать на экране картинку очень близкую к реальной, при этом с неплохим fps. Почему бы не начать делать фильмы на основе этих движков? То есть зритель уже не будет довольствоваться тем, что ему покажет одна-единственная камера, а сможет, например, наблюдать один и тот же эпизод глазами разных персонажей. Предполагалось, что это позволит глубже понять задумку режиссера и то, почему в некоторых ситуациях разные персонажи совершают определённые поступки.

Разумеется для этого придётся неоднократно отматывать видео назад, что представляется не очень удобным. Но здесь пока идет речь не об удобстве. Как показывает опыт (Apple, например), работу в любой системе можно сделать приятной и удобной.

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

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

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

P.S. Кстати уже после того как это написал, обнаружил, что Intel совместно с некоторыми организациями с громкими названиями проводит конкурс по применению высокопроизводительных вычислений («МАКСИМАЛЬНАЯ МАСШТАБИРУЕМОСТЬ – 2009»). Вроде то, что я тут изложил туда бы пошло. Вот только там нужны уже реальные проекты, а у меня пока только идея. Странно, что на форуме и блогах ISN нет никакой информации об этом конкурсе, и даже письма никакого не прислали. Хотя однажды мне (в ответ на моё письмо) обещали, что будут извещать о конкурсах и других мероприятиях в академической программе Intel, в которых я смогу принимать участие.

Кстати, там почему-то на разных сайтах разная информация о призах для победителей. Вот здесь - 250000 руб и 12500 руб, а вот здесь - 350000 и 150000 руб.

Я конечно же с интересом продолжил слушать. Вскоре стало ясно, кто рассказчик. Это был Борис Арташесович Бабаян. Он рассказывал о том, какие проблемы возникают при желании повысить производительность вычислительной системы при помощи распараллеливания, о проблемах снижения энергозатрат при вычислениях, о проблемах смены вычислительной архитектуры, о разработанной ими (я так понимаю, под его руководством) технологии двоичной компиляции. Из его слов выходило, что данная технология совершает качественный прорыв в решении упомянутых проблем. Основная её изюминка в том, что компиляция происходит под другую архитектуру, не под ту под которую писал программист, но для него это выглядит прозрачно и ему не надо переучиваться и изучать эту новую архитектуру. Эта самая "другая" архитектура сделана такой, что в ней можно эффективно реализовать отключение питания неиспользуемых блоков. По-крайней мере, так понял я - изложение было очень кратким и вскоре следом уже шёл другой сюжет - про золото (увы).

А теперь попытайтесь отгадать на каком канале я это видел. Это было на телеканале "Культура" (!!!). На телеканале "Культура". Один этот факт меня шокировал, не говоря уже о том, что я был приятно удивлен бодростью Бабаяна и тем как он интересно рассказывал. Вообще-то я когда каналы на телевизоре расставлял, специально поместил Культуру в середине, т.к. смотрю её очень редко, но переключая каналы буду регулярно на неё попадать, и может на что-то интересное наткнусь. Охота оставаться культурным человеком . Таким же образом я однажды наткнулся на передачу об Арнольде Владимире Игоревиче, ещё одном нашем академике. И если не ошибаюсь, тоже на канале Культура. Парадокс. Кстати в Википедии Бабаян всё ещё член-корреспондент РАН, а ведь он вроде бы уже академик (хотя тут я не уверен). Если тут есть активисты Википедии, приближённые к телу, уточните/поправьте.

Кстати, мне тут недавно пришло письмо с темой ISN TV. Что как нельзя кстати перекликается с вышенаписанным.  Понятно, что можно делать немало видеоматериалов, интересных людям из сферы IT/науки/computer science... Однако на целый телеканал это наверно не потянет, да и даже если потянет, в нашей стране его вряд ли организуют. Интересно, будут ли русскоязычные ролики на ISN TV? У меня эта страница что-то даже не открылась, надеюсь, это из-за наплыва посетителей. Но по ссылке понятно, что она в англоязычной части портала... А ведь есть масса интересного, что можно рассказать именно о "наших". Несмотря на многолетнее отставание отечественной электронной промышленности от мирового уровня, советские/российские специалисты продолжают придумывать в вычислительной технике и IT что-то революционное. Хотя нет, правильнее будет сказать не "специалисты", а "учёные".

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

Причем мне кажется, что пока человек считает, что он ещё может многое изобрести, сделать что-то принципиально новое, он как можно дольше старается оставаться в науке, а не уходить полностью в коммерческие структуры. Взять хотя бы Бабаяна. Наверняка бы его уже много лет назад приняли с распростёртыми  объятиями в массе мест - и в Intel, и в AMD, и в Transmeta, и ещё наверно где-нибудь... однако он до сих пор имеет свою кафедру, хотя и работает в Intel с 2004 года. У меня есть и другой пример - Кадач Андрей Викторович. В 90-е он активно занимался сжатием, писал свои упаковщики, значительно улучшал существующие алгоритмы. Начал он это делать ещё будучи студентом. Итогом была кандидатская диссертация. Кажется она тянула более чем на 200 страниц, убористым почерком. Неслабо для кандидатской. Я ей пользовался. Она и по содержанию очень сильна, особенно в те годы в ней было немало нового. Пару лет назад я был в новосибирском Академгородке, где собственно и учился Кадач, ну и спросил про него. Один человек мне рассказывал, что после защиты диссертации Кадач был завербован Майкрософтом, уехал и больше сжатием не занимается, т.к. одним из пунктов договора было то, что он продолжать свои работы не будет. А занимается он тем, что ездит по миру и вербует таких же как он хороших специалистов. Я не проверял, конечно, этой информации, нет такой возможности.

Возвращаясь к Бабаяну, хочу дать ссылку на его лекцию о работах, которые ведутся с его участием. Интересна она ещё тем, что записана до его перехода в Intel. Когда же мы увидим процессоры и компиляторы Intel в полной мере поддерживающие технологии защищённого программирования и двоичной компиляции? Делаем ставки...

1. Во-первых, нельзя не обратить внимание на исходный код алгоритмов для выдуманного компьютера MIX. Глаз программиста всегда цепляется за код в любом тексте. Хотелось бы знать, использует ли кто-нибудь этот код хоть как-то? Я не использую никак. Зачем было тратить столько времени на составление этих программ и описание архитектуры самого компьютера? Более того, в следующей редакции на описание компьютера MMIX (развитие MIX) будет посвящён (сначала я написал "потрачен") целый первый том, вместо его части как сейчас.

В поисках ответа на этот вопрос, я наткнулся на такой материал - "Чем может быть полезен MMIX". Главная мысль этой страницы, пожалуй, заключается в этих строках:

Учитывая, что удобные для изучения машины с архитектурой PDP-11 (“ДВК” “БК”, “УКНЦ”) уже ушли в прошлое, а придумывавшие процессор Intel инженеры, мягко говоря, не очень позаботились об удобстве его изучения, путь с учебной моделью сейчас становится все более предпочтительным. Отсюда MMIX как хорошо продуманная учебная модель тоже может быть использована при изложении данного вопроса.

То есть MIX и MMIX нужны для обучения. Только зачем обучаться тому, чего не используешь в реальных проектах, не знаю. Конечно, есть эмуляторы MIX. Наверняка, найдутся энтузиасты, который создадут эмулятор MMIX. Но всё же мне непонятно, какой с этого толк, кроме разминки для мозгов, если реального процессора с этой архитектурой нет. Допустим, архитектура x86 неудобна для изучения (кстати, что на это скажут инженеры Intel? мне сказать нечего, кроме того, что по-моему удобство изучения технологии в большей мере зависит от качества документации на эту технологию, чем от неё самой). Однако это реальная архитектура! И этим всё сказано. Кроме того, для начального изучения можно использовать эмулятор Emu8086, который, на мой взгляд идеален для изучения архитектуры x86 с нуля. Обладая всеми прелестями эмулятора, он к тому же содержит неплохую документацию (на себя и на саму архитектуру). Не говоря уже о тоннах документации в интернете, как от производителей процессоров, так и от обычных иссследователей. Возможно, автор имел в виду под неудобством только большое количество инструкций. Но кто же заставляет их использовать все до одной?

Насколько востребован эмулятор MIX? Я сомневаюсь, что количество скачиваний перевалило за несколько сотен. Вот к примеру, есть эмулятор от Intel для отладки программ с использованием новых инструкций из набора AVX, который реально в процессорах появится в следующем году. Выгода от такого эмулятора понятна. Освоение этих инструкций может быть выгодно для определённого круга приложений. Хотелось бы знать, сколько раз скачали инструменты для разработки под AVX? Хотя, что-то меня понесло в сторону, вернёмся к нашим баранам...

2. Второе, о чём я хочу сказать, возможно, очень тесно связано с первым Т.к. речь в книгах Кнута идёт об алгоритмах, ожидал, что максимум информации будет о высокоуровневой оптимизации (т.е. чисто об алгоритмах без их привязки к особенностям реализации). Тем не менее, немало размышлений даётся и о низкоуровневой оптимизации. Я имею в виду те места, где он говорит о возможных техниках  оптимизации, когда приходится работать с данными на магнитной ленте, перфокартах, в определённых сортировочных машинах и т.д. Да я и сомневаюсь, что этого удалось бы избежать. Когда предлагаешь что-то, всегда охота показать, что это не досужие рассуждения, а может пригодиться на практике. А поэтому волей-неволей приводишь практические примеры. И вот это обстоятельство оказало Кнуту медвежью услугу. С одной стороны объём книги возрос, солиднее стало выглядеть. С другой стороны, он сам говорит в интервью, что из третьего издания "Искусства программирования" пришлось выкинуть большую часть материала о сортировках на магнитных лентах, т.к. сейчас это никому не нужно. У меня 3-й том второго издания и в нём есть целая глава "Внешняя сортировка", где упоминаются магнитные ленты, диски и барабаны. Теперь приходится подстраиваться под другое железо. В связи с этим Кнут обещает, в следующей редакции учитывать параметры кэш-памяти и рассматривать кэш-дружественные техники.

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

В свете вышесказанного интересна тема оптимизации среднего уровня в "Искусстве программирования". Это, как известно, наиболее оптимальная реализация уже выбранного алгоритма на определённом языке программирования. Язык у Кнута свой - это MIX-ассемблер. Сейчас уже MMIX-ассемблер. MIX-программы обычно приводятся после описания алгоритма и далее почти не обсуждаются. Видимо сам такой ассемблер не очень подходит для оптимизации среднего уровня, т.к. в отличие от системы команд под x86 там нет дублирующих команд, когда одно и то же действие можно реализовать разными способами. Что тут можно сказать, никто кроме Кнута эти языки лучше не знает. Насколько я знаю, Кнут вполне открыт для обсуждения своих книг, так как опечатки и последующие исправления в таком огромном материале в любом случае бывают. И мне вот интересно, сообщали ли ему хоть одно исправление в коде MIX-программ? Если да, то значит их действительно читают!

Интересно было бы узнать от инженеров Intel, есть ли какие-то цифры о том, от какого вида оптимизации какая доля ускорения была достигнута в ваших библиотеках для высокопроизводительных вычислений за последние годы? Где-то читал, что сейчас основной прирост производительности даёт учёт параметров кэш-подсистемы, и думать об оптимизации для обычных программистов - бесполезное занятие.

Спасибо за внимание.