Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

Хостинг + Certum Commercial SSL и домен в подарок

VPS: SSD, KVM, бесплатные бэкапы и администрирование 24/7

Бесплатный перенос сайта + подарки к новоселью

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

Рабы закона Мура

Страницы: 1 :: 2 :: 3 :: следующая

 

Зако́н Му́ра — эмпирическое наблюдение, сделанное в 1965 году (через шесть лет после изобретения интегральной схемы), в процессе подготовки выступления Гордоном Муром (одним из основателей Intel). Он высказал предположение, что число транзисторов на кристалле будет удваиваться каждые 24 месяца.

ВикипедиЯ

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

Прошлое

Я снова буду говорить только о том, что видел собственными глазами. Наверное, можно было бы найти много других примеров, но они были бы для меня более абстрактными.

Начнем с БЭСМ-6. Эта машина проектировалась в ИТМ и ВТ при тесном взаимодействии инженеров-электронщиков и программистов и поначалу была идеальной платформой для требовавшихся в то время операционных систем. Обеспечивался простой и понятный механизм обработки внешних и внутренних прерываний, поддерживался привилегированный режим работы процессора с небольшим числом специальных команд, имелась аппаратная поддержка механизма виртуальной памяти и т.д. Первая операционная система для БЭСМ-6 (Д-68) действительно продолжала аппаратуру и (похоже) идеально с ней гармонировала.

Но у БЭСМ имелись два серьезных ограничения, которые не были ограничениями в конце 1950-х гг., но стали таковыми через 10 лет. Во-первых, длина адресной части команды составляла всего 15 разрядов и, тем самым, предельный размер виртуального адресного пространства составлял 215 6-байтовых машинных слов. При этом страницы виртуальной памяти были достаточно длинными – 1024 слова. Поначалу объем физической оперативной памяти в БЭСМ-6 также ограничивался объемом в 32 страницы, но со временем был расширен до 256 страниц. Малая виртуальная память стала ограничивать пользователей машины.

Во-вторых, к началу 1970-х гг. в связи с появлением проекта EC ЭВМ в странах «социалистического лагеря» стали массовым образом производиться внешние устройства, снабжаемые контроллерами и подключаемые к процессору на основе аналогов аппаратуры канала IBM. Эти внешние устройства (громоздкие и ненадежные) были все-таки более прогрессивными, чем доморощенные внешние устройства БЭСМ-6, и потребители желали ими пользоваться.

Первое ограничение БЭСМ-6 пытались преодолеть в ОС ИПМ. В этой операционной системе была сделана, в частности, программная реализация механизма управления виртуальной памятью, и виртуальное адресное пространство, поддерживаемое аппаратурой БЭСМ-6, было значительно расширено. С одной стороны, это был очень прогрессивный по тем временам шаг на пути к построению машинно-независимых ОС, но, с другой стороны, из-за принятия такого решения ОС ИПМ работала заметно медленнее других операционных систем для БЭСМ-6 и по этой причине использовалась в меньших масштабах. И уж, конечно, нельзя сказать, что ОС ИПМ гармонировала с аппаратурой БЭСМ-6; она ее не столько дополняла, сколько исправляла на программном уровне.

Второе ограничение было невозможно обойти чисто программными средствами, и в ИТМиВТ был образован проект АС-6 (о котором я уже говорил в первой заметке), исходной целью которого являлось создание «аппаратуры сопряжения» устройств ЕС ЭВМ с БЭСМ-6 (отсюда и происходит аббревиатура АС-6). Как уже отмечалось, этот проект быстро преобразовался в проект по созданию многомашинного вычислительного комплекса, в который, помимо БЭСМ-6, вошли новые компьютеры ПМ-6 и ЦП АС-6. ПМ-6 представляла собой специализированный компьютер, в котором развивались и расширялись идеи канала IBM, и к которому непосредственно подключались контроллеры устройств ЕС ЭВМ и других заново разрабатывавшихся устройств (в частности, сетевых контроллеров). В архитектуре ЦП АС-6 разработчики пытались преодолеть все известные к тому времени недостатки и ограничения БЭСМ-6 и сделать машину, «идеальную» для будущей ОС и разработчиков приложений. При этом следует особо отметить, что весь проект АС-6 с самого начала выполнялся совместно инженерами и программистами.

