Операции в больших циклах

[alexzk]

Сообщение от Haric_110

alexzk, благодарю, вещь полезная будем изучать)
О том, как применить конкретно в моём случае: как я понимаю, принцип состоит в том, чтобы разделить задачу между логическими процессорами, типа: 2 или 3 из 4-х заняты основными вычислениями а первом потоке, а остальные 2 или 1 проверяют чтение с клавиатуры, таким образом, процессор в результате загружается сильнее, производительность не страдает...

Не, я обязательно освоюсь в этой теме... ведь я планирую в перспективе увеличить число вычислений... я слышал, в моделировании из первых принципов всё только и стоит на параллельных вычислениях

Все верно. Главное не косячит с синхронизацией - недостаток ведет к случайным результатам, перебор - к потери скорости на ней и (или) дедлокам(когда 2 процессора взаимно ждут 1 ресурс вечно).

Но еще раз, для расчетов - openmp. Только, сам расчет нужно переделать так, чтоб паралельные его куски не зависили от других кусков. Т.о. можете увеличить расход памяти, например std::transfer позволяет эффективно посчитать подзадачи, но на результат подзадач - расход памяти, т.к. количество результатов = кол-ву входных данных (что не всегда так, и потом лишнее уже нада убирать на 1 процессоре).
Если расчеты в пределах школьной алгебры по сути, то их вообще можно на GPU сбросить. Т.о. программа на процессоре параллельно формирует блоки расчетов, которые скидываются на GPU(видеокарту), а там мат. процессоров сотни и тыщи.

Кстати, параллельные расчеты всяких синусов и косинусов будут не эффективны на центральном процессоре в параллельности (только целые вычисления), т.к. мат. блок всего 1. Он будет делится на все потоки. Для дробной математики нужно смотреть GPU, а CPU будет дирижером.
https://developer.nvidia.com/opencl

[Haric_110]

Сообщение от Pavia

Доказать что качество стандартного генератора не хватает.

Доказательство:

#include <iostream>
#include <ctime>

int main() {
	int	n, m, min, max, **rand_arr;
	srand(time(0));

	std::cout 
		<< "Enter a value of number of rows of the array:\n" 
		<< "n = ";

	std::cin >> n;

	rand_arr = new int *[n];

	std::cout
		<< "Enter a value of number of colums of the array:\n"
		<< "m = ";
	std::cin >> m;

	std::cout 
		<< "Enter a value of the minimum of the array:\n"
		<< "min = ";
	std::cin >> min;

	std::cout
		<< "Enter a value of the maximum of the array:\n"
		<< "max = ";
	std::cin >> max;

	std::cout << "\nArray of random numbers:\n";
	for (int i = 0; i < n; ++i) {
		rand_arr[i] = new int[m];
		for (int j = 0; j < m; ++j) {
			rand_arr[i][j] = rand() % (max - min + 1) + min;
			std::cout << rand_arr[i][j] << " ";
		}
		std::cout << '\n';
	}
	std::system("pause>>void");

	delete *rand_arr;
	return 0;
}

Как видно, числа очень неслучайные.
Я мог бы попробовать написать линейный конгруэнтный генератор из двух итераций, с отбросом младших битов (где-то читал про это), лучше будет, но всё равно, не уверен я...

Вихрь Мерсенна, конечно, хорош, но жертва тому - производительность

[Haric_110]

В общем, насчёт проверки клавиатуры на чтение, я решил поступить следующим образом: я засёк, сколько итераций происходит за 1 с, разделил это число на 10 (получилось около 6,5 миллионов), затем добавил в вычислительный цикл условие:

if ((n%6500000) == 0) {	// n определяет число итераций
	if (_kbhit()) {
		time_of_calc += clock() - start;
		_getch();

	/*предложение вывести промежуточные результаты, завершить или продолжить*/
	}
	start = clock();
}

Таким образом, проверка на чтение происходит примерно десять раз в секунду, производительность падает на величину n/6500000*c1 + n*c2, где с1 - время выполнения _kbhit(), c2 - время вычисления условия (n%6500000==0).
Кажется, с1 намного больше с2...

[alexzk]

Сообщение от Haric_110

В общем, насчёт проверки клавиатуры на чтение, я решил поступить следующим образом: я засёк, сколько итераций происходит за 1 с, разделил это число на 10 (получилось около 6,5 миллионов), затем добавил в вычислительный цикл условие:

if ((n%6500000) == 0) {	// n определяет число итераций
	if (_kbhit()) {
		time_of_calc += clock() - start;
		_getch();
	}
	start = clock();
}

