Журнал «Компьютерра» №38 - Журнал Компьютерра

4-кратный цифровой зум

фокусировка от 1,3 м до бесконечности

2-дюймовый ЖК-экран (технология LTPS)

разъем SecureDigital (карты до 1 Гбайт)

видео (режим web-камеры) 640x480 и 320x240

габариты 92x27x57 мм

цена $130

Трудно, конечно, порекомендовать не врагу эту новинку для использования в качестве нормальной карманной цифровой камеры (пусть и «мыльничного» типа), но если ей предстоит быть всего лишь веб-камерой, то куча возможностей будет притягательным довеском. Например, камеру можно напрямую подключать к телевизору для просмотра видео и фотографий, или к принтеру, совместимому с DirectPrint (ну почему, почему не PictBridge?! - конспирологически ориентированное сознание ясно видит тут тайный сговор). Предлагается PC-CAM 950 Slim в трех цветах - черном, серебристом и синем.

время отклика 12 мс

яркость 400 кд/м2

контрастность 500:1

диагональ экрана 19 дюймов

разрешение 1280x1024

размер пиксела 0,294 мм

габариты 543x542x223 мм

вес 7,75 кг

цена $700

Новинка сочетает в себе монитор и телевизор. Кроме стандартных интерфейсов она имеет встроенный компонентный вход SCART, что дает возможность подключить к ней не только ПК, но и, например, DVD-проигрыватель. Экран окаймлен широкой бордовой рамкой, в которой спрятаны два 3-ваттных динамики. Округлая «под хром» подставка весьма массивна и потому очень надежно удерживает монитор. Углы наклона экрана от 0 до 45 градусов. Если понадобится, монитор можно закрепить на стене с помощью VESA-совместимого кронштейна. Блок питания встроенный. Часть интерфейсов, а именно 15 Pin D-Sub, DVI, SCART, антенный, питание, а также замок Kensington скрыты массивной декоративной крышкой, остальные интерфейсы: Audio-In/Out, Video, S-Video и гнездо для подключения наушников расположены на задней панели.

13-я КОМНАТА: Ячейка, она же клетка, она же… Cell

У читателя, ознакомившегося с материалами рубрики «Архитектура ХХ века» в прошлом номере, могло сложиться ощущение, что в процессоростроении все мыслимое и немыслимое давным-давно изобретено и придумать что-то более совершенное, нежели суперскалярный OoO-процессор, невозможно в принципе. Однако это не так.

Основных «альтернативных» современному мэйнстриму путей развития два: один очень старый, второй совсем новый. Широкого распространения они пока не получили, но, может, их время еще не пришло?

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

Так может, повыкидывать из процессора все эти хитрые декодеры и планировщики и оставить только самое необходимое - исполнительные блоки, набор регистров, подсистему памяти и минимальный набор обслуживающей логики? Зачем, к примеру, заниматься хитроумным переименованием регистров, если этих самых регистров можно понаделать сотню-другую? И зачем отслеживать зависимости инструкций, если можно писать программы так, чтобы эти зависимости никогда не нарушались? Проще говоря, коли наш суперскалярный OoO-CPU все равно в конечном счете работает не с исходным программным кодом, а с неким внутренним его представлением - не лучше ли сразу записывать программы в этом представлении, обходясь без посредников? «В очередном такте исполнительному устройству X- загрузить из оперативной памяти по адресу из регистра такого-то данные и сохранить их в регистр такой-то; исполнительному устройству Y - взять данные из регистров такого-то и такого-то, сложить их и записать результат в регистр такой-то; устройству Z - проверить регистр такой-то на выполнение условия и по результатам проверки подкрутить внутренний указатель такой-то и сбросить при необходимости конвейер». Получится одна очень длинная инструкция (Very Long Instruction Word, VLIW), полностью и исчерпывающе описывающая, что каждому из блоков процессора следует в очередном такте делать.

К чему мы тогда придем? Получится архитектурно очень простой процессор, который будет очень трудно программировать: ведь придется детально учитывать его внутреннее устройство и особенности. Но если мы научимся это делать, то в качестве компенсации получим возможность изготовить сколь угодно навороченный CPU малой кровью - без всяких сверхсложных декодеров и планировщиков на три-четыре инструкции. К примеру, в отечественной разработке «Эльбрус Е2K» предполагалось одновременное исполнение до 24 инструкций за такт - при сохранении приемлемой сложность CPU. Реализовать что-либо подобное в классическом суперскалярном процессоре - нельзя; а при VLIW-подходе, не ограниченном жесткими рамками скоростного декодирования и планирования программы, - можно. Ведь никто же нам не запретит компилировать и оптимизировать программу хоть часами, хоть сутками - лишь бы потом она быстро исполнялась?