Что же в результате получилось? Как я писал раньше, операционную систему для ЦП АС-6 было делать очень интересно, и во многих отношениях она получилась удачной. Но при этом ОС ЦП «жила» в среде АС-6 совершенно естественной жизнью, поскольку именно для такой жизни она и предназначалась. На основе аппаратной поддержки в этой ОС была реализована специальная служба обмена сообщениями между компонентами АС-6, и эта служба естественным образом интегрировала ЦП с остальными компонентами. Однако ОС НД-70, которая использовалась в качестве основной ОС БЭСМ-6 в составе АС-6, была организована с этой точки зрения совсем не так естественно. Теперь в БЭСМ-6 можно было использовать как собственные внешние устройства, подключенные через ее «родные» интерфейсы, так и новые ресурсы, доступ к которым был возможен только через локальную сеть АС-6. Причем сам этот доступ осуществлялся через традиционный интерфейс БЭСМ-6. Даже если не вдаваться в подробности, видно, что «идеальной» гармонии операционной системы с новой аппаратурой снова не получилось.

На самом деле, идеала не удалось достичь и в ЦП АС-6. Во-первых, в составе ЦП имелась аппаратура (очень интересная и сложная аппаратура, позволяющая сохранять и динамически восстанавливать регистровый контекст процессов), которая, по сути, использовалась только для отладки операционной системы. Изначально мыслилось, что эта аппаратура будет использоваться в подсистемах поддержки времени выполнения языков программирования с динамическими контекстами (типа Algol-60). Однако в ходе разработки выяснилось, что у пользователей АС-6 нет заинтересованности в таких системах программирования. В системе команд АС-6 имелись и такие средства, которые не использовались ни в ОС, ни в компиляторах, ни в приложениях, в частности, средства машинной арифметики с фиксированной точкой.

Кроме того, а общесистемном уровне имелась аппаратура, позволяющая любому компоненту АС-6 иметь прямой доступ к основной памяти любого другого компонента. В ЦП это достигалось просто путем формирования соответствующего «машинного» адреса. Так вот, возможность записи в «чужую» память не использовалась ни в одной операционной системе (доступ по чтению использовался в упомянутой службе обмена сообщениями). Мне кажется (я не могу утверждать это обоснованно), что ровно так же обстоят дела в существенно более новых вычислительных системах, которые относятся к категории NUMA (Non-Unified Memory Access).

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

Между прочим, аналогичные наблюдения распространяются и на всеми нами любимые компьютеры компании Digital Equipment серий PDP-11 и VAX-11. Если я не ошибаюсь, аппаратная поддержка сегментной виртуальной памяти в PDP-11 не использовалась ни в «родной» ОС компании DEC RSX-11 (там применялся механизм мультизадачности с постоянными разделами основной памяти без какой-либо подкачки или свопинга), ни в UNIX для PDP-11, где использовался простой свопинг. Несмотря на все удобство для операционных систем общей архитектуры и системы команд компьютеров семейства VAX-11 70% команд этой микропрограммной машины никогда не использовалось компиляторами. Сомневаюсь, что кто-то отважится назвать это гармонией.

Тем не менее, у компьютеров прошлых лет имелась одна общая особенность. Операционные системы для них делались в тех же организациях, где и аппаратура. Разработчики аппаратуры имели представление о замыслах программистов (и наоборот), и они, по крайней мере, стремились к гармоничности аппаратных и программных решений, хотя идеала достичь и не удавалось. И тогда закон Гордона Мура) еще не оказывал такого давления на разработчиков аппаратуры, а программисты не были его рабами.

Страницы: 1 :: 2 :: 3 :: следующая

CITKIT.ru
Цикл "Операционные системы:
Ностальгия по будущему
"

Комментарии

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: следующая

Rigdzin, Пн 30 мар 2009 18:07:11:
Ну да наверное не понимаю, наверное это я пытаюсь заставить процы общего назначения рисовать графику и при этом назвать это графическим ускорителем Лараби. Типа не видно, что интел в своем лараби скрещивает бегемота с носорог. Аноним, если так хорошо понимаешь разницу между Cisc и RISC, вспомни времена Альфа процессоров - эти компьютеры были быстрее чем РС.
аноним, Пн 30 мар 2009 17:08:27:
2 Rigdzin, понедельник, 30 марта 2009 г. 15:54:55:
>Ну да наверное не понимаю, наверное это я пытаюсь заставить процы общего назначения рисовать графику и при этом назвать это графическим ускорителем Лараби.

А никто и не пытается. Интел тупо хочет выпустить процессоры с интегрированной графическим ускорителем. Типа как интегрированная графика в чипсет, но только в процессор. Чтоб никто (Нвидия) не смог бы выпускать чипсеты с интегрированной графикой под интеловские процессоры.

>Типа не видно, что интел в своем лараби скрещивает бегемота с носорог.

Ну да. Бегемот с носорогом. Но зато надеются отвоевать нишу встроенной графики.

>Аноним, если так хорошо понимаешь разницу между Cisc и RISC, вспомни времена Альфа процессоров - эти компьютеры были быстрее чем РС.

