Файл: 1. Понятие системного и служебного программного обеспечения 3 Системное программное обеспечение 3.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 09.01.2024
Просмотров: 37
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
ввести в систему еще один интерфейс пользователя, к какой группе и в каких соглашениях отнести новый программный код, где искать проблемы во время отладки и, как, вообще, модернизировать существующую систему. Однако, некоторые направления развития современного программного обеспечения заставляют задуматься о его дальнейшем будущем и наводят на мысли о том, что это, уже недалекое будущее, может оказаться совсем не таким, как представляется сейчас. [1]
Когда параллельность обслуживания запросов или выполнения процессов помогает работе, а когда она может сильно помешать?
Параллельное выполнение процессов на деле означает равноправие любого из них и значительно ухудшает характеристики быстродействия системы. При параллельном обслуживании запросов система ставит все задания на исполнение, и периодически останавливает обслуживание какого-либо процесса, с сохранением его контекста, передает управление другому процессу с восстановлением его контекста исполнения. Цикл повторяется внутри очереди заданий до полного выполнения каждого из них. В итоге каждое задание тратит определенное время на выполнение, но, возможно, еще большее количество времени уходит на ожидание в очереди на исполнение.
При последовательном выполнении задач система ставит запросы в ожидание исполнения. После чего монопольно выполняет первый попавшийся, затем берет следующий – и все повторяется до полного обслуживания всего списка запросов.
Однако, смена однопроцессорных или многопроцессорных систем на системы, имеющие большое количество ядер или процессоров, т.е., физически параллельно выполняющих операции аппаратных модулей многое меняет. Но приобретение подобной мощной техники отнюдь не гарантирует реального повышения производительности компьютерных систем, так как далеко не все современные программные средства умеют использовать такое количество ядер или процессоров.
Поэтому, в качестве одного из направлений развития софтвера, возможна разработка стратегий выполнения алгоритмов и обработки данных, ориентированных на физическое распараллеливание. [2]
Раньше наиболее ценным, но весьма ограниченным, ресурсом была оперативная память. Все алгоритмы и структуры разрабатывавшихся программ были в значительной степени нацелены на минимизацию ее использования. Сейчас стандартная, коммерчески доступная компьютерная система, имеет в своем распоряжении оперативную память в несколько гигабайт, что превосходит весь объем жестких дисков, применявшихся ранее. Поэтому следующим направлением перспектив представляется разработка алгоритмов и структур данных,
занимающих большие объемы, размещаемые в оперативной памяти. В недалеком прошлом эти методы эксплуатировались, в частности, в таблицах типа SUPERCALK, WORKS, для предварительного вычисления текущих значений и в табличных вычислениях. Представляется неплохим и перспективным и улучшение различных е алгоритмов и процедур обработки данных, применяющих для сокращения объемов вычислений большие объемы ОЗУ. Например, вычислений различного рода таблиц, и кроме того, что будет разработано в этой области для решения задач преобразований, например, кодирования и декодирования данных: СУБД, видео, звук, графика, задачи поиска и т.д.
Время доступа к жестким дискам, повсеместно применявшимся ранее и применяющимся сейчас в качестве основных накопителей, гораздо больше времени доступа к оперативной памяти. Как уже было сказано, ранее использовавшиеся стратегии и алгоритмы в разработке баз данных были направлены на нивелирование этого фактора. Например, методы блочной организации файлов данных в СУБД, а также кэширования оперативной памяти компьютера. На сегодняшний день мы видим настоящий бум для твердотельных накопители SSD, которые отличаются тем, что имеют чрезвычайно большую скорость доступа к данным, и соотношение времени доступа оперативной памяти и к дискам существенно изменилось. Логически отсюда следует, что направление ближайших исследований в области организации СУБД будет меняться, и ведущие разработчики баз данных, возможно поменяют сам основополагающий принцип, на котором работают большинство существующих разработок и заменят структуру индексация с B*-дерева, например, на более многообещающий RB-дерево, или даже будут разработаны новые механизмы, на сегодняшний день неизвестные. [3]
Вообще-то не секрет, что указанная проблема достаточно серьезна. На сегодняшний день абсолютно переносимых языков программирования не существует. Да, мы привыкли считать, что наиболее переносимый язык программирования - это язык СИ и его клоны. Однако несовместимость компиляторов имеет место быть. На текущий момент сделано много попыток разработать портируемый компилятор. Но факт остается фактом: язык СИ стандартизирован, и достаточно давно, но 90% программного обеспечения, компилируемого, например в Linux, не сможет быть скомпилирован, скажем в Windows XP без изменения исходного кода. И, думается, усилия ведущих разработчиков, компиляторов будут направлены и на решение этой проблемы. Как следствие этого, к перспективам рынка программного обеспечения относится возможность портирования софта. Тут можно использовать различные подходы – использовать средства виртуализации, интерпретирующие системы, кросскопиляцию и т.д. [3]
Процессоры компьютерных систем, применявшиеся ранее в качестве ядра, почти не имели внутренних кэшей. К ним программисты относились, можно с уверенностью утверждать, просто никак. Средства встроенных или дополнительных кэшей процессоров могли быть хоть как-то использованы только при выборе аппаратной части компьютера. На все остальное, т.е.: работу программистов, планирование алгоритмов и структур данных - это совершенно не влияло. На сегодняшний день ситуация кардинально изменилась. Размеры кэшей стали настолько велики, что не учитывать их при разработке СУБД стало попросту невозможно. Существенно возросла сложность структуры кэшэй. И теперь невозможно себе представить СУБД, где бы с максимальной эффективностью не использовались алгоритмы и структуры кэширования данных. Использование кэща становится правилом хорошего тона и является показателем степени качества работы программиста.
Удивительно, но уже есть примеры того, как простая перестановка местами полей в базе данных, неожиданно дает выигрыш в производительности сразу на несколько десятков процентов. [4]
1. Викикак – совместное решение вопросов [Электронный ресурс]: Тенденции развития программного обеспечения – Режим доступа: http://life-prog.ru/
2. Автоматическое распараллеливание программ для распределенных систем. Статическое построение расширенного графа управления REFSRU [Электронный ресурс]: Режим доступа: http://www.refsru.com/
3. Программное обеспечение компьютера TURBO PASCAL [Электронный ресурс]: Режим доступа: http://www.borlpasc.narod.ru/docym/shay/teor/chapter6/1_6.htm
4. YourLib.net Твоя библиотека [Электронный ресурс]: Тенденции развития программного обеспечения – Режим доступа: http://yourlib.net/content/view/12775/151/
Когда параллельность обслуживания запросов или выполнения процессов помогает работе, а когда она может сильно помешать?
Параллельное выполнение процессов на деле означает равноправие любого из них и значительно ухудшает характеристики быстродействия системы. При параллельном обслуживании запросов система ставит все задания на исполнение, и периодически останавливает обслуживание какого-либо процесса, с сохранением его контекста, передает управление другому процессу с восстановлением его контекста исполнения. Цикл повторяется внутри очереди заданий до полного выполнения каждого из них. В итоге каждое задание тратит определенное время на выполнение, но, возможно, еще большее количество времени уходит на ожидание в очереди на исполнение.
При последовательном выполнении задач система ставит запросы в ожидание исполнения. После чего монопольно выполняет первый попавшийся, затем берет следующий – и все повторяется до полного обслуживания всего списка запросов.
Однако, смена однопроцессорных или многопроцессорных систем на системы, имеющие большое количество ядер или процессоров, т.е., физически параллельно выполняющих операции аппаратных модулей многое меняет. Но приобретение подобной мощной техники отнюдь не гарантирует реального повышения производительности компьютерных систем, так как далеко не все современные программные средства умеют использовать такое количество ядер или процессоров.
Поэтому, в качестве одного из направлений развития софтвера, возможна разработка стратегий выполнения алгоритмов и обработки данных, ориентированных на физическое распараллеливание. [2]
Раньше наиболее ценным, но весьма ограниченным, ресурсом была оперативная память. Все алгоритмы и структуры разрабатывавшихся программ были в значительной степени нацелены на минимизацию ее использования. Сейчас стандартная, коммерчески доступная компьютерная система, имеет в своем распоряжении оперативную память в несколько гигабайт, что превосходит весь объем жестких дисков, применявшихся ранее. Поэтому следующим направлением перспектив представляется разработка алгоритмов и структур данных,
занимающих большие объемы, размещаемые в оперативной памяти. В недалеком прошлом эти методы эксплуатировались, в частности, в таблицах типа SUPERCALK, WORKS, для предварительного вычисления текущих значений и в табличных вычислениях. Представляется неплохим и перспективным и улучшение различных е алгоритмов и процедур обработки данных, применяющих для сокращения объемов вычислений большие объемы ОЗУ. Например, вычислений различного рода таблиц, и кроме того, что будет разработано в этой области для решения задач преобразований, например, кодирования и декодирования данных: СУБД, видео, звук, графика, задачи поиска и т.д.
Время доступа к жестким дискам, повсеместно применявшимся ранее и применяющимся сейчас в качестве основных накопителей, гораздо больше времени доступа к оперативной памяти. Как уже было сказано, ранее использовавшиеся стратегии и алгоритмы в разработке баз данных были направлены на нивелирование этого фактора. Например, методы блочной организации файлов данных в СУБД, а также кэширования оперативной памяти компьютера. На сегодняшний день мы видим настоящий бум для твердотельных накопители SSD, которые отличаются тем, что имеют чрезвычайно большую скорость доступа к данным, и соотношение времени доступа оперативной памяти и к дискам существенно изменилось. Логически отсюда следует, что направление ближайших исследований в области организации СУБД будет меняться, и ведущие разработчики баз данных, возможно поменяют сам основополагающий принцип, на котором работают большинство существующих разработок и заменят структуру индексация с B*-дерева, например, на более многообещающий RB-дерево, или даже будут разработаны новые механизмы, на сегодняшний день неизвестные. [3]
Вообще-то не секрет, что указанная проблема достаточно серьезна. На сегодняшний день абсолютно переносимых языков программирования не существует. Да, мы привыкли считать, что наиболее переносимый язык программирования - это язык СИ и его клоны. Однако несовместимость компиляторов имеет место быть. На текущий момент сделано много попыток разработать портируемый компилятор. Но факт остается фактом: язык СИ стандартизирован, и достаточно давно, но 90% программного обеспечения, компилируемого, например в Linux, не сможет быть скомпилирован, скажем в Windows XP без изменения исходного кода. И, думается, усилия ведущих разработчиков, компиляторов будут направлены и на решение этой проблемы. Как следствие этого, к перспективам рынка программного обеспечения относится возможность портирования софта. Тут можно использовать различные подходы – использовать средства виртуализации, интерпретирующие системы, кросскопиляцию и т.д. [3]
Процессоры компьютерных систем, применявшиеся ранее в качестве ядра, почти не имели внутренних кэшей. К ним программисты относились, можно с уверенностью утверждать, просто никак. Средства встроенных или дополнительных кэшей процессоров могли быть хоть как-то использованы только при выборе аппаратной части компьютера. На все остальное, т.е.: работу программистов, планирование алгоритмов и структур данных - это совершенно не влияло. На сегодняшний день ситуация кардинально изменилась. Размеры кэшей стали настолько велики, что не учитывать их при разработке СУБД стало попросту невозможно. Существенно возросла сложность структуры кэшэй. И теперь невозможно себе представить СУБД, где бы с максимальной эффективностью не использовались алгоритмы и структуры кэширования данных. Использование кэща становится правилом хорошего тона и является показателем степени качества работы программиста.
Удивительно, но уже есть примеры того, как простая перестановка местами полей в базе данных, неожиданно дает выигрыш в производительности сразу на несколько десятков процентов. [4]
Список литературы
1. Викикак – совместное решение вопросов [Электронный ресурс]: Тенденции развития программного обеспечения – Режим доступа: http://life-prog.ru/
2. Автоматическое распараллеливание программ для распределенных систем. Статическое построение расширенного графа управления REFSRU [Электронный ресурс]: Режим доступа: http://www.refsru.com/
3. Программное обеспечение компьютера TURBO PASCAL [Электронный ресурс]: Режим доступа: http://www.borlpasc.narod.ru/docym/shay/teor/chapter6/1_6.htm
4. YourLib.net Твоя библиотека [Электронный ресурс]: Тенденции развития программного обеспечения – Режим доступа: http://yourlib.net/content/view/12775/151/