Участница:Alinap95 - История изменений

Alinap95 в 02:20, 7 августа 2021

2021-08-07T02:20:03Z

← Предыдущая		Версия 12:20, 7 августа 2021
Строка 25:		Строка 25:
	=По рефакторингу=		=По рефакторингу=
	Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource). (Возможно, нужно применить паттерн Декоратор?)		Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource). (Возможно, нужно применить паттерн Декоратор?)

			=Идея для статьи=
			Переделать парсер математических выражений, сделав его объектно-ориентированным. В дальнейшем прикрутить SBO.

Alinap95: /* По рефакторингу */

2018-07-02T23:56:44Z

По рефакторингу

← Предыдущая		Версия 09:56, 3 июля 2018
Строка 24:		Строка 24:

	=По рефакторингу=		=По рефакторингу=
	Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource).		Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource). (Возможно, нужно применить паттерн Декоратор?)

Alinap95 в 23:30, 2 июля 2018

2018-07-02T23:30:51Z

← Предыдущая		Версия 09:30, 3 июля 2018
Строка 22:		Строка 22:

	По CUDA. Первичная обработка – это инициализация модели на узле? Мы посылаем устройству (CUDA) задание, вызывая ядро с параметрами, ждем результата. Во время выполнения циклов по перебору контрольных точек и созданию вторичных источников мы опять вызываем соответствующие ядра CUDA, и ждем результатов. Нам нужен будет какой-нибудь класс с интерфейсом для CPU, реализующий очередь задач (на основе очереди, создаваемых драйвером CUDA), возможно с ограниченной клиентом длиной. Опять же, если выполнение ядра дает ошибку, выполняем на CPU или генерируем ошибку узла или пытаемся выполнить вновь на CUDA позже (если синхронная функция CUDA, напр. cudaDeviceSynchronize или cudaMemcpy, дает ошибку вроде cudaErrorIllegalAddress – это нехватка ресурсов). [[Участник:Андрей Чусов\|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов\|обсуждение]]) 09:05, 4 января 2018 (UTC)		По CUDA. Первичная обработка – это инициализация модели на узле? Мы посылаем устройству (CUDA) задание, вызывая ядро с параметрами, ждем результата. Во время выполнения циклов по перебору контрольных точек и созданию вторичных источников мы опять вызываем соответствующие ядра CUDA, и ждем результатов. Нам нужен будет какой-нибудь класс с интерфейсом для CPU, реализующий очередь задач (на основе очереди, создаваемых драйвером CUDA), возможно с ограниченной клиентом длиной. Опять же, если выполнение ядра дает ошибку, выполняем на CPU или генерируем ошибку узла или пытаемся выполнить вновь на CUDA позже (если синхронная функция CUDA, напр. cudaDeviceSynchronize или cudaMemcpy, дает ошибку вроде cudaErrorIllegalAddress – это нехватка ресурсов). [[Участник:Андрей Чусов\|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов\|обсуждение]]) 09:05, 4 января 2018 (UTC)

			=По рефакторингу=
			Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource).

Андрей Чусов: Новая страница: «=По балансировке= Пусть в domain_node существует некий контейнер статусов узлов vector>…»

2018-01-04T09:05:38Z

Новая страница: «=По балансировке= Пусть в domain_node существует некий контейнер статусов узлов vector<pair<string, int>>…»

Новая страница

