Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

06.06.2017

Google
WWW CITForum.ru
С Новым годом!
2008 г.

Пикоджоуль ватт бережет

Сергей Кузнецов

Обзор июльского, 2008 г. номера журнала Computer (IEEE Computer Society, V. 41, No 7, Июль 2008)

Авторская редакция.
Также обзор опубликован в журнале "Открытые системы"

Формально темой июльского номера журнала являются архитектуры и оптимизации процессоров. Однако в этот раз полноценная тематическая подборка статей отсутствует – теме номера соответствуют только три больших статьи, подобранные без участия специальных редакторов. Тем не менее, начну обзор именно с этих статей.

Вильям Долли, Джеймс Бэлфур, Дэвид Блэк-Шейфер, Джеймс Чен, Р. Картис Хартинг, Вишал Парих, Джонгсу Пак и Дэвид Шеффилд (William J. Dally, James Balfour, David Black-Shaffer, James Chen, R. Curtis Harting, Vishal Parikh, Jongsoo Park, David Sheffield, Stanford University) представили статью «Эффективная встроенная вычислительная обработка» («Efficient Embedded Computing»).

Для встроенных вычислительных приложений требуется как эффективность, так и гибкость. Основная часть вычислений сегодня производится не в настольных компьютерах, лаптопах или центрах данных, а во встроенных медиа-устройствах. Каждый год продается более миллиарда мобильных телефонов, и мобильный телефон, поддерживающий функцию 3G, выполняет каждую секунду большее число операций, чем типичный процессор настольного компьютера.

Медиа-устройства, такие как мобильные телефоны, видеокамеры и цифровые телевизоры, производят едва ли не больше вычислений, чем самые быстрые суперкомпьютеры, потребляя при этом энергию, на несколько порядков меньшую энергии, потребляемой настольными компьютерами и лаптопами общего назначения. Например, для обеспечения работы с каналом в 14.4 Mbps приемника мобильного 3G-телефона требуется выполнять от 35 до 40 гигаопераций в секунду (giga operations per second, GOPS). По оценкам исследователей, для поддержки работы со 100-мегабитным каналом, основанном на мультиплексировании с ортогональным частотным разделением сигналов (orthogonal frequency-division multiplexing, OFDM), требуется производительность от 210 до 290 GOPS.

При этом пиковая производительность типичной настольной системы составляет несколько GOPS, а для большинства приложений требуется гораздо меньшая производительность. Проблемы вычислительной обработки в мобильных телефонах еще более впечатляют, если вспомнить о том, что этот уровень производительности должен обеспечиваться портативным блоком с максимальным рассеянием мощности в пределах одного ватта. Простые вычисления показывают, что для обеспечения работы 3G-приемника требуется эффективность в 25 милливатт на гигаоперацию, или 25 пикоджоулей на операцию, а для OFDM-приемника – 3-5 пикоджоулей на операцию.

Жесткие требования к производительности и эффективности вынуждают использовать для вычислительной обработки в медиа-устройствах «зашитую логику» (hardwired logic) в форме специализированных интегральных схем (application specific integrated circuit, ASIC). Тщательно разработанная ASIC может обеспечивать эффективность в 5 пикоджоулей на операцию при использовании технологии комплементарных металло-оксидных полупроводников (complementary metal-oxide semiconductor, CMOS). В отличие от этого очень эффективные встраиваемые процессоры и цифровые сигнальные процессоры (digital signal processor, DSP) требуют в 50 раз больше энергии для выполнения каждой операции, а процессоры популярных лаптопов – в 4000 больше. Эффективность этих программируемых процессоров просто не отвечает требованиям встраиваемых приложений, и это вынуждает разработчиков использовать «зашитую логику» для соблюдения требований минимального потребления энергии.

