Журнал «Компьютерра» №38
Шрифт:
вес 396 г
цена от $1500
Нечто среднее между ультрапортативным ноутбуком и карманным компьютером. Дизайн со времени предыдущей модели (без плюса) почти не изменился, лишь чуть подправлены внутренности. Компьютер работает под управлением Windows XP (производитель уверяет, что 01+ самый маленький КПК для этой системы). В качестве опций предлагаются VGA-адаптер, зарядное устройство и прочный анодированный металлический чемоданчик (все совместимо и с OQO model 01). В комплект входит цифровое перо.
два процессора IBM Cell BE
память Rambus XDR (eXtreme Data Rate)
Ну вот, игры кончились… Теперь у процессора Cell появилось серьезное применение - блейд-серверы. Используется
5-Мп 1/1,8-дюймоввый сенсор
объектив с фиксированным фокусным расстоянием 8,25 мм
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-процессора.