Выбор основного языка программирования и графической библиотеки для реализации программ компьютерной графики – часть 1

В настоящее время существует огромное многообразие языков программирования. Обзор и подробное рассмотрение их всех заняло бы большое количество времени и не принесло бы никакого результата. Поэтому будут рассмотрены две самые популярные концепции в программировании вообще и в программировании трехмерных приложений в частности – так называемые управляемые (managed) и неуправляемые (unmanaged) языки программирования. Что значит «управляемый»? Под данным термином подразумевается, что существует некая промежуточная ступень между кодом, который непосредственно пишет программист, и командами ассемблера, выполняемыми процессором. Эта ступень осуществляет автоматический контроль над такими аспектами выполнения программы, как, например, сборка мусора, то есть освобождение памяти от объектов, которые больше не требуются для дальнейшего выполнения программы. Одним из самых популярных представителей managed-языков программирования является платформа .NET Framework, созданная и развиваемая Microsoft, а также ее «флагманский» язык программирования C#. Его мы изберем в качестве представителя концепции managed-языков. В качестве представителя семейства unmanaged-языков избран unmanaged C++ (уточнение «unmanaged» требуется, поскольку в настоящее время той же самой Microsoft разрабатывается и продвигается managed C++ в рамках платформы .NET). Итак, для реализации алгоритмов воссоздания модели и модуля управления средой отображения модели будет использован один из этих двух языков. Рассмотрим два данных языка.

О платформе .NET Framework

Платформа .NET Framework определяет среду для разработки и выполнения распределенных приложений, основанных на использовании компонентных объектов. Она позволяет сосуществовать различным языкам программирования и обеспечивает безопасность, переносимость программ и общую модель программирования для операционной системы Windows. Важно при этом понимать, что .NET Framework по своему существу не ограничена применением в Windows, то есть программы, написанные для нее, можно затем переносить в среды, отличные от Windows. Связь среды .NET Framework с С# обусловлена наличием двух очень важных средств. Одно из них, Common Language Runtime (CLR), представляет собой систему, которая управляет выполнением пользовательских программ. CLR – это составная часть .NET Framework, которая делает программы переносимыми, поддерживает многоязыковое программирование и обеспечивает безопасность.

Второе средство, библиотека классов .NET-оболочки, предоставляет программам доступ к среде выполнения. Например, если необходимо выполнить некоторую операцию ввода-вывода (отобразить что-либо на экране), то для этого необходимо использовать .NET-библиотеку классов. Если программа ограничивается использованием средств, определенных .NET-библиотекой классов, она может выполняться в любой среде, где поддерживается .NET. Поскольку С# автоматически использует .NET-библиотеку классов, программы, написанные на С#, автоматически переносимы во все .NET-среды.

Функционирование системы CLR