Хотя использование ASIC позволяет удовлетворить требования встраиваемых приложений к эффективности потребления энергии, специализированные интегральные схемы не отличаются гибкостью, и их трудно разрабатывать. Разработка типичной ASIC занимает два года и обходится в 20 миллионов долларов. Эта высокая стоимость делает приемлемым использование ASIC только в наиболее массовых приложениях. Длительность разработки приводит к тому, что функциональные возможности готовых к использованию ASIC сильно отстают от имеющихся к этому времени результатов разработки алгоритмов, модемов и кодеков. Отсутствие гибкости приводит к увеличению плотности и сложности ASIC. Например, если система должна поддерживать несколько радиоинтерфейсов, то в реализации на основе ASIC для каждого интерфейса должен иметься отдельный «зашитый» модем, несмотря на то, в каждый конкретный момент времени будет использоваться только один из них. Если бы требованиям эффективности отвечал какой-либо программируемый процессор, то все интерфейсы можно было бы реализовать с использованием одного аппаратного ресурса путем выполнения на нем разных программ.

По мере того как медиа-приложения развиваются и усложняются, усугубляются и проблемы ASIC. Усложняющиеся приложения сложнее реализовывать в виде «зашитой логики», и они выставляют более динамичные требования – например, наличие нескольких режимов функционирования. Все быстрее совершенствуются алгоритмы, что делает проблематичным их «замораживание» в зашитых реализациях. Встраиваемым приложениям все больше требуется гибкость наряду с эффективностью.

Встроенный процессор тратит большую часть потребляемой энергии на выборку команд и данных. Поэтому первым полезным шагом при разработке эффективного встраиваемого процессора является анализ того, на что уходит потребляемая энергия в имеющихся процессорах. Оказывается, что типичный встраиваемый RISC-процессор расходует 70% энергии на выборку данных и 42% на выборку команд. На выполнение вычислений уходит только 6% энергии, из которых только 59% расходуется на полезные вычисления – остальное составляет накладные расходы: пересчет индексов циклов и вычисление адресов памяти. Энергия, потребляемая для полезных вычислений, соизмерима с энергией, расходуемых для этих же целей в «зашитой» реализации: в обоих случаях используются похожие арифметические устройства.

Высокие накладные расходы программируемых процессоров проистекают от неэффективного способа обеспечения данных и команд для их арифметических устройств: на каждую арифметическую операцию, на выполнение которой требуется 10 пикоджоулей энергии, процессор расходует 70 пикоджоулей на выборку команд и 47 пикоджоулей на чтение и запись данных. Накладные расходы оказываются даже более высокими, поскольку для каждой полезной команды приходится считывать и снабжать данными 1.7 команд.

Более тонкий анализ потребления энергии на выборку команд показывает, что больше всего энергии потребляется 8-килобайтным кэшем команд. Для считывания любой команды требуется доступ к обоим каналам двухканального секторно-ассоциативного кэша (two-way set-associative cache) и чтение двух тегов, для чего требуется 107 пикоджоулей энергии. Конвейерные регистры потребляют еще 12 пикоджоулей, передавая эти команды по пятифазовому RICS-конвейеру. Таким образом, получается, что для выполнения арифметической команды, для которого требуется 10 пикоджоулей энергии, 119 пикоджоулей расходуется на выборку каждой команды. Из-за наличия служебных команд, для выполнения каждой полезной команды в среднем приходится считывать 1.7 команд.

Анализ потребления энергии для обеспечения данных показывает, что 50% энергии потребляется кэшем. На работу 40-словного многопортового массива регистров общего назначения расходуется 41% энергии, и остальное тратится на конвейерные регистры. Для выборки слова из кэша требуется 131 пикоджоуль энергии, а на выборку слова из массива регистров тратится 17 пикоджоулей. При выполнении каждой арифметической команды, потребляющей 10 пикоджоулей энергии, потребляются два слова и производится одно слово данных.

Следовательно, энергия, требуемая для обеспечения данных и команд арифметическим устройствам традиционных встраиваемых RISC-процессоров, в 15-20 раз больше энергии, требуемой для выполнения самой команды. Из этого становится ясно, что для повышения эффективности программируемых процессоров нужно сосредоточиться на выборке данных и команд.

Потребление энергии для обеспечения команд можно снизить в 50 раз за счет использования более глубокой иерархии с явным управлением, устранения служебных команд и раскрытия конвейера. Поскольку наибольший расход энергии для обеспечения команд периодически происходит в кэше команд, для сокращения потребления энергии процессор должен обеспечивать команды без их поиска в энергоемком кэше. В описываемом в статье эффективном процессоре с низким потреблением энергии (low-power microprocessor, ELM) команды поставляются в арифметическое устройство не из кэша, а из небольшого набора регистров команд. Расход энергии на чтение одного бита команды из этого массива регистров команд (instruction register file, IRF) составляет 0.1 пикоджоуля против 3.4 пикоджоулей в случае использования кэша, т.е. в 34 раза меньше.

