 |
| 
Люблю революции. Когда "всю жизнь" гланды удаляли через... одно место, а потом кому-то вдруг
пришла в голову революционная идея - удалять через это место не гланды, а геморрой.
Есть (ну... "бывает") у компьютерщиков такая странная потребность - гонять "систему в системе"
("систему в пробирке"). Грубо говоря, жить в винде (линухе, бзде, нужное вписать), но для
каких-то целей (экспериментов, работы, наладки-проверки) - запускать на том же компьютере другую
ОС (или другой экземпляр той же ОС).
"Всю жизнь" (точнее, всю ту жизнь, когда это делалось не через перезагрузку всей машины)
это делалось через "эмуляторы". Сначала - "виртуальные дос-машины" (для доса, а потом и для win16)
в os/2 и NT (да, да, а ещё 95 и 3.11), затем, по мере роста мощности -
vmware (первый известный мне проект "виртуального писюка на реальном писюке"), сейчас - ещё и virtualPC,
и что ещё будет дальше...
Проблема "виртуальных писюков" одна: средствами, не предназначенными для виртуализации всего на свете
(ну не разрабатывался intel х86 для виртуализации совсем всего на свете, только для ограничения
приложений лазить куда не попадя, да частично - "дос-машину" создать, чтобы "в песочнице" некапризные программы гонять)
- виртуализовать пытаются как раз всё на свете, от памяти (совсем просто), до процессора
(а операционные системы так просто не проведёшь, ОС сейчас хотят реальный процессор, ядро в нулевом кольце привелегий,
и вообще полную власть), и всего необходимого железа (и работа с IDE или видеокарой при этом
будет напоминать бокс по переписке: каждое шевеление ОС будет вызывать поток экспешнов, в ответ на которые
эмулятор будет эмулировать поведение реального железа)... в-общем, сложно, медленно,
да и невозможно в полной мере скорее всего (не зря OS/2 так под vmware и не грузится - видимо, хочет чего-то
неэмулируемого).
Но я - про революции. Возмем линукс. Линукс - портабелен на черт-те какие аппаратные платформы,
включая наручные часы с ЧПУ (кажется, IBM этим хвастала). Что мешает спортировать линкс на,
скажем так, не совсем аппаратную, но всё же - платформу?
Да ничего не мешает. И в светлые головы линуксоидов сначал приходит идея "линуха
в линухе" (http://user-mode-linux.sourceforge.net),
а зетем - "линуха под виндой" (http://colinux.org).
Идея - как я уже написал, "спортировать линух под новую платформу". Ну и что, что платформа не
совсем аппаратная - если линукс нормально чувствует себя на наручных часах с ЧПУ - значит, выживет и
в виде бинарника под win32. На самом деле, под винду не всё так просто и безоблачно... но идея-то какова, а?
Р-революция! Теперь каждая домохозяйка сможет поставить себе "линух фор виндовз" - рядом с "офис фор
виндовз" и микрософт-интернет-эсплойтером. Р-революция - машина в машине без оверхеда на эмуляцию
неэмулируемого! Машина в машине - и это без тормозов! Только в XXI веке стало возможным столь революционное...
...постойте-ка, что-то знакомое вспоминается. Где-то когда-то вроде было, нет? А, вспомнил!
VAX/VMS. Digital Equipment Corporation - помним такую? Нет? Забыли. Жаль. Ну, PDP-11 помним? Тоже нет...
Ладно, БК-0010 и ДВК-11 - помним? Хорошо :-) БК и ДВК - делались на базе процессора, содранного с
DEC PDP-11. Ещё "на базе DEC'а" у нас делалась СМ-4 (хреновина из нескольких шкафов с терминалами)...
а больше из нашего я ничего и не припомню, ибо был мал и не очень интересовался :-)
Так вот, этот самый DEC в 1978 (тысяча девятьсот семьдесят восьмом) году выпустил операционную
систему VMS для своего компьютера VAX. VAX - расшифровывалось как "virtual addresses extention", VMS -
"virtual memory system". Нетрудно догадаться, что в VAX/VMS применялась не так уж давно доползшая до
писюков концепция виртуальной памяти. А ещё, из интересного мне сейчас в контексте -
в VMS изначально, штатно, и без извратов была возможность запустить систему в системе!
При этом без извратов вроде эмуляции железа - возможность запускаться не "надо всеми" а "под кем-то"
была предусмотрена системой штатно (и активно использовалась - удобно, знаете ли, отлаживать
"ядрёный код", когда крах ядра приводит не к краху всей системы, а просто к смерти одного из процессов,
запущенных под "вышележащей" копией ОС. Никому не мешаем, отлаживаем всё что хотим... запустивши ОС
под другой копией ОС.
...и глядя на современные "Р-революции!" в мире писюкостроения (преподносимые, разумеется, как
новейшие разработки микрософт, интел, и кого-там-ещё) - грустно становится. Поскольку более чем половина
- "калька" идей, реализованных два (а то и три) десятка лет назад на "больших машинах".
Причем реализация эта, как правило,"слишком революционна" - совместимость писюка с original IBM PC
затертого года выпуска сильно ограничивает. Впрочем, требование совместимости с каким-нибудь
"пентиумом-166ММХ" ограничивает ещё сильнее, ибо от "диггера" мы ещё как-то откажемся,
а вот от винды - вряд ли. А винда - она хочет пень. И программы - хотят пень, а не принципиально
новую архитектуру, будь она хоть в десятьраз лучше. Вот и "обстругивают" хорошие идеи так, чтобы
они "втиснулись" в гробик аппаратной совместимости с 8086 да виндовз-2000...
В тему.
Современный "интел пентиум" содержит в своем АЛУ - кучу узлов. Всякие складывалки, множилки, отдельно FPU,
отдельно SSE[2], отдельно то, отдельно сё, отдельно чёрт в ступе... и используются они, в основном,
"по очереди" - если сейчас процессор выполняет команду умножения двух целых чисел - узел извлечения
квадратного корня простаивает.
Чтобы увеличить производительность процессора - можно попытаться
"распараллелить" выполнение команд: если текущая команда не влияет на результат следующей -
то можно одновременно выполнить обе команды. Если же влияет - то нельзя. (К слову - уж не
в советских ли времен "эльбрусе" было "предвыполнение" команд: при наличии свободного
"выполнителя" выполнялась следующая команда, если результат "не пригождался" - его выкидывали?)
В идеале, при полном распараллеливании, это дает выигрыш в два раза. Реально - сильно меньше:
и не только потому, что команды плохо распараллеливаютс, но и потому, что
алгоритм обнаружения возможности распараллеливания внутри процессора - долен быть быстр
(иначе тормозить процессор начнет он сам), и умён неестественным интеллектом (программы-то
пишутся исходя из линейного выполнения кода). В результате - сложность процессора растет,
производительность... ну, типа тоже да. Кроме того - растет сложность оптимизирующих
компиляторов: компилятор теперь занят
забавным делом: расставляет инструкции так, чтобы (1) они распараллеливались и (2) - чтобы
процессор смог это понять :-) и таки действительно распараллелил их выполнение.
Забавная ситуация, не правда ли? Чтобы немного снизить идиотизм ситуации -
интел придумал "гипертрединг" - когда процессор молотит команды в два потока (как будто в нем сидит два процессора),
но при этом АЛУ - одно, и используется "по возможности одновременно" обоими "половинками"
процессора. Выигрыш - полтора-два раза (поскольку на однотипных задачах конкуренция
за одно АЛУ таки случается часто), и это уже сильно лучше, чем то "как-нибудь"
с обменой намёками о возможности распараллеливания между компилятором и процессором.
...а ведь существует EPIC - explicit parallel instruction computer. Где возможность распаралеливания
команд - задается в виде флажка в самой команде. Что автоматически позволяет выкинуть нафиг
узел "неестественного интеллекта" процессора, упростить компиляторы, поднять эффективность использования
АЛУ, да ещё и обеспечить глубину не в 2-3 команды за раз, а в "сколько влезет в флажки". Вот только...
с 8086 оно как бы несовместимо, и потому - на писюках не будет.
Ибо диггер работать не будет.
А жаль.
| |
| |