Единственная очевидная загвоздка в подобном подходе - тот самый компилятор, умеющий генерировать очень сложный технически и требующий тщательнейшей оптимизации машинный код для VLIW-процессоров. Но ведь, в конце концов, и простые компиляторы с языков высокого уровня когда-то казались чудом, а сейчас мы преспокойно используем сложнейшие компиляторы C++, работающие с парадигмами обобщенного программирования. Так что создание совершенного оптимизирующего компилятора для VLIW-процессоров - это, скорее, вопрос времени[Отрадно, кстати, сознавать, что над созданием этих «суперкомпиляторов», в первую очередь - Intel C/C++ Compiler, активно работают наши соотечественники - например, Нижегородская лаборатория (бывшая московская команда Бориса Бабаяна, разрабатывавшая компиляторы для «Эльбруса Е2К»). Нам бы, правда, к этому еще и свои процессоры с компиляторами…]. Но есть и другие проблемы.

Проблема первая - жесткая привязка исполняемого кода к конкретному процессору. x86-программа запросто может работать и на i386, и на Pentium 4; с каноническим VLIW-процессором такой фокус, увы, не пройдет. Правда, Intel в усовершенствованной версии VLIW-архитектуры (EPIC - Explicitly Parallel Instruction Computer, компьютер с явно заданным параллелизмом команд) смягчила этот недостаток, введя не инструкции, а bundles - эдакие «полуинструкции», упакованные в контейнере с информацией о взаимозависимостях между этим и другими бандлами. Предполагается, что процессор, без труда проверив бандлы на взаимозависимость, может запускать их параллельно и, таким образом, обладать некоторой «свободой действий» в проектировании будущих CPU, сохраняющих бинарную совместимость с текущим поколением.

Вторая проблема прямо вытекает из первой: довольно трудно сделать совместимые VLIW-процессоры, предназначенные для разных секторов рынка. Уж больно сильно привязан программный код к аппаратной начинке. То есть если мы делаем «супер-VLIW», с кучей исполнительных устройств и тщательно вылизанной подсистемой памяти - то ровно такой же «суперпроцессор» (с суперсебестоимостью) нам придется продавать и для low-end-сектора рынка. И наоборот, «сэкономив» и выкатив процессор для low-end и middle-end, мы получим крепкого середнячка, но не лидера производительности. Подход EPIC с его бандлами слегка исправляет ситуацию, но не до конца - дешевых Itanium в природе так и не появилось.

Третий и, пожалуй, главный недостаток VLIW - это то, что предусмотреть и спланировать все события в процессоре невозможно. К примеру, нельзя предугадать, сколько времени займет операция обращения к оперативной памяти. А раз так, то нельзя и эффективно запланировать ее: OoO-исполнения во VLIW-процессорах не бывает, и если мы думали, что данные для инструкции в кэше будут, а их там не оказалось, то весь этот сложный, «мышцастый» процессор будет простаивать десятки и сотни тактов, дожидаясь исполнения злополучной инструкции загрузки данных. В EPIC придуман способ борьбы и с этой проблемой - программную предвыборку данных, software prefetch[Это такие специальные инструкции, которые позволяют процессору параллельно с основным исполнением запросить фоновую подгрузку в кэш-память определенных данных, если их там еще нет.]; однако подсистема памяти до сих пор остается одним из самых узких мест любого VLIW-процессора.

Идея VLIW отнюдь не нова - еще в середине 80-х годов корпорация Intel пыталась продвигать весьма неординарный VLIW-процессор i860. Однако описанные проблемы и отсутствие по-настоящему эффективных оптимизирующих компиляторов поставили крест на i860 еще до его практического рождения. Да, i860 был «суперкомпьютером на чипе», да, он опережал свое время, но как процессор общего назначения - никуда не годился[Теоретический максимум производительности - 60 Мфлопс. Практический максимум для программистов, вручную оптимизировавших код для i860 на ассемблере, - 40 Мфлопс. Производительность обычного компилятора для i860 - не более 10 Мфлопс. Производительность рабочих станций на первом коммерческом MIPS R3000 - 9 Мфлопс; на первом Intel Pentium - 15-40 Мфлопс.]. Для него требовались специальные сложные компиляторы и новая инфраструктура - и все лишь ради того, чтобы в конце концов получить производительность, в большинстве случаев уступающую производительности стремительно развивавшихся RISC-конкурентов! i860 мог быть очень быстрым процессором для вычислений с плавающей точкой - но между «мог» и «был» в большинстве приложений зияла огромная пропасть, которую было проще преодолеть, положившись на технический прогресс, благодаря которому даже безнадежно «тормознутая» в те годы архитектура x86 через несколько лет достигла такого же уровня производительности. Некоторое время Intel 80860 использовался в качестве специализированного программируемого DSP-процессора (графического ускорителя), но заметного распространения даже в такой ипостаси не получил.