Во многих отношениях IRF – это всего лишь еще один небольшой уровень иерархии памяти команд, и можно задать вопрос, почему этот уровень не включался в архитектуру процессоров раньше? Исторически кэши использовались для повышения производительности, а не для снижения энергопотребления. Для достижения максимальной производительности нижний уровень иерархии доводится до предельно допустимого размера при сохранении возможности доступа за один цикл. Уменьшение размера кэша может привести только к снижению производительности за счет увеличения коэффициента «непопаданий» без воздействие на время доступа. По этой причине кэш команд первого уровня обычно имеет размер от 8 до 64 килобайт. Для оптимизации с целью понижения энергопотребления требуется минимизировать нижний уровень иерархии, обеспечивая при этом эффективное выполнение критических циклов медиа-приложений.

В ELM имеется IRF с 64 регистрами, который может быть разделен таким образом, что для поддержки небольших циклов требуется только циклически обращаться к разрядным шинам регистров. Процессор ELM управляет IRP, как массивом регистров, при поддержке компилятора, который распределяет регистры и выполняет пересылки. Это делается не так, как при использовании кэша, где распределение блоков кэша и пересылка команд производятся под прямым управлением аппаратуры. У явного управления ELM имеются два основных преимущества. Во-первых, это позволяет избежать простоев за счет упреждающего чтения блока команд в IRF, которое производится, как только процессору становится известен блок команд, который будет выполняться. В отличие от этого, кэш ожидает, пока не потребуется первая команда, а затем процессор простаивает, пока команда считывается из основной памяти. В некоторых кэшах имеются аппаратные устройства упреждающего чтения, но они тратят много энергии, часто считывают ненужные команды и редко обнаруживают условные переходы в последовательных участках команд. Кроме способствования повышению эффективности, явное управление IRF позволяет лучше справляться с ситуациями, когда рабочий набор команд не помещается на регистрах.

Притом что явное управление IRF позволяет сократить стоимость чтения каждого бита команды с 3.4 пикоджоулей до 0.1 пикоджоуля, теперь становится существенной энергия в 0.4 пикоджоуля, расходуемая на перемещение этого бита по конвейеру. В процессоре ELM эти конвейерные регистры команд устраняются благодаря раскрытию конвейера. При использовании традиционного скрытого конвейера процессор считывает команду, для выполнения которой требуется много тактов, а затем задерживает ее посредством последовательности конвейерных регистров, пока не потребуются все ее части. Система использует адреса чтения регистров в течении фазы конвейера чтения регистров, код операции в течении фазы конвейера исполнения и т.д. Это удобно, но требует много энергии.

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

IRF и раскрытый конвейер снижают стоимость выборки каждого бита команды. Устранение служебных команд позволяет сократить число бит инструкций, которые должны обеспечиваться системой. Большинство служебных команд нужно процессору для управления индексами циклов и вычисления адресов. В IRF система команд модифицирована таким образом, что наиболее распространенные функции этих служебных команд выполняются системой автоматически, в качестве побочного эффекта других команд. Например, команда загрузки слова из памяти увеличивает использованный адрес на некоторую константу и возвращается к исходному адресу при достижении предела. Это позволяет реализовать циклический буфер с использованием одной, а не пяти команд.

Включение в команды этих побочных эффектов означает частичный возврат к архитектуре со сложной системой команд (Complex Instruction Set Computer, CISC). Если основной проблемой является энергия, что такие конструкции в духе CISC вполне осмысленны, и они вводятся в архитектуру ELM таким образом, чтобы облегчить их использование оптимизирующим компилятором. Эксперименты показывают, что в архитектуре ELM выбирается на 63% меньше бит динамических команд, чем в архитектуре RICS.

