WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

загрузка...
   Добро пожаловать!

Pages:     | 1 || 3 |

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

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

Все современные разработки (практические реализации) принято делить на три направления:

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

Специальные приложения, контролирующие упреждающие выборки и кэширование: подобными системами занимался Patterson. Он модифицировал два unix приложения: make и grep, таким образом, что файловой системе передавалась информация о файлах, к которым собирается обратиться приложение заранее. Такой подход повысил эффективность исполнения приложения от 13 до 30%.

Специальное компилирование приложений: Основная идея этого направления заключается в исключении роли разработчика приложения для использования упреждающего кэширования. Chang и Gibson разработали средство SpecHint, которое специальным образом изменяло откомпилированные файлы, что позволяло использовать так называемое спекулятивное выполнение задачи в моменты блокирующих операций ввода/вывода.

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

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

Упреждающее кэширование основывается на четырех компонентах: транслятор исходного кода, библиотека упреждающего кэширования, загрузочном модуле и модуле упреждающего кэширования (рис. 3).

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

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

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

1. create_prefetch_thread(prefetch_function): эта функция позволяет приложению создать упреждающий поток и выполнить prefetch_fuction.

2. prefetch_xxx(): это множество функций, которые заменяют в упреждающем потоке все стандартные функции ввода/вывода.

3. inform_open(file_pointer) и inform_close(file_pointer): Эти функции необходимы для того, чтобы информировать упреждающий поток об открытии или закрытии файлов вычислительным потоком.

4. synchronize(synchronization_point, type): эта функция синхронизации двух потоков.

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

1. Открытие файла: Упреждающий поток должен ожидать пока вычислительный поток откроет файл. Потоки синхронизируются вызовом synchronize() с указанием номера синхронизационной точки (табл. 1).

2. Ввод информации пользователем: Упреждающий поток вынужден ожидать, пока вычислительный поток вычислит адрес на основе входной информации(stdin) или считает его из специального файла. Если адрес следующих данных зависит от данных файла, для которого уже осуществляется предвыборка, тогда в каждый из потоков вставляются точки синхронизации. Если входные данные считываются из конфигурационных файлов, тогда также добавляются точки синхронизации.

3. Чтение после записи: Если программа содержит только вызовы чтения из одного файла и запись в разные файлы или операции чтения и записи не пересекаются для некоторого файла, тогда во всех этих случаях синхронизация не нужна, в остальных случаях синхронизация необходима.

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

Транслятор основывается на двух алгоритмах: внутренний и внешний анализ зависимостей функции. Цель внутренннего анализа заключается в построение зависимостей внутри функции. В результате анализа определяются все переменные и выражения, относящиеся к дисковому вводу/выводу.

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

Все вызовы упреждения, которые использует упреждающий поток, содержатся в библиотеке упреждающих вызовов, размещаются и хранятся в памяти очередь команд на упреждение. Структура очереди команд на упреждение имеет следующий вид: {идентификатор файла, номер блока, идентификатор вызова}. Идентификатор файла и блока определяют реальный физический блок данных, который необходимо предвыбрать. Идентификатор вызова определяет вызов, который инициировал запуск механизма упреждения для данного блока. Начальное значение идентификаторов вызовов начинается с 0. Файловая таблица для каждого файла дескриптора содержит смещение. Используя эту информацию всегда можно вычислить номер блока для вызовов prefetch_read и prefetch_lseek.

Таблица Пример вычислительного и упреждающего потоков int fp;

Вычислительный поток(ВП)** Упреждающий поток(УП) void main(void){ Void prefetch_fuction(void){ int i; int data[100]; int I;

/*создание упреждающего потока*/ ##C1 create_prefetch_thread( (void*)prefetch_function);

/*открытие файла данных*/ C2 fp=open(“mydata.dat”, O_RDONLY);

/*сигнал упреждающему потоку*/ ##C3 synchronize(1, signal); /*ожидание открытия файла*/ $$P1 synchronize(1, wait);

/*указание об открытии файла*/ $$P2 inform_open(fp);

C4 for(i=99; i>=0; i--){ /*предвыборка*/ /*ввод-вывод*/ P3 for(i=99; i>=0; i--){ C5 lseek(fp, i*4, SEEK_SET);

C6 read(fp, &data[99-i], 4); /*только ввод-вывод*/ /*вычисления*/ P4 prefetch_lseek(fp,i*4,SEEK_SET);

C7 data[99-i] = data[99-i]*i; P5 prefetch_read(fp, 4);

} /*закрытие файла*/ C8 close(fp); } } /*указание о закрытие файла*/ $$P6 inform_close(fp);

} **Слева вычислительный поток, справа упреждающий поток. Внутри функции main строчки без ## являются оригинальным кодом приложения. В этот код были вставлены изменения по созданию упреждающего потока. Строчки без символа $$ были взяты с оригинального кода приложения. В упреждающем потоке не присутствуют вычисления.

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

Разработан вариант модуля упреждающего кэширования на основе разделения потоков под версию ядра Linux 2.4. Необходимо загрузить разработанные модификации ядра Linux и специальный драйвер устройства. Для проверки разработанного модуля упреждающего кэширования использовались следующие тестовые программы:

1. XDataSlice (версия 2.2) – средство визуализации трехмерных массивов.

Позволяет динамически загружать большие массивы данных.

2. Приложение для расчета быстрого преобразования Фурье FFT (fast Fourier transform).

3. Agrep (версия 2.0.4) – программа поиска в текстовых файлах. Данная утилита осуществляет поиск текста по шаблонам среди большого количества текстовых файлов.

4. PostgreSQL (версия 7.0.3) – расширенная версия СУБД Postgres. Запускался процесс расчета индексов для четырех частей базы.

5. Mpich2 – реализация MPI. Использовалась программа перемножения двух матриц, файлы которых располагаются на множестве узлов ввода/вывода.

Рисунок 4 - Архитектура исполняющей системы В работе метод проверялся на решении задач физики газовых лазеров.

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

Исследовалось влияние конвекции на теплоотвод в коаксиальном цилиндре с учетом объемного энерговыделения. Рассматривается жидкость в пространстве между двумя коаксиальными цилиндрами радиусов Ri и Ro. Сами цилиндры поддерживаются при температурах То и Ti. В системе происходит постоянное энерговыделение c объемной мощностью Q, не зависящей от координат среды. После обезразмеривания и перехода к новым переменным, исходная система сводилась к системе трех уравнений второго порядка:

На рис. 5 представлена поверхность RaT (Ra, ), которая отделяет точки, соответствующие двумерной конвекции, от трехмерных режимов. Приведенные в работе расчеты касались двумерной модели (R, ) и не очень больших чисел Рэлея. Кроме того, достаточно просто учитывалось энерговыделение в системе. Увеличение RaT приводит к изменению структуры конвективного течения, поэтому анализ конвективных потоков играет исключительно важную роль при расчете геометрии лазерной системы. На рис. 6 представлены линии тока и профиль температур в координатах радиус-угол для параметров: = 2, ri =1, ro = 2, RaT = 3104, Ra = 0. Как видно из рисунка, наблюдается сильная неоднородность распределения температуры по углу. Максимальное значение температуры превышает соответствующее значение максимальной температуры в системе без конвекции. Для того, чтобы проследить эволюцию температур и линий тока с течением времени, необходимо вычислить соответствующие поля. Для вычисления каждого поля (в рамках реализации задачи это представляет собой матрицу некоторого размера) на каждом временном шаге необходимо решить систему трех уравнений (5-7).

Pages:     | 1 || 3 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»