Стоит задача максимально быстрой записи на диск большого количества данных. Данные генерирует прибор и они представляют из себя просто поток чисел. Числа приходят порциями (массивами). Количество записываемых данных ограничено максимальным размером файла.

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

На диске сначала формируется файл посчитанного (смотри ниже) размера, а потом порции данных пишутся уже в отведенный файл. При записи каждой порции, естественно, указывется в какое место файла ее писать. Это все понятно, а вот в определении размера файла я несколько запутался.

• На вход подается желаемый максимальный размер файла M.
• С жесткого диска считывается размер сектора (S) и максимальный размер файла уменьшается так, чтобы файл занимал целое число секторов: M=(M\S)*S.
• Размер порции данных, записываемой за один раз, известен (B). Максимальный размер файла еще раз уменьшается так, чтобы в файл помещалось целое число порций: M=(M\B)*B.
• Создается файл этого уменьшенного размера - и поехали записывать данные.

Что-то мне непонятно зачем надо сначала подгонять размер файла под размер сектора?

ЗЫ: Размер сектора всегда меньше, чем размер порции данных.

Спасибо

Купи SSD или пиши в RAM или ещё куда и не занимайся ерундой.
Некому твои 0.1% выигрыша в скорости не нужны когда как легко скорость поднимается заменой комплектующих, а это десятки сотни процентов выигрыша.
Что касается быстрой записи, то пиши просто порциями большого размера. Размер порции определяешь путём тестирования жесткого. А можно один раз протестировать перед разработкой программы и забыть как константу. 


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

Не совсем так

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

Pavia, спасибо за ответ. 

Первый пункт мне не подходит. Задача промышленная, RAM-а нужных размеров не бывает просто. Да и пишу я не на обычный жесткий диск из интернет магазина.

Запись порциями большого размера - это именно то, что и делается. Величина B в моем описании не маленькая.

Про лишний код я тоже подумал. Проблема в том, что писавший это разработчик - отнюдь не юниор, а персонаж весьма в данной области уважаемый. Забыть код почистить мог, конечно, а вот про кратное точно знает. Был бы он начинающим, я бы не задумываясь исправил и дальше пошел, а вместо этого сюда пишу - может сам я чего-то недогоняю?

Добавлено @ 16:00
Mirkes, как файлы будут использоваться я тоже не знаю. Но это и не важно. Задача - записать в заданном формате и прочитать записанное с целью контроля записи - не более того. Чукча не читатель, чукча писатель.  

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

Это сообщение отредактировал(а) _Y_ - 9.5.2013, 16:02

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

Остаётся спросить у автора или не париться. Даже самые опытные люди делают ошибки и глупости. Humanum errare est.

Ваши формулы, наверное, должны быть такими: M=floor(M/S)*S.

beroal, по первому пункту - это ИМХО очевидно.

У автора спросить в ближайшее время не удастся. Да, скорее всего, он уже и не помнит этот код.

floor(M/S) и M\S, сколь помню, разные записи одной и той же операции. Извиняюсь если написал непонятно.

_Y_, 

С этого и надо было начинать.  Всё таки не мешает выяснить связь B и S. Может кратность учитывается в другом месте программы и эти переменные кратны? Но в любом случае первая строчка лишняя. 
Единственное что может быть ваш диск не размечен и тогда да его надо первоначально привести к размеру кластера. 
(Размер диска обычно кратен сектору, но не обязан быть кратен кластеру) .  Далее делается разметка диска а после уже идет усечение до размера записываемой информации.
Строчки идут подряд?
M=(M\S)*S.
M=(M\B)*B. 
Если между строчками есть код, то там может быть не очевидный вызов метода класса или функции или макрос которую вы просто проглядели. В Си++ это очень легко сделать, в том смысле что легко проглядеть.

Mirkes, 
Если хотели избежать, то надо вычислять кратность. А во вторых файлы должны быть очень маленькими или кластеры очень большими.
Не выделяется. Уже давно есть ФС в которых в одном кластере находятся несколько файлов, к примеру NTFS. (Да, пример не очень, но по лучше пример искать лень) В самодельном хранилище данных скорее всего будет и самодельная ФС, а что там нагородили только авторам известно.



Это сообщение отредактировал(а) Pavia - 9.5.2013, 19:02

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


Строчек там нет - язык графический  но операции идут подряд.

А может действительно в старом коде между ними что-то было, это что-то убрали, а переписывать логику руки не дошли?

Что за файловая система надо посмотреть. Явно не самодельная, но, возможно, поставленная производителем дисков.

-------------- 

Спасибо всем за советы. Я, понемногу, начинаю догонять как надо сделать. Потестирую свои решения - отпишусь.

В описанном виде это не имеет НИКАКОГО смысла. Что-то либо убрано, либо недописано.Второе мне кажется более вероятным - заработало, и ладно.

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

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

Ну и конечно, буфер должен был кратен кластеру. 

Еще возможно стоит отключить кеширование записи. по крайней мере поиграцца с параметрами кеширования.
(но это уже системные дела)




Это сообщение отредактировал(а) volatile - 10.5.2013, 01:58

Пожалуй, что именно от этой гипотезы я уже и отталкиваюсь.


Ну, как сказать. Есть разные способы записи данных и скоость у них, как ни крути, разная. Но я , видимо, неясно выразился в самом начале. Я не остараюсь увеличить скорость. Эта задча уже решена предидущим разработчиком. Я развиваю программу дальше и мои вопросы вызваны, скорее, желанием не накосячить (что нетрудно если менять код, не полност'ю его понимая).


Буферизация отключена, но пишется не побайтно, а блоками.

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

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

Потому, что у "старичков" блоковая запись на уровне рефлексов. От-туда кстати могла появиться нормировка на блок, просто рефлекторно.

_Y_, Если B кратен S, то смысла в первой операции нет, в конце он и так будет кратен S (это понятно, и здесь уже об этом писали)
Если B не кратен S, то смысла в первой операции - тоже нет  
В конце, в общем случае, М не будет кратен S, а округлять до S промежуточное значение имеет мало смысла.
Это чисто по логике.

Теперь по скорости записи.
Вся эта возня, вообще никак не отразицца на скорости, имхо.   


Это сообщение отредактировал(а) volatile - 10.5.2013, 23:47

В общем, с вашей помощью, да с помощью RTFM вырисовалась разумная картина.

Код мусорный я убрал, конечно, но размер файла считаю как кратное к наименьшему общему кратному от размера блока данных (B) и размера сектора диска (S).

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

Спасибо

У нас «\» было вычитанием множеств.