Количество энергии, требуемой для обеспечения данных, можно сократить в 21 раз путем использования более глубокой иерархии памяти на основе применения индексируемых массивов регистров. В RICS-процессоре большая часть данных поступает из общего массива регистров с потреблением 17 пикоджоулей энергии на слово. Доступ к этому массиву регистров стоит так дорого из-за того, что он имеет размер в 40 слов и несколько портов чтения и записи. В архитектуре ELM энергия, требуемая для обеспечения данных, сокращается за счет размещения в каждом арифметико-логическом устройстве (arithmetic logic unit, ALU) небольшого четырехсловного массива регистров операндов (operand register file, ORF). Из-за небольшого размера и ограниченного числа портов на чтение слова из ORF тратится только 1.3 пикоджоуля энергии, т.е. в 13 раз меньше, чем в архитектуре RICS. Небольшой размер ORF также позволяет производить чтение из него в том же такте, в котором выполняется арифметическая операция без существенного удлинения времени такта. Это позволяет упростить раскрытие конвейера.

На следующем уровне иерархии используется индексируемый регистровый массив (indexed register file, XRF). Система может обращаться к XRF либо напрямую (в отдельном поле команды указывается требуемый регистр), либо косвенно (в поле команды указывается регистр, в котором специфицируется требуемый регистр). Возможность косвенного (индексного) доступа к регистровому массиву устраняет потребность во многих ссылках на кэш данных или основную память. Для многих медиа-приложений характерен доступ к небольшим массивам данных, которые помещаются в регистровом массиве, но к которым требуется косвенный доступ. В процессоре ELM эти массивы могут сохраняться в индексируемом регистровом массиве, что позволяет значительно сократить расход энергии на доступ к таким данным. Эксперименты показывают, что в архитектуре ELM из основной памяти считывается на 77% меньше слов, чем в архитектуре RICS.

Авторами статьи «Закон Амдала в эпоху многоядерных архитектур» («Amdahl’s Law in the Multicore Era») являются Марк Хилл и Майкл Марти (Mark D. Hill University of Wisconsin-Madison, Michael R. Marty, Google).

Наступление эпохи многоядерных архитектур является переломной точкой в истории компьютеров. Поставщики компьютеров объявляют о выпуске кристаллов с несколькими процессорными ядрами. Более того, в планах поставщиков обещается частое удвоение числа ядер в кристалле. Эти будущие кристаллы называют мультипроцессорами на кристалле или многоядерными кристаллами.

Разработчики многоядерных кристаллов стакиваются с большим числом степеней свободы, чем одноядерных случаях. Им требуется отвечать на ряд дополнительных вопросов. Сколько должно быть ядер? Следует ли использовать простые конвейеры или мощный множественный конвейер (multi-issue pipeline)? Должны ли все ядра иметь одну и ту же микроархитектуру? Кроме того, в то же время разработчики должны решать проблему управления питанием от динамических и статических источников.

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

Авторы полагают, что при разработке будущих многоядерных кристаллов нужно руководствоваться законом Амдала, который был сформулирован для случая распараллеливания программы на n процессорах следующим образом. Если имеется некоторая вычислительная задача, решаемая по такому алгоритму, что долю f от общего объема вычислений можно получить только за счет последовательной обработки, а долю 1-f можно распараллелить идеально, то ускорение, которое можно получить при использовании n процессоров, ограничено величиной 1/((1-f) + f/n).

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

Последнюю статью тематической подборки – «Warp-обработка: динамическая трансляция бинарного кода в схемы FPGA» («Warp Processing: Dynamic Translation of Binaries to FPGA Circuits») – написали Фрэнк Вахид, Грег Стигг и Роман Лисецки (Frank Vahid, University of California, Riverside, Greg Stitt, University of Florida, Roman Lysecky, University of Arizona).

Программное обеспечение состоит из бит, загружаемых в заранее изготовленное аппаратное устройство. Биты традиционного программного обеспечения микропроцессоров представляют собой последовательные команды, выполняемые программируемым микропроцессором. В отличие от этого, программное обеспечение программируемой вентильной матрицы (field-programmable gate array, FPGA) – это схема, отображаемая в реконфигурируемую логическую структуру FPGA. Оба вида программного обеспечения освобождают разработчиков от потребности конструировать аппаратуру. Вместо этого для реализации требуемых вычислений в заранее изготовленное аппаратное устройство просто загружаются биты.