Система CLR управляет выполнением .NET-кода. Вот как это происходит. В результате компиляции программы на одном из языков высокого уровня платформы .NET (например, на C#) получается не исполняемый код, а файл, который содержит специальный псевдокод, именуемый промежуточным языком Microsoft (Microsoft Intermediate Language – MSIL). MSIL определяет набор переносимых инструкций, которые не зависят от типа процессора. По сути, MSIL определяет переносимость ассемблера. И хотя концептуально MSIL подобен байт-коду Java, это не одно и то же. Важно отметить, что все языки, поддерживаемые платформой .NET, компилируются в одинаковый MSIL-код независимо от своего синтаксиса. Таким образом, с помощью дополнительного уровня абстракции, предоставляемого CLR, обеспечивается унификация всех поддерживаемых высокоуровневых языков программирования вне зависимости от их особенностей.

Цель CLR-системы – при выполнении программы перевести ее промежуточный код в исполняемый. Таким образом, программа, подвергнутая MSIL-компиляции, может быть выполнена в любой среде, для которой реализована CLR-система. В этом частично и состоит способность среды .NET Framework добиваться переносимости программ.

Код, написанный на промежуточном языке Microsoft, переводится в исполняемый с помощью JIТ-компилятора. «JIT» – сокращение от выражения «just-in-time», означающего выполнение точно к нужному моменту (так обозначается стратегия принятия решений в самый последний подходящий для этого момент в целях обеспечения их максимальной точности и минимальных несвоевременных затрат производительности). Упомянутый процесс выполняется следующим образом. При выполнении .NET-программы CLR-система активизирует JIT-компилятор, который преобразует MSIL-код в код, который непосредственно может быть выполнен данной системой. Таким образом, промежуточная программа в действительности выполняется в виде «родного» кода, несмотря на то, что первоначально она была скомпилирована в MSIL-код. Это значит, что программа будет выполнена практически так же быстро, как если бы она с самого начала была скомпилирована с получением «родного» кода, но при этом имеют место все вышеупомянутые преимущества переносимости от преобразования в MSIL-код. В результате компиляции сопрограммы помимо MSIL-кода образуются и мета-данные (metadata). Они описывают данные, используемые программой, и позволяют данному коду взаимодействовать с другим кодом. Метаданные содержатся в том же файле, где хранится MSIL-код.

Сравнение управляемого кода с неуправляемым

В общем случае при написании программы на одном из языков высокого уровня платформы .NET создается код, называемый управляемым (managed code). Управляемый код выполняется под управлением CLR-системы. У такого выполнения в результате есть как определенные ограничения, таки немалые достоинства. К числу ограничений относится необходимость иметь, во-первых, специальный компилятор, который должен создавать MSIL-файл, предназначенный для работы под управлением CLR-системы, и, во-вторых, этот компилятор должен использовать библиотеки среды .NET Framework. Достоинства же управляемого кода – современные методы управления памятью, возможность использовать различные языки, улучшенная безопасность, поддержка управления версиями и четкая организация взаимодействия программных компонентов.

Все Windows-программы до создания среды .NET Framework использовали неуправляемый код, который не выполняется CLR-системой. Управляемый и неуправляемый код могут работать вместе, поэтому факт создания компилятором С# управляемого кода отнюдь не ограничивает его возможность выполняться совместно с ранее созданными программами.

Рисунок 1. Структура стека технологий для managed-языков программирования.

Итак, в неуправляемом коде отсутствует промежуточный уровень между кодом на языке высокого уровня и непосредственно машинным кодом с инструкциями для процессора. То есть, руководствуясь терминологией рисунка 1, при компиляции и выполнении неуправляемого кода происходит прямой переход от пользовательских приложений и библиотек к уровню PAL (Processor Abstraction Layer – уровень абстракции процессора). Несмотря на то, что отсутствие промежуточных уровней компиляции и выполнения программы несколько повышает скорость, последние версии платформы .NET Framework в достаточной степени оптимизированы, чтобы скомпенсировать этот недостаток. Более того, если принять во внимание тематику настоящей работы, то есть специфику реализуемой системы и ее компонентов, станет ясно, что, например, 10-процентный выигрыш в производительности при реализации алгоритмов обсчета модели ничего не даст, если не будет налажено эффективное взаимодействие между упомянутыми алгоритмами и средой отображения модели. В то же время, если для реализации алгоритмов и среды будут использованы различные языки программирования, то потребуется дополнительный слой, конвертирующий данные между ними. Понижение производительности из-за наличия подобного «конвертора» будет значительно существеннее любого выигрыша, который способны предоставить современные версии unmanaged-языков по сравнению с современными версиями managed-языков.

Выводы

Итак, проанализировав вышеозначенные аргументы, можно придти к выводу, что, пожертвовав небольшим ухудшением в производительности по сравнению с unmanaged-языками программирования, мы получаем значительные выгоды в удобстве реализации кода, контроле его выполнения и высокой совместимости с операционной системой Windows. В дополнение к этому мы, безо всяких дополнительных усилий, получаем возможность исполнять написанный код в любых средах выполнения, для которых реализован .NET Framework Common Language Runtime. Итак, в качестве языка программирования будет избран язык C#, поскольку он является основным, а значит, обладающим наибольшей функциональностью, а также имеющим наиболее простой и понятный синтаксис из всех языков, в настоящее время поддерживаемых платформой .NET. В следующих статьях можно дополнительно будет убедиться в выгодах, предоставляемых C# при работе с библиотеками трехмерной графики.

Сравнительный анализ библиотек компьютерной трехмерной графики

Какие на сегодняшний день существуют аппаратно-ускоряемые библиотеки для создания компьютерной трехмерной графики? Конечно, любой специалист в области техники назовет DirectX и OpenGL. Проведем сравнительный анализ данных библиотек.

OpenGL и DirectX – основная информация

Во-первых, необходимо отметить, что все современные видеокарты имеют аппаратную поддержку возможностей и DirectX, и OpenGL последних версий, причем для совместимости с различными программными средствами (использующими ту или иную версию) производители встраивают в чипы реализацию сразу обеих библиотек. Причем можно с высокой степенью уверенности утверждать, что на аппаратном уровне реализация обеих библиотек выполнена настолько качественно, что ни одна из них не имеет значительно преимущества над другой. Различия между DirectX и OpenGL состоят в способе обработки графической информации, причем от версии к версии добавляются новые функции и возможности, позволяющие создавать более реалистичную графику.

Что же все-таки скрывается за словами OpenGL и DirectX? Слова эти именуют те самые Application Programming Interface (API — Интерфейс Прикладного Программирования), библиотеки для обработки графической информации и прямого доступа к железу («software interface to graphics hardware», как обозначаются они в спецификации). Из вышесказанного становится ясным, что данные библиотеки содержат набор уже однажды написанных функций, от самых простых (вывод точки на экран) до довольно сложных (построение готовых примитивов, например, пирамиды), которые применяются практически в каждой программе. Базовые функции реализованы аппаратно, в виде части графического процессора (Graphical Processing Unit, далее – GPU), а более сложные представляют собой программные модули, построенные на базовых командах. Видеокарта не всегда аппаратно поддерживает нужные для работы приложения функции, и в этом случае библиотека использует программные модули, эмулирующие требующиеся возможности. Однако необходимо отметить, что в контексте задачи, решаемой в настоящей работы, выполняемые операции относительно просты – например, не потребуется применения шейдерной графики – и, таким образом, можно сделать обоснованное предположение, что любая из доступных видеокарт будет аппаратно поддерживать все необходимые для работы приложения возможности.

Если попытаться объяснить понятным языком общую схему работы любой из библиотек, то она выглядит примерно так: предположим, требуется выполнить команду трилинейной фильтрации (Tri-linear Filtering – уменьшение искажения в картах текстур). Программа вызывает графическую часть DirectX (Direct3D или сокращенно D3D) и предает библиотечной функции данные и инструкции, в которых указывается, что нужно сделать с упомянутыми данными. Модуль библиотеки, отвечающий за работу с драйвером видеокарты, в свою очередь, передает ему необходимые данные и определяет, аппаратно или программно будет происходить требуемая обработка. Драйвер детектирует, что D3D данной версии полностью поддерживается на аппаратном уровне и передает на верхний уровень библиотеки ответ, что наличествует аппаратная поддержка. Дополнительно драйвер перенаправляет команды и информацию, полученную с программного уровня дальше вниз по так называемому «стеку обработки» – видеоадаптеру. Но на этой стадии разработчики видеокарты и драйвера могут внести в процесс свои коррективы. Например, Tri-linear Filtering – очень ресурсоемкая операция, поэтому на уровне драйверов она заменяется менее точной, но более быстрой Bri-linear Filtering (брилинейная фильтрация, реализована на картах фирмы ATi). Наконец, драйвер записывает в необходимые регистры GPU все данные, которые обрабатываются в соответствии с запросом, после чего в буфер отображаемого кадра (framebuffer) поступает двумерный кадр, который и выводится на монитор.

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

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


Реклама
Запись опубликована в рубрике Разные старые статьи. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s