Таким образом, проверка на чтение происходит примерно десять раз в секунду, производительность падает на величину n/6500000*c1 + n*c2, где с1 - время выполнения _kbhit(), c2 - время вычисления условия (n%6500000==0).
Кажется, с1 намного больше с2...

Сделайте класс типа

class Elapasable
{
   public:
       void restart();
       bool isElapsed();
}

который по рестарт запоминает текущие показатели таймера системы., isElapsed сравнивает текущий таймер и запомненый

static Elapasable some;
if (some.isElapsed()) {	// n определяет число итераций
	if (_kbhit()) {

		_getch();
	/*предложение вывести промежуточные результаты, завершить или продолжить*/
	}
some.restart();
}

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

Вообще забрасывайте к черту этот С стиль. Я тут ардуин прикупил, накачал библиотек....ну бред школьный...некоторые переписал на С++/шаблонах, сразу выиграл 1Кб (из 32Кб) размер. Так что, все мифы о вреде С++.
Конкретно, в С++ размер дает stdlib, но, предполагается, что ее будет делать разработчик девайса (т.е. оптимизировать). А без нее, язык намного более эффективен.

[Haric_110]

isElipced будет выполнять что-то, вроде

if(cloak() - start >= 100000) return 1;
else return 0;

?

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

[GreenWizard]

Если стоит задача тупо генерировать много чиселок, то можно упороться с всякими там потоками, CUDA и т.п.
Если же это нужно для моделирования какого-то процесса, то стоит его реализовать, а потом оптимизировать. Может мне гугл не то выдал, но, как я понял, этот ваш вихрь весьма шустрый и тормозить будет сама модель или что-то др. (память, работа с файлами, др.... в код не вникал, может вы там каждое число сохраняете в файл по одному байтику, в обратном порядке, ещё и переводя в строки, поэтому оно безбожно тормозит)

Всякие хаки с потоками и кол-вом итераций в секунду - верная дорога к лютым багам, даже если всего один, главный, поток. Если же их два, то это точно огребёте проблем и, что самое печальное, не сразу, а когда на 80% решите задачу свою и придётся всё переделывать. Хотите потоки? - Будьте добры, изучить и использовать объекты синхронизации (крит. секции и events тут самое оно). Если задача корректна и всё правильно разбито на потоки, с адекватной сихронизацией, то потоки могут существенно ускорить работу. Впрочем, бегло просмотрел тему и сейчас не советовал бы пытаться писать многопоточный вариант.

[Haric_110]

GreenWizard, хорошо, учту Ваши предостережения насчёт потоков. Я ещё не умею ими пользоваться, планирую изучить в будущем.
Насчёт случайных чисел, они нужны для моделирования случайных процессов. Вероятности процессов меняются линейно от n (число итераций). Модель я старался писать максимально эффективно, сократив вычислительные операции до необходимого минимума, в файл, разумеется, ничего не записывается, на консоль не выводится, только во время остановки программы можно что-то вывести или сохранить в файл и принудительно сохраняется примерно раз в час. Это необходимо, потому что однажды я огрёб от того, что случайно нажал в винде "Выход из системы" и потерял результат 28-часового расчёта. Теперь у меня есть возможность сохранять промежуточные результаты в файл и восстанавливать расчёт.
Долго программа работает из-за того, что число итераций может быть порядка 1e16, например, может 1e22. кстати, это число которое 64-х битный целочисленный тип данных не вмещает в себя, необходимо использовать число двойной точности, но, помню я, есть проблемы с инкрементом double-переменных... Там, вроде, флаг округления изменять нужно... как-то на низком уровне решается.
Перед тем, как писать на с++ и использовать вихрь Мерсена, я писал на с# и использовал тот стандартный генератор, который там был (не знаю, что там за алгоритм). Так вот, после того, как я перевёл всё на с++ и поменял только функцию генерации псевдослучайных чисел, программа стала работать значительно медленнее. Я думал, с++ больше подходит для этой задачи... но думаю, дело в том, что метод генерации СЧ значительно сложнее того, что в с#. Надо бы посмотреть по-подробнее.

[GreenWizard]

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

[Haric_110]

92-95 часов по расчётам... сегодня завершится должно через несколько часов, буду отмечать это событие)
Код скину вечером. Я изменил код на с++ с тех пор, как сравнил с кодом с#, добавил проверку на ввод с клавиатуры, возможность останавливать программу, выводить результаты, сохранение в файл промежуточных результатов и восстановление из файла. Это, конечно, немного уменьшило производительность, но именно немного (где-то на 2-3%, я сравнивал скорости вычислений, как число итераций в час)

[Haric_110]

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