Вычисления могут производиться быстрее, если им соответствует схема FPGA, чем если они задаются набором последовательных команд, потому что в первом случае допускается больше параллелизма, на уровне процессов, а не бит. Например, при реализации операции изменения порядка бит (bit reversal) в виде схемы для выполнения операции потребуется всего один такт, а при выполнении требуемых команд в микропроцессоре это займет десятки тактов. Арифметическое вычисление с 20 умножениями может быть выполнено на FPGA за два такта, если в FPGA имеется 10 устройств умножения, а на микропроцессоре для этого потребуется не менее 20 тактов. Для выполнения вычисления уровня процесса с десятью независимыми потоками 100-тактовых потоков потребуется только 100 тактов, если каждый поток реализуется в виде отдельной схемы, в том время как при выполнении на одном микропроцессоре это займет не менее 1000 тактов.

Нескольких коммерческих и исследовательских инструментальных средств направлено на компиляцию популярных языков программирования для микропроцессоров (C, C++, Java) в схемы FPGA. Во многих таких компиляторах используется профилирование для обнаружения программных ядер – небольших участков программ, которые больше всего используются при выполнении программы (следуя известному правилу 90/10), – и эти ядра отображаются на схемы FPGA, в то время как оставшаяся часть программы выполняется в микропроцессоре.

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

Warp-обработка направлена на устранение этих барьеров за счет того, что FPGA становятся невидимыми для разработчиков программного обеспечения. В этом случае вычислительная платформа выполняет компиляцию в схемы FPGA прямо при выполнении двоичного кода программ на микропроцессоре, т.е. динамически.

Архитектура Warp-компьютера включает микропроцессор, FPGA, разделяемые кэши команд и данных, профилировщик и динамические средства САПР. Разработчик загружает программу в память микропроцессора в виде стандартного исполняемого двоичного кода. Профилировщик динамически обнаруживает ядра в двоичном коде, динамические САПР-средства автоматически отображают эти ядра в схемы FPGA, и корректор двоичного кода динамически модифицирует программу для использования новых схем. После этого выполнение программы внезапно ускоряется в 2 раза, в 10 раз и даже больше. Другими словами, происходит «разрыв» времени исполнения программы («time warp»). (Это значение слова warp происходит из научной фантастики, где «space warp» означает «прокол искривлённого пространства», или «нуль-транспортировку». Поэтому не очень понятно, какой русский эквивалент могут иметь введенные Фрэнком Вахидом термины warp-processing и warp-computer.)

Вне тематической подборки в июльском номере журнала опубликованы еще три большие статьи. Авторами статьи «Автоматизация устранения дефектов в кремниевых кристаллах на уровне пластины» («Automating Postsilicon Debugging and Repair») Кай Чанг, Игорь Марков и Валерия Бертокко являются (Kai-hui Chang, Avery Design Systems, Igor L. Markov, Valeria Bertacco, University of Michigan, Ann Arbor).

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

Притом что для многих современных продуктов время жизни на рынке составляет только несколько лет, задержка, вызываемая двумя повторными изготовлениями кристалла, может существенно сократить доход или даже погубить продукт. По опубликованным оценкам расходы на устранение дефектов в кремниевом кристалле на уровне пластины могут составлять от 15 до 20 миллионов долларов, и этот этап может длиться до шести месяцев, хотя для решения этой проблемы разработано несколько автоматизированных средств и алгоритмов.

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

Существующие методы устранения дефектов в кремниевых кристаллах на уровне пластины направлены на обеспечение большей видимости и контролируемости кремниевых кристаллов. Хотя такие методы хорошо помогают инженерам, они не автоматизируют сам процесс разработки. Для решения этой проблемы авторы статьи разработали методологию, которая способствует автоматизации устранения дефектов в кремниевых кристаллах на уровне пластины. Ключевыми особенностями предлагаемого подхода является поддержка физических ограничений кремниевых кристаллов на уровне пластины и возможность устранения дефектов путем тонких модификаций существующей топологии.

