«Открытые системы»

Новые сервера Sun были созданы «с чистого листа»; в нынешней ИТ-индустрии такое встречается нечасто

Для преставления нового семейства серверов в Москву приезжал Марк Тремблей, вице-президент Sun Microsystems, главный архитектор отдела масштабируемых систем, обладатель титула Fellow, который крупные технологические компании присваивают своим наиболее выдающимся разработчикам. Он ответил на вопросы редактора журнала «Открытые системы» Леонида Черняка.

Если я правильно понимаю, Niagara появился на свет в результате сложного эволюционного процесса, его создание длилось более десяти лет. Мне встретилась работа по многопотоковым вычислениям, написанная Грегом Паподопулосом, нынешним техническим руководителем компании, в начале 90-х годов, еще в бытность научным сотрудником Массачусетского технологического института. Вы сами тоже много лет отдали проектированию процессоров, в том числе MAJC (Microprocessor Architecture for Java Computing), это был своего рода ответ Sun на еще только появлявшуюся архитектуру IA-64. Купленная компания Afara с ее процессором Hydra, непосредственным предшественником Niagara, тоже не новичок, она была основана на результатах исследования, которые велись в Стэндфордском университете с начала 90-х. Как вы себе представляете этот внутрикорпоративный эволюционный процесс?

Марк Тремблей: «Мы сами поражены тем уровнем производительности, которого удалось достичь»

Работе с потоками посвящено большое количество академических исследований. Наш интерес к этому направлению волне объясним. В необходимости работы с потоками своими силами мы убедились, когда стали разрабатывать схемы коммутаторов, в архитектурах серверов они должны были заменить собой шины. Что же касается упомянутого вами процессора MAJC, то здесь действительно было сделано кое-что по части управления потоками, что-то из разработанного удалось реализовать в серверах, но в целом проект остался незавершенным. Наша ошибка состояла в том, что в то время мы в большей степени ориентировались на настольные компьютеры. Заблуждение вполне объяснимо: мы начинали тогда, когда считалось, что применение языка Java будет ограничено разного рода устройствами и настольными компьютерами, даже в Sun мы не могли предполагать такого успеха Java на серверах.

Мы были не одиноки в своем заблуждении. Компании Corel и Lotus пытались сделать офисные приложения целиком на языке Java, но и у них ничего не вышло. На границе 1999-2000 годов мы переориентировали проект MAJC в направлении серверов, мы пытались сделать 8- и 16-потоковые процессоры. Но, как вы знаете, после этого начались не лучшие годы для компании, тогда в целях экономии мы решили сосредоточить свои усилия на отработанных технологиях SPARC. Несколько лет мы работали над реализацией многоядерности и многопоточности, не выходя за рамки отработанных нами технологий. И вот однажды мы заметили Afara Websystems, у компании были интересные идеи, но они испытывали сложности с финансированием и искали поддержки. Нас привлекло то, что они в своем проекте Hydra ориентировались на архитектуру SPARC.

Но начинали они с MIPS?

Да, начинали они с архитектуры MIPS, но когда команда Afara окрепла, особенно когда в нее вошел Лес Кон, активно участвовавший в свое время в разработке UltraSPARC I, они переориентировались на архитектуру SPARC. Должен признаться, я был поражен увиденным и сразу понял, что нужно покупать эту компанию. У меня возникли два соображения, во-первых, переориентируясь на многоядерную архитектуру, мы сможем покончить с противоречиями относительно будущего, а во-вторых, если небольшая компания смогла сделать это, то мы с нашим потенциалом сделаем лучше.

Итак, мы купили компанию, в ней работало тогда около восьмидесяти инженеров, вслед за этим сократили часть собственных проектов и собрали коллектив примерно из двухсот разработчиков. Мы смогли довести проект до ума, повысить частоту, добиться большей совместимости. В итоге получился UltraSPARC T1, который является непосредственным преемником проекта Hydra. Но практически одновременно был начат параллельный проект, мы разрабатываем архитектуру Rock, в ней мы сможем реализовать все те наработки, которые накоплены в проекте MAJC и появятся в будущих поколениях UltraSPARC. Это гораздо больший по объему проект, с привлечением большего числа людей, с множеством новых изобретений.

Проблема сложности является одной из важнейших в отрасли, и особенно при создании процессоров. Как вы ее преодолеваете?

Сложность определяет время подготовки продукта до вывода на рынок, размер команды разработчиков, стоимость разработки, количество обнаруженных ошибок и также работы, которые необходимо выполнить после того, как кристалл готов. Мы подошли к проектированию, учитывая названную проблему. Поскольку процессор многоядерный, то есть возможность использовать один и тот же набор транзисторов много раз, поэтому проектированием занималось всего двести человек, что очень мало по стандартам не только Intel, но даже IBM.

Кроме того, мы четырежды используем репликацию внутри ядра — по числу потоков, и еще восемь раз, потому что восемь ядер, умножьте четыре на восемь и получите величину, характеризующую упрощение процесса разработки.

Кроме того, мы пошли по пути предельного упрощения ядра. Мы удалили условную многопотоковость, некоторые сложные команды — это, безусловно, поможет нам при проектировании процессоров следующего поколения.

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

Какое из решений, принятых при подготовке UltraSPARC T1, вы считаете для себя самым важным?

Самое ответственное решение заключается в том, чтобы сказать: «Мы начинаем с чистого листа». Мы решили создавать специализированный процессор. Некоторые называют его нишевым продуктом, и я с этим согласен: у него одна ниша — Internet. А самое большое удовлетворение — убедиться в правильности принятого решения. Мы сами поражены тем уровнем производительности, которого удалось достичь.

Сегодня работу серверов Sun Fire T1000 и T2000 поддерживает только операционная система Sun Solaris. Что вы скажите относительно других ОС?

Мы считаем перспективным использование Linux и BSD Unix. Для этого мы открыли спецификацию, хотя понимаем, что для создания обладающей теми же характеристиками масштабируемости операционной системы Linux, что и Solaris, потребуется немало времени. Так или иначе, возможность адаптировать эту операционную систему к многопотоковому и многоядерному процессору открыта всем — в том числе и программистам из России.