Наверное, x86? Так вот, тогда они вообще были самыми медленными. Но и самыми дешёвыми. Такие дела.
Rigdzin, Пн 30 мар 2009 15:54:55:
Ну да наверное не понимаю, наверное это я пытаюсь заставить процы общего назначения рисовать графику и при этом назвать это графическим ускорителем Лараби. Типа не видно, что интел в своем лараби скрещивает бегемота с носорог. Аноним, если так хорошо понимаешь разницу между Cisc и RISC, вспомни времена Альфа процессоров - эти компьютеры были быстрее чем РС.
аноним, Пн 30 мар 2009 10:48:50:
Спешу сообщить, что Rigdzin - мудак, который не понимает, чем отличаются RISC и CISC архитектуры, в чём их преимущества и недостатки. Так же он не понимает чем отличаются специализированные процессоры (типа процессоров видеокарт) и процессоры общего назначения. А вполне очевидные и ожидаемые ходы Интела после провала покупки Нвидии рисует в каком-то странном свете.
аноним, Вс 29 мар 2009 01:07:10:
Персональный суперкомпьютер Tesla: 960 ядер, размер десктопа, питание по обычному кабелю, цена 12 тыс долл.
http://www.cs.msu.su/messaging/forum/news-details.html?id=42034956
Rigdzin, Сб 28 мар 2009 16:18:46:
Разница между х86 и RISC-процессорами на заре микропроцессоров и персоналок была неочевидна. Ведь тогда каждый проц исполнял инструкции программы поочередно - сначала загружал инструкцию из оперативки потом исполнял, и так каждую иструкцию. А вот когда уже началась конвееризация исполнения.. и тем более процы стали суперскалярными. х86 процу для такой эффетивной загрузки исполнительного конвеера как у RISC,нужны дополнительные схемы. В пользу этого говорит тот факт, что х86 процы вот уже скоро как 15 лет перекодируют свои родные х86 инструкции в RISC формат и только потом отправляют их в конвеер на исполнение. Я искренне считаю, что х86 МАСТ ДАЙ
Rigdzin, Сб 28 мар 2009 16:05:17:
И еще забыл сказать - у RISC-процов напрочь отсутствуют схемы перекодировки команд в какой-либо другой формат. Ну нет у них такой неообходимости, они исполняют свои команды тупо - напрямую. За счет отсутствия этих схем RISC-процы получаются проще.И скажите мне, какие такие задачи есть, что х86 может решить, а РИСК типа не может?
И на домашний комп я себе поставил ОпенСолярис.
Rigdzin, Сб 28 мар 2009 15:52:56:
Чтобы программировать аппаратуру с наибольшей эффективностью и наименьшими проблеммами для программиста - надо программировать не интел архитектуру.
Вообще интел архитектура - это уродливое порождиние человечества(впрочем как и PowerPC). Ведь каждый нормальный программер знает, что иа имеет нефиксированную длину команд - разные команды имеют разную длину в байтах(У пауэрписи такая же фигня). А RISC-процессоры обладают строго фиксированной длиной команд, у SUN SPARC и DEC Alpha 32 бита. х86-процу нужны дополнительные схемы и соответственно транзисторы, которые бы учитывали длину каждой команды, которая поступает на исполнение, а также появляются дополнительные задержки в процессе исполнения, и возникают из-за анилиза той самой пресловутой длины. А еще схемы предсказания ветвления имеют сложную структуру и огромные размеры, ведь им надо учитывать или вычислять длину команды, которая будет следующей. Плюс к этому, каждый сегоднашний проц х86 архитектуры, начиная с ПентиумПро у и нтела и К5 у АМД, имеют схемы, которые переводят х86 иструкции в RISC-инструкции, которые исполняются непосредственно процом, бо видите-ли исполнение таких команд легче конвееризируется и паралллелится. А еще надо организовать дополнительный цикл доступа в память, бо видите-ли в прошлом цикле одна команда поместилась только на половину, а вторая половина осталась в оперативе, а не в кэше.

