фаил в память

← →
Tonich (2010-01-13 12:04) [0]

Дарова Всем.

Есть следующий вопрос-задача.

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

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

Сейчас я переделал это механизм, используя FileMapping, но особого прироста в скорости не получил (может просто из-за того что в корне не понимаю данный механизм, если кто-то объяснит буду благодарен)

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

← →
clickmaker © (2010-01-13 12:12) [1]

а почему бы их целиком в память не загнать?

← →
sniknik © (2010-01-13 12:12) [2]

> как будут предложения?
предложение поискать скорости в месте более зависящем от тебя (коде/алгоритме), а не от системы.

← →
tonich (2010-01-13 12:13) [3]

ну вот и я так думал..то есть считав их просто в массив я получу все коэффициенты в оперативке...

← →
tonich (2010-01-13 12:14) [4]

> предложение поискать скорости в месте более зависящем от
> тебя (коде/алгоритме), а не от системы.

ну собственно пересмотр алгоритма/кода и привел к тому что все основное время тратится на то что бы получить те самые коэффициенты

← →
Сергей М. © (2010-01-13 12:15) [5]

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

И поскольку ты "особого прироста в скорости не получил", следы ведут к неэффективному алгоритму самых вычислений с использованием массива, будь он хоть в MMF хоть еще где-то ..

← →
Сергей М. © (2010-01-13 12:16) [6]

> основное время тратится на то что бы получить те самые коэффициенты

На основании чего ты сделал такое умозаключение ?

← →
tonich (2010-01-13 12:20) [7]

> На основании чего ты сделал такое умозаключение ?

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

← →
tonich (2010-01-13 12:23) [8]

Сергей М.

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

← →
Сергей М. © (2010-01-13 12:28) [9]

> различные способы получения коэффициентов

С этого момента максимально подробно - что за "различные способы получения коэффициентов" ?

Есть массив A, не важно как организованный - то ли с использованием MMF то ли без него.
Каждое обращение к некоему элементу массива, кранящему коэф-т, сводится к обращению вида A[i].
Среднее время такого обращения, что в случае с MMF что без него, - величина при тех или иных доп.условиях вполне прогнозируемая.

?

← →
Сергей М. © (2010-01-13 12:32) [10]

> tonich (13.01.10 12:23) [8]

Это да.
Но даже если ты распределишь память под массив статически, объявив массив как стат.переменную типа array[0..дохрена], это вовсе не означает, что ОС не вправе в какой-то момент времени выбросить какие-то страницы вирт.памяти, которые занимает массив. в файл подкачки, так что последующая их подгрузка вызовет те же самые задержки, что и в случае с MMF-механизмом

← →
tonich (2010-01-13 12:47) [11]

> Сергей М. © (13.01.10 12:32) [10]

так ну вот теперь все окончательно прояснилось...

что касается

> Сергей М. © (13.01.10 12:28) [9]

дело было так...
эти самые коэфф. это коэффициенты полиномов Чебышева, позволяющие найти координаты некоторого небесного(дальше думаю не имеет смысла вникать в суть задачи, потому как все остальное мало связанно непосредственно с программированием ), они актуальны лишь для какого-то определенного промежутка времени. И можно грубо сказать что, для того что бы найти положения тех самых тел на промежутке Т1-Т2 необходимо взять коэфф. с 1 по 1000 допустим. Следовательно выходя за Т2 мы уже смотри смотрим временной интервал Т3-Т4 и коэфф с 1001 по 2000.

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

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

← →
clickmaker © (2010-01-13 12:48) [12]

а интересно, VirtualLock не поможет?
ведь по идее можно зафиксировать блок в физической памяти, чтобы винда не сбрасывала его в своп

← →
tonich (2010-01-13 12:50) [13]

> clickmaker © (13.01.10 12:48) [12]

а вот это уже интересно этого я не знал, надо почитать

← →
tonich (2010-01-13 12:53) [14]

притом что из всех 60 метров по суди мне надо всего лишь метров 20-25, я думаю система не сильно обидится, если я урву у нее 20 метров памяти

← →
Сергей М. © (2010-01-13 13:09) [15]

Собссно 60 мб - это не так уж и много. Резона использовать MMF что-то не видно.
Засосал все 60 мб в Memorystream - и работай с его св-вом Memory как с типиз.указателем на массив.

← →
tonich (2010-01-13 13:13) [16]

> Сергей М. © (13.01.10 13:09) [15]

но получается что часть этого самого мемори стрима будет в виртуальной памяти. А если попробовать применить VirtualLock к этому самому стриму то можно добиться что что бы он весь был в физической...так?

> часть этого самого мемори стрима будет в виртуальной памяти

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

← →
tonich (2010-01-13 13:18) [18]

ок, спасибо за информацию, будем ваять-с! ))

> А если попробовать применить VirtualLock к этому самому
> стриму то

.. то запросто можно получить граблями от Borland Memory Manager, особенно в случае если в цикле своих расчетов ты к нему обращаешься с просьбой о выделении/распределении/освобождении каких-то блоков памяти

> Tonich (13.01.2010 12:04:00) [0]

60 мб это примерно 1 секунда на загрузку, скорость определяет характеристики устройства и никак ты не сможешь ее повысить за счет чуда.

> tonich (13.01.2010 12:14:04) [4]

Ну так смени алгоритмы получения коэффициентов, раз ты уже определил узкое место.

> clickmaker (13.01.2010 12:48:12) [12]

Да какой еще сброс в своп при современных объемах памяти, если только искуственно устраивать такую ситуацию.

фаил в память Найти похожие ветки