19 января

Трансмета опубликовала описание того, что разрабатывалось в секрете столько времени.

Увы, все, в принципе, знали, что там на самом деле происходит и, ещё раз увы, ничего сверхудивительного из недр не вышло. Да - это VLIW-процессор, как и Мерсед, как и Эльбрус 2К. Да, для него есть софтверный конвертор инструкций x86 в родной набор команд, но ничто не мешает написать аналогичный для Мерседа или какого-либо ещё процессора. Да, трансметовский процессор прост и работает при температуре в 40-50 градусов, а не 100-120, как Пентиум.

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

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

Что это за процесс - двоичная трансляция. В принципе, ничего нового. Любой Pentium II, III и Pro делают её, фактически, в железе постоянно. Трансметовцы просто вынесли её за рамки процессора. Процессор исполняет свой набор инструкций, программа написана в своём. Преобразование втрого в первый происходит динамически - как у Java, между прочим.

В чём прелесть подхода? Ну, во-первых, совместимость. :-) А во-вторых - реальная совместимость. Дело в том, что 486-й и Pentium II совместимы лишь формально. Реально, чтобы получить от второго максимум быстродействия, программу под него нужно компилировать специфическим образом - с учётом временных характеристик процессора.

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

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

На базе Крузо, между прочим, можно построить нетривиальный вариант ассиметрично-двухпроцессорной машины. Один процессор будет транслировать код, другой - исполнять. Очевидно, что первый будет загружен не на 100%, но за то не будет стоять вопрос о распараллеливаемости кода - эта система сможет исполнять любой код в два процессора. Ну, точнее, в полтора. :-)

Вынос транслирующей прослойки из процессора в программное обеспечение позволяет, для начала, облегчить кристалл, что уже само по себе здорово - проще добиться высокого выхода годных процессоров, проще конструировать компьютеры, легче наращивать тактовую. Но главное - гораздо проще добиться высокого качества кода. Code morphing software - та самая прослойка, будучи твёрдо уверена в том, под какой именно процессор генерируется код, имея доступ ко всему "исходному коду" программы и располагая всей мощью компьютера, в состоянии выполнить трансляцию оптимальным путём, получив идеальный (ну, близкий к идеальному) результат.

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

Оба плохи. На практике морфер (code morphing software) делает нелёгкий выбор между поблочной трансляцией и исполнением и интерпретацией, выбирая то, что по его мнению более уместно в данный момент.

Странслированные блоки хранятся в памяти - это своеобразный кеш, размер которого может варьироваться. Как и всякий кеш, он удорожает систему - теперь в компьютер нужно ставить больше памяти. Насколько больше? Неизвестно. Известно впрочем, что если кеш меньше определённого размера, то он будет работать крайне неэффективно - почти впустую. Это происходит, если в кеш не умещается рабочее множество. В таком случае старые блоки то и дело будут вытесняться из кеша, не успевая "дожить" до повторного использования, может быть, всего пару сотен команд. Определить правильный размер кеша - непростая задача, и пока неочевидно, решила ли её Трансмета. Моя ставка - на то, что не решила.

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

Ладно, на сём закончим общий разговор - завтра напишу о деталях.

Забор или запас.

From: Dmitry E. Kim Subject: www.lenta.ru привет, Собственно, насчет ленты.ру и идеи про то, что можно не заморачиваться с секьюрити вообще, а просто держать копию контента и все такое. Насколько я успел отследить, взлом ленты.ру был осуществлен путем модификации записей в DNS-е. Т.е. адресная запись ("IN A" record), описывающая хост www.lenta.ru, была модифицирована таким образом, чтобы возвращать адрес некоторой некоторой машины, кажется, в подлипках, похаканной заранее. на которой, собственно, и был размещен message, процитированный в твоем последнем обозрении. Очевидно, что в связи с наличием такого явления, как кеширование DNS, даже после полной починки персоналом ленты того, что было сломано, модифицированная IN A record будет вводить в заблуждение броузеры большого числа людей на протяжении оговоренного в SOA Time To Live, что составляет, как правило, не меньше суток. Так что все эти идеи о быстровосстанавливаемых копиях контента -- довольно вредное заблуждение. Есть много способов портить жизнь хозяевам вебсайтов, и rm -rf $HTDOC/*; echo "i'm VERY BIG" > $HTDOC/index.html -- один из самых безобидных :). И, кстати, с индикацией взлома проблемы те же самые. Разнообразие способов и потенциальных проявлений настолько велико, что отмониторить все и вся без человеческого непрерывного участия кажется нереальным. have a nice day, jsn.

Гм. Наводит на мысли о журналирующих файловых системах, которые гарантируют быстрое восстановление именно метаинформации после краха системы - структуры каталогов и т.п. - но не пользовательской (содержимого файлов).

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

Весьма нетривиальный аргумент! :-)

From: Peter Ivanov Subject: Digital photo Привет пропагандистам цифрофото! Вот мой аргумент в его защиту: если мне присписчит сделать пикантные фотки (каюсь, грешен :), то как я их обработаю? В минилабе, что ли? Простите, но не идет нога. Это чтобы вся контора их изучала? Да еще себе на память пару кадров оставят. Хорошо, пусть они суперчестные и порядочные, но я ж автоматически покраснею, когда буду получать "результат"! Вот цифра - другое дело: и камера, и минилаб - все мое, приватное. Всего самого, Петр.

Продать порнографию сотруднику минилаба - задача невыполнимая. Как показывает практика, у него на работе - почти непрерывный поток. :-) Особенно - летом. Отнюдь не все так стеснительны, Пётр, как мы с Вами. :-)