Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer. |
Бабушка-бабушка! А почему у тебя такой большой процессор? Сам придумал |
Когда-то давно-давно, примерно в годы, следующие за появлением мобильных компьютеров... нет, уважаемый - не носимых, а мобильных - пара грузовиков всей-то радости... в одном - машина на самых современных радиолампах, в другом - дизель-генератор...
Так вот, когда-то давным-давно навязшая уже в устах IBM придумала один из устоев современного компьютерного мира. Причем не из научных соображений, не со скуки - по причинам чисто коммерческим.
Случилось так, что клиенты придумали возмущаться сущей мелочью - простоем центрального процессора во время распечатки результатов. Ведь оно как получается? Пару минут машина читает программу и исходные данные с перфокарт, потом полчаса считает, а потом еще полчаса печатает - а процессор-то эти полчаса почти незадействован! Бардак. Он стоит бешеных денег - подать сюда стопроцентную нагрузку.
Требование было неприятным, но решений нашлось аж два. Первое было неудобно и не решало проблему на корню, но зато было легко реализуемо. Данные после обсчета быстренько скидывали на магнитную ленту, а с нее печатали в сторонке, сколько душа пожелает.
Второе называлось "многозадачная операционная система". Идея звучала так: Пусть задач будет настолько много, чтобы центральный процессор всегда был загружен их работой. А когда очередная из них закончит считать и начнет распечатывать, оставшийся избыток процессорного времени будет передан другим задачам.
Решение было вполне удовлетврительным до тех пор, пока компьютеры использовались в пакетном режиме - заказчики несли задачи, а оператор их "прогонял" на компьютере, следя одновременно за порядком. Вопросов приоритета почти не стояло, а если и была задача приоритетная, то уж приоритетная совсем. То есть - одна поперед всех, а остальным поцессорного времени - сколько останется.
Вся эта незамысловатая идиллия была разрушена появлением человека. Человека с терминалом. Человек пришел, воткнул в машину терминал и заявил - "буду работать интерактивно". И тут выяснилось, что, во-первых приоритеты задач в отношении процессора бывают отличные от нуля и ста процентов, а во-вторых - могут изменяться во времени.
Что такое приоритет? Это атрибут задачи, который влияет на решение одного простого вопроса: Готовых к работе задач - 33, а процессор - один. Кому он достанется на следующие n миллисекунд? А кому потом?
Понятно, что задачи с высоким приоритетом должны получать процессор как-то чаще, чем задачи с низким. Поэтому самое простое решение родилось быстро. Было оно вот каким. Давайте выберем группу задач с максимальным приоритетом, и будем гонять только их, по очереди. А когда все они кончатся или по какой-либо причине приостановятся, то выберем из оставшихся самые приоритетные - и опять, запустим только их.
Такая схема называется схемой с жесткими приоритетами, или приоритетами реального времени. Дело в том, что она вполне применима в системах, требующих предсказуемого времени ответа - при управлении производством, например. Задаче, которая управляет быстротекущими процессами назначают высокий приоритет - как только у нее возникает потребность поуправлять - она сразу же получает в свое полное распоряжение процессор. Когда же она спит, порцессор достается задачам, занимающимся делами не столь неотложными.
Опять же, в случае с многопользовательскими машинами жесткие приоритеты были неудобны. Не может же один пользователь ждать, пока другой наработается и пойдет обедать?
Поэтому была разработана другая схема - с мягкими приоритетами. Процесс, имеющий бОльший приоритет получает процессор просто чаще, чем другие, но все, даже самые низкоприоритетные процессы, хоть капельку, да получат.
Это было уже лучше. Это позволяло вести бизнес гибко, нагружая машину высокоприоритетными и высокооплачиваемыми пользователями, и "добивать" загрузку машины теми, кто не мог платить полную цену, но соглашался на не самую быструю работу своих задач. Тем более, что когда приоритетные пользователи вдруг делали паузу в работе, вся освободившаяся мощь процессора обрушивалась на остальных, причем совершенно бесплатно.
Впрочем, и тут крылся минус. Но о нем - в другой раз.
Набрел тут на компьютерную коммисионку онлайн. В былые времена это дело активно процветало, пожалуй, только в ФИДО, а вот - и в Интернете народу стало достаточно. Похоже, живет комок - выбор барахла приличный.
Где только Питерские ФИДОшники не пьют пива... лично проверил - почти везде пьют. :-) На выставках и в парках, в компаниях, занимающихся айпи-провайдингом, и в компаниях, им не занимающихся. У растральных колонн и близ Спаса... даже в арке главного штаба.
Осмотреть все наиболее пригодные для пития пива места в Питере можно зайдя на страничку питерского ФИДОшника Петра Соболева, не пожалевшего кучи батареек и сил своих на создание очень неплохой коллекции изображений Питера.
Если серьезно, Санкт-Петербург - место для фотографа благодатное. Сконцентрировано в нем на довольно небольшой площади столько всего красивого, что пройти и не щелкнуть - думаю, невозможно. Я бы не смог, факт. Вот и Соболев, видать, тоже не удержал затвора :-). Фоток наделал - уйму. Увы, не все идеальны, но как минимум хороших - подавляющее большинство.
Заговорив о Соболеве нельзя не сказать об Enlight-е.
Встречаются в этой жизни непрактичные люди. Люди, которые делают не то, что можно выгодно продать, а то, к чему душа лежит. Их еще художниками называют, или поэтами... архитекторами, музыкантами, танцорами... только программистами их не называют. Потому что талантливых непрактичных программеров издревле прозвали хакерами. Вложив в это слово всю силу цивильного презрения к уникальному. К тому, что живет красотой, а не деньгами.
А красота в компьютерном мире - двояка. Одна ее сторона - традиционна. Это хорошая графика, музыка, стильный шрифт... другая - доступна избранным из избранных. Тем, кто не просто умеет программировать. Тем, кто не просто умеет программировать на ассемблере. Тем, кто знает про машину больше, порой, чем ее создатели. Хакерам.
Сочетание красоты традиционной и красоты программистской называется "демо". Демка, демонстрашка - маленькая программа, сочетающая в себе, как правило, звуковую и графическую части. В функцию демки входи показать что-нибудь красивое под соответствующую музыку. Хорошее представление о них дают вводные кадры многих игр, за тем исключением, что оные кадры частенько отрисовываются заранее и прокручиваются из avi-шника, а любая приличная демка обязана синтезировать все изображение и звук на ходу и быть маленькой в объеме. То есть никак не десятки мегабайт.
Ну так вот - Enlight являет собой ежегодный фестиваль, на котором демомейкеры, авторы оных демок, хвалятся друг перед другом своим искусством. Програмистским, художественным, музыкальным... а организует эти самые фестивали - Соболев.
Кстати, любопытный факт. Будучи приглашен на один из таких фестивалей я вернулся домой в подареной мне майке, на спине которой в шестнадцатеричном виде записан код одной из самых маленьких демок на свете - 126 байт! Запихать на спину целую программу - почище, чем подковать блоху, нет? :-)
К сожалению, не всем удалось скачать ту демку, на которую стоит ссылка чуть выше - глупый нетскейп пытается ее выполнить и жалуется на CGI error. Поэтому вот она же, но в zip-е.
LCD-мониторы все дешевеют и дешевеют. Akia вот слепила парочку довольно сносных, и по терпимой для такой крутости цене - 1500 за 14.5-дюймовый 1024x768. Конечно, это еще не конкурент электронно-лучевым трубкам, но если кому приспичило озаботиться здоровым образом жизни - уже можно себе позволить, коль поднапрячься.
Радует, впочем, не столько факт, сколько тенденция. Летом я оценивал свои шансы купить LCD как нулевые - отдать $2800 я за это хрен с два соглашусь. А сейчас - уже ближе к делу. Все равно ужасно дорого, но ближе. И будет еще ближе.
Причина дороговизны LCD мониторов тривиальна. Высокий поцент брака.Технология не столь отточена, и слишком часто несколько ячеечек из миллионов отказываются работать. Точнее - почти всегда. Большинство производителей указывают в паспорте, что две-три точки на экране могут не работать и это не дает права на возврат товара. Даже у моего двухдюймового LCD на фотоаппарате это допускается фиромой изготовителем. Правда, на практике я их не нашел. Может, мелкие очень... не знаю.
Знаю, что по части вьедливости и скрупулезности в изготовлении всякой высокотехнологичной утвари японцы - народ непревзойденный. Им дай идею - они доведут до совершенства.
Отсюда вывод - в 2000-ном следует ожидать резкого падения спроса на старые электронно-лучевые мониторы.
Кстати, о проценте брака. В СССР с этим обходились, порой, довольно по-свойски. Скажем, выпускает завод микросхемы памяти. Скажем, объемом аж по 4 килобайта на таракана. Потом проверяет их. Те, которые полностью работают идут как 4х-килобайтные. Те, у которых сбой только в первой или только во второй половине емкости - идут как 2х-килобайтные. Остальные - в брак.
Может и с мониторами бы так? Если в верхней половине лысинка - отпилить нижнюю и продать, как монитор половинного размера. :-) А еще ведь можно отпиливать слева, справа, сверху... :-)
Редакция отказывается ставить свою подпись под данным номером, считая, что он содержит ошибку, которую нельзя терпеть. Сомневаясь в этом, я обращаюсь к читателям с просьбой - прислать мне список найденных в номере ошибок.
Генеральным
спонсором журнала dz online является
компания "Эксимер".
Спонсор не отвечает за содержание
публикуемых материалов.
Пишите нам! Редакции интересно знать мнение своих читателей. Если Вы не против опубликования Вашего письма, то, пожалуйста, указывайте это в самом письме.
Copyright c dz online, 1996-1998 Designed by Denis A. Kim |