Это ж как надо намучаться программистам,которые пишут хороший оптимизирующий компилятор. Это компилятору каждый раз, когда он генерирует процессорную инструкцию надо учитывать длину инструкции, а когда их у вас чуть-ли не около 300-х сот только в 386 проце, и все разной длины! Во зоопарк, а? А еще когда интел начинает плодить всякие SSE со скорость кролика.Ну хорошо ССЕ, ССЕ2-3 - имели яркио выраженый смысл, но когда появляются ССЕ4-4,1-4,2.Вполне возможно, что и ССЕ4,х имеет смысл, но я начинаю сомневаться.
А еще у каждого проца есть тонкости исполнения, он видите-ли должен передохнуть после этой инструкции, а 2 сякие инструкции ему в декодер не лезут, а вот одна такая и одна сякая лезут. КАк можно создать компилятор С++ например в таких условиях, что бы он делал проги со 100% КПД, ну пусть не 100 пусть 95?
А например набор команд SPARCv9 не менялся 10 лет.
То что такое уродство получило повсеместное и подаляющее распостранение - заслуга не столько интела, сколько IBM и Microsoft. Да и не так уж давно она получила такое распостранение. Еще в середине 90-х в европе была популярна Амига, кстати - эта система от рождения имела аппаратное ускорение графики и звука на много раньше РС. И 3dMax был рожден для амиги и только потом перекочевал на РС.
IBM, когда выпускал свой первый РС - исповедывал принцип открытой архитектуры, когда каждый желающий мог производить оборудование для этого компа. И это был первый фактор широкого распостранения, ведь сразу появились делки, которые захотели заработаь на производстве оборудования к писюкам. Второй фактор сработал, когда появилась Винда 3.1.
И сколь интел с АМД не красят это уродство - оно постоянно вылазит из под краски, то большим энергопотреблением, то огромным числом транзисторов и малым числом ядер, то видите-ли плохо оптимизированой программой. Это видите-ли не проц плохо прогу исполняет - это оптимизация плохая, а то что под такого Квазимодо как х86 просто не возможно сделать хороший компилятор - кажется никого не волнует.
Последние 2,5 года много шума вокруг огромной вычислетельной мощности графических процессоров. Канечно, скажет читатель, там ведь много универсальных процессоров, которые испольнаюд код шейдеров версии 4. А почему их так много?(В чипах Радеон их до 800, а может уже и больше). Да потому, что они простые и эффективные, а просты и эффективны ибо исполняют RISC-команды. А интел ваяет Лараби - видеопроц с х86 инструкциями. Читал я уже обзоры будущего чипа, там уже не чистый х86, а с модификациями. В общем будет очередное гэ. И вроде рисовать будет, да как-то не так быстро и греться будет хоть курицу жарь. И вроде код шейдеров прямо на центральном проце можно будет испольнять-отлаживать, да опять все-таки нельзя будет и спец компилятор нужон будет - ВЕДЬ В Лараби НЕ ЧИСТЫЙ х86.
А я душой и сердцем болею за SUN с ее SPARCом, я бы и заDEC Alpha болел, да умер Альфа. У спарк архитектуры есть шанс спастись, Сан открыла спецификации Ниагары1,загляните на Opensparc.net, и европейские университеты присоединяются к изкчению и развитию этой архитектуры. И скачать можно с сайта эти спецификации, и лицензия на производство процов по ним стоила 99 баксов. А то, что Сан делает сервера на х86 архитектуре, так это она больше заложник ситуации, ведь надо где-то деньги брать на развитие Solaris и Ниагары, потому на данный момент, я это ей прощаю. Я ведь и сам пишу это сообщение с ноута на базе Центрино. А сам мечтаю о комеп на базе УльтраСпарк, ну хота бы III, я уже не говорю про IV и IV+ и тем более про Ниагары - пишу и мечтаю.
Mapar, Ср 11 мар 2009 17:24:52:
Спасибо за статью. Мысли во общем-то не новые, но все упорядочено, это очень ценно.

О гармоничности аппаратуры только мечтать остается или ждать кто пойдет с другого конца создаст под тот же Unix свою архитектуру (хотя вряд ли).
Что касается многоядерности, тут есть свои за и против. Мне кажется на рынке серверов SMP прочно стоит на ногах, такие системы активно применяются и достаточно хорошо масштабируются. В основном там где можно породить отдельный процесс для каждого пользователя/сессии: сервера приложений, базы данных, файловые сервера, хост сервера для виртуальных машин. Это наверно большинство бизнес-задач на данный момент. Но как всегда остаются 20% на которые уходит 80% времени и тут грабли многопроцессорности бьют в лоб по полной. Хорошо если получается разделить работу на части и запустить несколько процессов (и получить кучу геморроя с синхронизацией). А если путь распараллеливания не очевиден? Кнут, по моему, говорил что в одном из своих интервью, что он за всю жизнь написал только 1-2 параллельную программу и были проблемы с отладкой. Так что проблема действительно есть, и закрывать глаза на нее нельзя. В этом отношении статья очень полезна. Ибо хороший специалист по любой системе не тот кто ее может похвалить, а тот кто может квалифицированно рассказать о ее недостатках.
Kuma-sama, Пн 02 мар 2009 11:51:08:
Очень порадовала статья. Ждём статью на тему "Мировой экономический кризис как следствие неправильной архитектуры современных компьютеров"!

Love, Kuma-sama.

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: следующая

Ваш комментарий

Имя:

Текст комментария (HTML-теги не допускаются):

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...