Статью « SIISAM: модель для безопасных неоднородных информационных систем» («SIISAM: A Model for Secure Inhomogeneous Information Systems») написали Кун Ванг, Жонгжай Йин, Лихуа Жоу, Фенг Юань и Зенксин Ли (Kun Wang, Zhonghai Yin, Lihua Zhou, Xidian University, Feng Yuan, Zengxin Li, National Information Security Engineering and Technology Research Center, Beijing, China).

Большие и сложные информационные системы, используемые, например, в электронном правительстве, в банках и вооруженных силах, содержат много несовместимых приложений, созданных в разное время и для разных целей. Для координации проектирования, разработки, использования и сопровождения этих неоднородных информационных систем (inhomogeneous information system, IIS) требуется гибкая и расширяемая архитектура, которая смогла бы обеспечить бесшовную интероперабельность унаследованных приложений и безопасность при использовании новых компонентов.

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

Для решения этой проблемы, исследователи, участвующие в проекте EEDP (E-Government Experimental and Demonstration Project), разработали модель архитектуры безопасных неоднородных информационных систем (secure inhomogeneous information system architecture model, SIISAM). Основные черты SIISAM:

  • это практическая, а не теоретическая модель, предназначенная для регулирования процесса построения реальной IIS;
  • обеспечиваются важные службы поддержки безопасности – шифрование, аутентификация, авторизация, обнаружение вторжений, аудит и антивирусная защита, а также восстановление после отказов для обеспечения непрерывной работы;
  • для поддержки интероперабельности и расширяемости используется технология Web-сервисов;
  • модель является многоуровневой, а не ориентированной на процессы, что облегчает проектирование, разработку и внедрение системы.

Описываемая модель будет положена в основу будущей системе электронного правительства КНР.

Автор последней большой статьи номера – Рональд Лоуи (Ronald P. Loui, Washington University in St. Louis). Статья называется «Хвала сценариям: настоящая практичность программирования» («In Praise of Scripting: Real Programming Pragmatism»).

Сегодня подтверждается справедливость смелого предвидения, содержащегося в статье создателя языка Tcl Джона Оустерхоута «Сценарии: программирование высокого уровня 21-го века» (John K. Ousterhout, «Scripting: Higher Level Programming for the 21st Century»), опубликованной в журнале Computer в 1998 г. Забавно, что в 2005 г. журнал IEEE Software напечатал статью «Java делает скриптовые языки неуместными» (Diomidis Spinellis, «Java Makes Scripting Languages Irrelevant?»), содержащую стандартные нападки на языки сценариев. Эта статья интересна тем, что автор, как кажется, сам не соглашается с ее названием. В заключении статьи больше текста посвящено восхвалению скриптовых языков, чем рассуждениям о развитии языка Java в направлении простоты и удобства использования. Еще не ясно, что является лучшей рекомендацией для скриптовых языков: долговечность текста Оустерхоута или нерешительность этой критики.

Больше всего потрясает то, что академическое сообщество языков программирования продолжает отрицать наличие изменений в практике программирования, привнесенных скриптовыми языками. Академические ученые, очарованные объектно-ориентированной парадигмой, не готовые к принятию концепции LAMP (Linux-Apache-MySql-Perl/Python/Php) и твердо полагающие, что для улучшения практики программирования требуется как можно больше теории программирования, остаются глухими к доводам Оустерхоута.

Частично это объясняется тем, что скриптовые языки развивались в тени объектно-ориентированных языков. Эти два направления не являются несовместимыми, но наибольшее внимание привлекает объектная ориентированность. Кроме того, направление скриптового программирования формировалось от одного языка к другому. Те люди, которые выступали в поддержку философии сценарного программирования, больше всего хвалили свой любимый язык, включая Оустерхоута, который в большей части своей статьи восхваляет Tcl. Сегодня имеется много вопросов по поводу скриптового программирования. Пригодны ли скриптовые языки для обучения программированию на первых курсах университетов? Есть ли место для сценарного программирования и корпоративных приложениях или приложениях реального времени? Поддаются ли проекты, выполненные с использованием скриптового подхода, существенному масштабированию?

Автор доказывает, что на все эти вопросы теперь можно отвечать положительно.

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




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

    Информация для рекламодателей Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 This Web server launched on February 24, 1997
    Copyright © 1997-2017 CIT, © 2001-2017 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...