=По балансировке=
Пусть в domain_node существует некий контейнер статусов узлов vector<pair<string, int>> nodeStatuses, где будет храниться адрес узла и его статут (например, 0 – занят, 1 – свободен).
Когда стартует узел, он посылает сигнал о готовности в domain_node. Domain_node, в свою очередь, записывает в nodeStatuses адрес узла и его статус 1. При записи должен срабатывать триггер – если записали 1, то тут же надо посылать задание на обработку узлом, после чего присвоить 0 – узел занят. Таким образом, вектор будет иметь N ячеек по количеству узлов.
По мере выполнения, каждую минуту (интервал может быть и другим) просыпается отдельно выделенный поток на каждом узле (или сделать его detached, а не вводить в сон?), который опрашивает состояние (isProcessRunning), после чего отправляет запрос на запись уже в свою выделенную ячейку о статусе (стоит ли создать мьютекс на каждую ячейку вектора?). Возможно, задания будут выполнены раньше, поэтому надо также реализовать передачу в поток сигнала о том, что задания выполнены.
Возможно, стоит рассмотреть случай выхода из строя узла (если такой системы нет). Тогда имеет смысл хранить посланное задание (набор параметров и функцию). Если вышел из строя, то нужно будет послать первому свободному узлу задание отключенного узла. - Алина.

Я так понимаю, вы хотите убрать процедуру запроса состояния «пауза-запрос-снять с паузы»?

[[File:DIS-DS-Query-Sequence.svg|500px|thumb|right|Протокол опроса состояния процесса моделирования, выполняемого асинхронно экземпляром подсистемы предметной области (ППО) и его узлами.]]

1. isProcessRunning – это метод узла или балансировщика? Процесс определен на узле, поскольку им и выполняется, иначе нужно будет вводить сведения о существующих логических процессах в балансировщик. (Логический процесс, в отличие от процесса моделирования, – элемент параллельного выполнения в терминах глобального балансировщика нагрузки).

2. А зачем узлу знать о том, что все задания выполнены? Сейчас он просто реализует сервер «получил свое задание-выполнил-уведомил балансировщик». Можно сделать это для «головного узла» (ППО на рисунке), задачей которого является взаимодействие с предметно-независимой подсистемой. Можно в балансировщике в интерфейсе [[ILoadBalancer]] реализовать метод, например, GetLoadInformation, который позволял бы атомарно (в глобальном смысле) получать информацию о количестве свободных узлов и параметрах, т.е. объединить методы [[ILoadBalancer::NodeCount]] и [[ILoadBalancer::ParametersTotalSize]]. Далее ППО на основе этих данных делала бы вывод о состоянии общего процесса моделирования. Вроде бы это позволило бы избавиться от паузы. Но на это еще надо внимательно посмотреть.

Очередь с приоритетом все равно нужна. Можно, конечно, определить ее над вектором.

Если асинхронный метод [[INode::StartProcess]] (в т.ч. на стороне прокси, реализующего коммуникацию, в распределенной конфигурации) вернул код ошибки, значит задание из балансировщика не извлекается. Но если узел задание принял, т.е. метод вернул «успех», а потом отключился, то да – задание потеряно. Если же соединение не потеряно, но ошибочно лишь выполнение логического процесса узлом, то узел может вновь поместить задание в балансировщик (такого в узле сейчас нет). [[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 09:05, 4 января 2018 (UTC)

=По CUDA=

Стратегия использования всех мощностей будет хорошо работать при наличии хотя бы одно устройства с CUDA; мощности позволят быстрее проводить первичную обработку. (Позволит ли разделение процесса обработки и вычисления отлавливать ошибки эффективнее?) - Алина.

По CUDA. Первичная обработка – это инициализация модели на узле? Мы посылаем устройству (CUDA) задание, вызывая ядро с параметрами, ждем результата. Во время выполнения циклов по перебору контрольных точек и созданию вторичных источников мы опять вызываем соответствующие ядра CUDA, и ждем результатов. Нам нужен будет какой-нибудь класс с интерфейсом для CPU, реализующий очередь задач (на основе очереди, создаваемых драйвером CUDA), возможно с ограниченной клиентом длиной. Опять же, если выполнение ядра дает ошибку, выполняем на CPU или генерируем ошибку узла или пытаемся выполнить вновь на CUDA позже (если синхронная функция CUDA, напр. cudaDeviceSynchronize или cudaMemcpy, дает ошибку вроде cudaErrorIllegalAddress – это нехватка ресурсов). [[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 09:05, 4 января 2018 (UTC)