Ребят, потестите пожалуйста

← →
DevilDevil © (2013-02-13 10:25) [0]

Разрабатываю библиотеку для скоростного буферезированного чтения/записи файлов. Осенила меня идея, что можно добавить в такой алгоритм "чтение/запись куска памяти в файле в отдельном потоке", дабы не тормозить hardware работой основной поток.

Написал бенчмарк для записи файла (около 100мб) стандартными подходами и с помощью моей библиотеки. Результаты работы (моей библиотеки) меня удивляют. Но для более общей картины хочу попросить вас протестировать бенчмарк на нескольких машинах.

Вот ссылка: http://zalil.ru/34256579
Бенчмарк выполняется около часа. За счёт вариантов записи в TFileStream и в TMemoryStream. Так что уходя на обед вполне можно запустить. Но если не хотите ждать или нет времени - можете в исходнике закомментировать строки:
RunBenchmarkProc("Standard TFileStream writer", StreamWriter, false); RunBenchmarkProc("Standard TMemoryStream+SaveToFile()", StreamWriter, true);

Спасибо за помощь

← →
Владислав © (2013-02-13 11:38) [1]

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

← →
DevilDevil © (2013-02-13 12:25) [2]

> А зачем это все?

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

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

На данный момент меня больше интересует не TFileStream и не TMemoryStream. Меня интересуют различные вариации записи через мой "класс"

← →
Владислав © (2013-02-13 12:42) [3]

> для того чтобы сравнить различные способы записи в файл

Способ в итоге один: WriteFile.

> можете добавить свой метод

Чтобы добавить метод, нужно знать цель. Если просто "посравнивать", то Вы эту цель уже выполнили. :)

> можете добавить бенчмарк другого подхода - будет интересно

Все эти бенчмарки зависят от задачи.

> Меня интересуют различные вариации записи через мой "класс"

Мне не очень понятно, для чего нужны Ваши классы. Последовательное чтение и последовательная запись в файл?

← →
DevilDevil © (2013-02-13 12:47) [4]

> Владислав © (13.02.13 12:42) [3]

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

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

приведите цифры бенчмарка пожалуйста

← →
O'ShinW © (2013-02-13 12:49) [5]

ничего не смотрел, просто запустил
Win7 64бит SP1
Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
4 гига RAM
IDE\DiskWDC_WD5000AAKX-001CA0

The benchmark shows how quickly you can write files
Destination file must be same as "correct_file.txt" (about 100Mb)
Test data generating... done.

Let"s test methods (it may take an hour, but try to wait):
1.txt - "Standard TFileStream writer"... 73601ms
comparing with correct file... binary equal.
2.txt - "Standard TMemoryStream+SaveToFile()"... 294842ms
comparing with correct file... binary equal.
3.txt - "Simple CachedFileWriter"... 2293ms
comparing with correct file... binary equal.
4.txt - "Simple CachedFileWriter+DoubleThreading"... 2496ms
comparing with correct file... binary equal.
5.txt - "Fast CachedFileWriter"... 141ms
comparing with correct file... binary equal.
6.txt - "Fast CachedFileWriter+DoubleThreading"... 109ms
comparing with correct file... binary equal.

Press Enter to quit

← →
Владислав © (2013-02-13 12:56) [6]

The benchmark shows how quickly you can write files Destination file must be same as "correct_file.txt" (about 100Mb) Test data generating... done. Let"s test methods (it may take an hour, but try to wait): 1.txt - "Simple CachedFileWriter"... 312ms comparing with correct file... binary equal. 2.txt - "Simple CachedFileWriter+DoubleThreading"... 265ms comparing with correct file... binary equal. 3.txt - "Fast CachedFileWriter"... 218ms comparing with correct file... binary equal. 4.txt - "Fast CachedFileWriter+DoubleThreading"... 187ms comparing with correct file... binary equal. Press Enter to quit

Если Вам нужно последовательное чтение и последовательная запись в файл на OS Widows, смотрите в сторону CreateFile + FILE_FLAG_NO_BUFFERING + FILE_FLAG_SEQUENTIAL_SCAN + FILE_FLAG_WRITE_THROUGH (в правильном сочетании флагов).

← →
DevilDevil © (2013-02-13 12:59) [7]

> O"ShinW © (13.02.13 12:49) [5]
> Владислав © (13.02.13 12:56) [6]

спасибо.

> Если Вам нужно последовательное чтение и последовательная
> запись в файл на OS Widows, смотрите в сторону

а можно поподробнее об этих флагах ?
может у себя на машине поэкспериментируете в TCachedFileWriter ?

← →
Владислав © (2013-02-13 13:09) [8]

The benchmark shows how quickly you can write files Destination file must be same as "correct_file.txt" (about 100Mb) Test data generating... done. Let"s test methods (it may take an hour, but try to wait): 1.txt - "Standard TFileStream writer"... 198106ms comparing with correct file... binary equal. 2.txt - "Standard TMemoryStream+SaveToFile()"... 1357ms comparing with correct file... binary equal. 3.txt - "Simple CachedFileWriter"... 281ms comparing with correct file... binary equal. 4.txt - "Simple CachedFileWriter+DoubleThreading"... 265ms comparing with correct file... binary equal. 5.txt - "Fast CachedFileWriter"... 203ms comparing with correct file... binary equal. 6.txt - "Fast CachedFileWriter+DoubleThreading"... 171ms comparing with correct file... binary equal. Press Enter to quit

> а можно поподробнее об этих флагах ?

В справке по функции CreateFile.

> может у себя на машине поэкспериментируете в TCachedFileWriter
> ?

Нет на это времени. :)

← →
Slym © (2013-02-13 13:36) [9]

Лихо ты с несозданными экземплярами орудуешь...
var Writer: TCachedFileWriter; begin Writer.Initialize(FileName, Flag);

← →
Владислав © (2013-02-13 13:43) [10]

> Лихо ты с несозданными экземплярами орудуешь...

Since object types do not descend from Borland.Delphi.System.TObject, they provide no built-in constructors, destructors, or other methods. You can create instances of an object type using the New procedure and destroy them with the Dispose procedure, or you can simply declare variables of an object type, just as you would with records.

← →
DevilDevil © (2013-02-13 14:18) [11]

> Нет на это времени. :)

ога )))))

← →
Дмитрий С © (2013-02-13 14:30) [12]

100Mb за 171мс, это 580 мегабайт в секунду. Это что за жесткий такой?

← →
Владислав © (2013-02-13 14:37) [13]

> Дмитрий С © (13.02.13 14:30) [12]

HDD. А время не мое, не разбирался, что оно означает.

← →
DevilDevil © (2013-02-13 15:30) [14]

Убрал запись через TFileStream и TMemoryStream
добавил бенчмарк на чтение
http://zalil.ru/34257617

протестируйте пожалуйста
можно запустить файл "benchmarks.bat" - он выдаст файл "benchmarks.log"

← →
Дмитрий С © (2013-02-13 15:35) [15]

> DevilDevil © (13.02.13 15:30) [14]

Твой класс позволяет записать 580 мегабайт в секунду?

← →
Дмитрий С © (2013-02-13 15:37) [16]

> 2.txt - "Standard TMemoryStream+SaveToFile()"... 294842ms
> comparing with correct file... binary equal.

> 1.txt - "Standard TFileStream writer"... 198106ms
> comparing with correct file... binary equal.

Вообще во все это верится слабо.
Почему так доооолго?

← →
dmk © (2013-02-13 15:52) [17]

win7 64 - ST31500341AS

Let"s test methods (it may take an hour, but try to wait):
1.txt - "Standard TFileStream writer"... 52525ms
comparing with correct file... binary equal.
2.txt - "Standard TMemoryStream+SaveToFile()"... 252051ms
comparing with correct file... binary equal.
3.txt - "Simple CachedFileWriter"... 1170ms
comparing with correct file... binary equal.
4.txt - "Simple CachedFileWriter+DoubleThreading"... 1139ms
comparing with correct file... binary equal.
5.txt - "Fast CachedFileWriter"... 140ms
comparing with correct file... binary equal.
6.txt - "Fast CachedFileWriter+DoubleThreading"... 94ms
comparing with correct file... binary equal.

>binary equal
У меня обычным BlockWrite (в цикле) 538 Мб за 381 мс записалось (писалка TIFF"ов написанная 9 лет назад :)
100 Мб пишет за 79 мс vs ваши 94 мс. IMHO лучше оставить эту задачу на совести ОС.

← →
DVM © (2013-02-13 16:02) [18]

> У меня обычным BlockWrite (в цикле) 538 Мб за 381 мс записалось
> (писалка TIFF"ов написанная 9 лет назад :)

куда оно с такой скоростью записалось да еще 9 лет назад?

← →
Дмитрий С © (2013-02-13 16:07) [19]

> куда оно с такой скоростью записалось да еще 9 лет назад?

Видимо в кеш записи:)

← →
dmk © (2013-02-13 16:13) [20]

DVM © (13.02.13 16:02) [18]
В кэш скорее всего. А записалось сегодня. С тех пор 4 компьютера сменил.

← →
DevilDevil © (2013-02-13 16:19) [21]

> Дмитрий С ©
> Твой класс позволяет записать 580 мегабайт в секунду?

ну современные винчестеры позволяют писать ещё с большей скоростью

> Вообще во все это верится слабо.
> Почему так доооолго?

TMemoryStream долго потому, что постоянно перевыделяет память. Если не ошибаюсь - по 8кб. А тут их надо 100Мб

TFileStream тормозит потому, что происходит очень много обращений к файловой системе

> dmk © (13.02.13 15:52) [17]
> IMHO лучше оставить эту задачу на совести ОС.

по сути без DoubleThreading - и есть "на совести ОС"

Спасибо за тест!
посмотри ещё reader пожалуйста ! (последняя ссылка)

← →
Дмитрий С © (2013-02-13 16:26) [22]

> TMemoryStream долго потому, что постоянно перевыделяет память.
> Если не ошибаюсь - по 8кб. А тут их надо 100Мб
>
> TFileStream тормозит потому, что происходит очень много
> обращений к файловой системе

Так это идиотизм писать по 8кб такой объем. Так никто не будет делать.

← →
DevilDevil © (2013-02-13 16:31) [23]

> Дмитрий С © (13.02.13 16:26) [22]
> Так это идиотизм писать по 8кб такой объем. Так никто не
> будет делать.

пока я тебе не сказал - ты не знал этого факта о TMemoryStream
следовательно на практике тебя мало что может остановить от использования TMemoryStream

это я к чему
люди вообще слабо заботятся об оптимизациях. Особенно если не знают внутренних механизмов: классов, RTTI, ассемблера

отчасти поэтому я пишу такие "классы". Чтобы разочек написать, отладить, и больше не возвращаться

← →
Дмитрий С © (2013-02-13 16:34) [24]

> пока я тебе не сказал - ты не знал этого факта о TMemoryStream
> следовательно на практике тебя мало что может остановить
> от использования TMemoryStream

в него тоже можно по разному писать, например сразу
MS.Size := 100*MB;
Как и в файл, чтобы не мучить файловую систему.

Интересно а как твой класс выбирает приращение блоков памяти?

← →
DVM © (2013-02-13 16:39) [25]

> DevilDevil © (13.02.13 16:19) [21]
> > Дмитрий С ©
> > Твой класс позволяет записать 580 мегабайт в секунду?
>
> ну современные винчестеры позволяют писать ещё с большей
> скоростью

Ну это сказки. Пропускная способность даже для SAS - 3000 мбит/сек и это в теории, на практике меньше, а это равно 375 МБАЙТ/СЕК

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

Stream := TBufferedStream.Create(TFileStream.Create("test.dat", fmCreate or fmOpenWrite), 65534, true);

Получилось 1500 мсек.

← →
DevilDevil © (2013-02-13 16:42) [26]

> Дмитрий С © (13.02.13 16:34) [24]

> Интересно а как твой класс выбирает приращение блоков памяти?

не поверишь
для любого файла используется 256кб памяти

> в него тоже можно по разному писать, например сразу
> MS.Size := 100*MB;

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

← →
DevilDevil © (2013-02-13 16:45) [27]

> DVM © (13.02.13 16:39) [25]

> Ну это сказки.

буду знать

> Я кстати попробовал сделать тест для записи строк в файл
> аналогичный твоему

да, да !
мы говорили с тобой о твоём классе

> Получилось 1500 мсек.

это круто конечно :)
но сколько выдаёт мой "класс" :)
ты засунь свой TBufferedStream в бенчмарк. Сделай по аналогии с TStream

← →
Jeer © (2013-02-13 16:49) [28]

Хрень какая-то:
1. Бенч на HDD
2. Бенч на RAM

http://s16.radikal.ru/i191/1302/f4/928cd4f71c03.png

← →
DVM © (2013-02-13 16:52) [29]

> DevilDevil © (13.02.13 16:45) [27]

> ты засунь свой TBufferedStream в бенчмарк.

у меня твой код не компилируется в XE2 там исправлять надо в нескольких местах.

← →
DevilDevil © (2013-02-13 16:53) [30]

> Jeer © (13.02.13 16:49) [28]

эммм.. я может что-то не понимаю
что значит "на RAM" ?

кстати запусти лучше "benchmarks.bat" отсюда: http://zalil.ru/34257617
он выдаст файл "benchmarks.log"
здесь убран TFileStream и TMemoryStream, добавлен бенч на чтение

← →
DVM © (2013-02-13 16:55) [31]

> DevilDevil © (13.02.13 16:45) [27]

> но сколько выдаёт мой "класс" :)

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

← →
DevilDevil © (2013-02-13 16:57) [32]

> у меня твой код не компилируется в XE2 там исправлять надо
> в нескольких местах.

кстати я планирую отдать библиотеку общественности (когда разберусь с DoubleThreading и т.д.). Чтобы потом была поддержка всех Delphi, в том числе FPC, x64, ARM, Linux, MacOS, iOS

странно что не компилируется
исправь если можешь
и скажи в чём была проблема - на будущее

← →
DVM © (2013-02-13 17:00) [33]

> DevilDevil © (13.02.13 16:57) [32]

> и скажи в чём была проблема - на будущее

Например тут:
function FuncThreadFinalizing(Parameter: pointer): integer; begin with (PCachedBufferThreadMemory(Parameter)^) do begin if (State = STATE_DONE) then State := STATE_FINALIZE; // <===тут Result := State; end; end;

[DCC Error] CachedBuffers.pas(533): E2064 Left side cannot be assigned to

← →
Дмитрий С © (2013-02-13 17:00) [34]

> DevilDevil © (13.02.13 16:57) [32]

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

← →
Jeer © (2013-02-13 17:04) [35]

Win7 64 Intel 16Gb

Ну вот тебе на HDD SCSI:

------- writing_benchmark.exe -------
The benchmark shows how quickly you can write files
Destination file must be same as "correct_file.txt" (about 100Mb)
Test data generating... done.

Let"s test methods:
1.txt - "Simple CachedFileWriter"... 1467ms
comparing with correct file... binary equal.
2.txt - "Simple CachedFileWriter+DoubleThreading"... 7753ms
comparing with correct file... binary equal.
3.txt - "Fast CachedFileWriter"... 140ms
comparing with correct file... binary equal.
4.txt - "Fast CachedFileWriter+DoubleThreading"... 7613ms
comparing with correct file... binary equal.
.
.
.
------- reading_benchmark.exe -------
The benchmark shows how quickly you can read/parse files
Testing file is "correct_file.txt" (about 100Mb)
Total sum of numbers must be equal 0x2904E86C0

Let"s test methods (it may take a few minutes):
1) "Standard TStringList reader"... 4696ms
2) "Fast buffering reader"... 483ms
3) "Using CachedFileReader"... 390ms
4) "Using CachedFileReader+DoubleThreading"... 375ms

И диск 2 Gb реализованный в памяти ( RAM )
------- writing_benchmark.exe -------
The benchmark shows how quickly you can write files
Destination file must be same as "correct_file.txt" (about 100Mb)
Test data generating... done.

Let"s test methods:
1.txt - "Simple CachedFileWriter"... 1466ms
comparing with correct file... binary equal.
2.txt - "Simple CachedFileWriter+DoubleThreading"... 7878ms
comparing with correct file... binary equal.
3.txt - "Fast CachedFileWriter"... 171ms
comparing with correct file... binary equal.
4.txt - "Fast CachedFileWriter+DoubleThreading"... 7379ms
comparing with correct file... binary equal.
.
.
.
------- reading_benchmark.exe -------
The benchmark shows how quickly you can read/parse files
Testing file is "correct_file.txt" (about 100Mb)
Total sum of numbers must be equal 0x2904E86C0

Let"s test methods (it may take a few minutes):
1) "Standard TStringList reader"... 4665ms
2) "Fast buffering reader"... 483ms
3) "Using CachedFileReader"... 375ms
4) "Using CachedFileReader+DoubleThreading"... 374ms

← →
DevilDevil © (2013-02-13 17:05) [36]

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

так задача моих TCachedBufferWriter и TCachedBufferReader - такая же как у твоего TBufferedStream. Только:
1) принципиально различаются чтение и запись. У тебя насколько понял всё в одном
2) для файлов существуют отдельные "классы". Специально заточенные, чтобы больше не париться
3) у тебя насколько понял есть только Read() и Write(). Тут кроме "высокоуровневых" методов есть возможность работать с низким уровнем: Current, Margin(остаток в буфере) и Flush. Это позволяет снизить оверхед на вызов лишних методов. Типа Move/CopyMemory если пишем маленький объект константного размера. Используется object, а не class опять таки не случайно. Доступ к полям object быстрее доступа к полям class; особенно если object хранится на стеке. Кроме того такое использование положительно сказывается на кэш-френдли
4) выравнивание буферизированной памяти по границе в 4кб + дополнительные буферизированые зоны (Previous и Additional), которые иногда нужны.

← →
DevilDevil © (2013-02-13 17:09) [37]

> Дмитрий С © (13.02.13 17:00) [34]

> добавь в бенч еще FlushFileBuffers перед закрытием и учитывай
> этот вызов во времени.

я в этом не разбираюсь
подкорректируй сам и вышли мне
или здесь положи

> DVM © (13.02.13 17:00) [33]

я чёт не понял. а в чём там ошибка то ?

> Jeer © (13.02.13 17:04) [35]

Спасибо!

P.S.
сдаётся мне либо не нужно использовать DoubleThreading, либо я его как-то неправильно реализую.

← →
dmk © (2013-02-13 17:13) [38]

Читалка на SSD Intel-X25
1) "Standard TStringList reader"... 4165ms
2) "Fast buffering reader"... 468ms
3) "Using CachedFileReader"... 375ms
4) "Using CachedFileReader+DoubleThreading"... 374ms

Читалка на HDD ST31500341AS
1) "Standard TStringList reader"... 4165ms
2) "Fast buffering reader"... 453ms
3) "Using CachedFileReader"... 374ms
4) "Using CachedFileReader+DoubleThreading"... 375ms

Писалка на SSD Intel-X25
1.txt - "Simple CachedFileWriter"... 1186ms
comparing with correct file... binary equal.
2.txt - "Simple CachedFileWriter+DoubleThreading"... 1139ms
comparing with correct file... binary equal.
3.txt - "Fast CachedFileWriter"... 125ms
comparing with correct file... binary equal.
4.txt - "Fast CachedFileWriter+DoubleThreading"... 437ms
comparing with correct file... binary equal.

Писалка на HDD ST31500341AS
1.txt - "Simple CachedFileWriter"... 1185ms
comparing with correct file... binary equal.
2.txt - "Simple CachedFileWriter+DoubleThreading"... 1154ms
comparing with correct file... binary equal.
3.txt - "Fast CachedFileWriter"... 125ms
comparing with correct file... binary equal.
4.txt - "Fast CachedFileWriter+DoubleThreading"... 437ms
comparing with correct file... binary equal.

А если не видно разницы, зачем платить больше? :)
На самом деле SSD раза в 2 быстрее HDD в моем варианте.

← →
dmk © (2013-02-13 17:15) [39]

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

← →
DVM © (2013-02-13 17:19) [40]

> 1) принципиально различаются чтение и запись. У тебя насколько
> понял всё в одном

Да, в одном классе, разумеется

> 2) для файлов существуют отдельные "классы". Специально
> заточенные, чтобы больше не париться

У меня вообще нет привязки к источнику/приемнику данных, это декоратор.

> 3) у тебя насколько понял есть только Read() и Write().

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

> особенно если object хранится на стеке.

где то читал, что все уже в куче хранится.

← →
DevilDevil © (2013-02-13 17:19) [41]

> dmk ©

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

← →
DVM © (2013-02-13 17:21) [42]

> DevilDevil © (13.02.13 17:09) [37]

> я чёт не понял. а в чём там ошибка то ?

в том, что левой части нельзя присвоить правую :)

← →
DevilDevil © (2013-02-13 17:24) [43]

> DVM © (13.02.13 17:19) [40]

> не, не только, Flush, например, тоже есть, я и не ставил
> целью достичь максимума возможного, мне нужна была максимальная
> гибкость.

ну мне тоже нужна гибкость. Только вместо TStream используется TCustomCachedBuffer.

кстати нет особой сложности реализовать ридер или райтер, использующий TStream. Нужно лишь реализовать соответствующий калбек. Я прост не первый день борюсь за производительность, такой подход немного эффективней )

> где то читал, что все уже в куче хранится.

это наверное если New/Dispose использовать. У меня их нет. В бенчмарке - на стеке. А в дизассемблере - прямое обращение к переменным стека

← →
DevilDevil © (2013-02-13 17:26) [44]

> в том, что левой части нельзя присвоить правую :)

звучит как бред :)
разберись пожалуйста, почему XE2 ругается

← →
DVM © (2013-02-13 17:27) [45]

> > я чёт не понял. а в чём там ошибка то ?

вот здесь про записи, у тебя object, но разницы нету:

http://stackoverflow.com/questions/5484163/delphi-e2064-left-side-cannot-be-assigned-to-error-appeared-when-upgrading-a-p

← →
DVM © (2013-02-13 17:38) [46]

> DVM © (13.02.13 17:27) [45]

тьфу, не ту ссылку прислал, вот правильная:

http://stackoverflow.com/questions/6676083/using-for-in-sentence-and-compiler-error-e2064

← →
DevilDevil © (2013-02-13 17:39) [47]

> DVM © (13.02.13 17:27) [45]

with теперь не работает со структурами ?

← →
DVM © (2013-02-13 17:40) [48]

> with теперь не работает со структурами ?
>
>

не, смотри следующее мое сообщение

← →
DVM © (2013-02-13 17:42) [49]

> DevilDevil © (13.02.13 17:39) [47]

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

← →
DevilDevil © (2013-02-13 17:47) [50]

> DVM © (13.02.13 17:42) [49]

не радует меня такая фишка. бред
к тому же что, if (State =) не считается чтением ?

← →
DVM © (2013-02-13 17:48) [51]

> DevilDevil © (13.02.13 17:39) [47]

в твоем случае, можно вероятно как то так:

function FuncThreadFinalizing(Parameter: pointer): integer;
var
Obj: TCachedBufferThreadMemory;
begin
Obj := PCachedBufferThreadMemory(Parameter)^;
with Obj do
begin
if (State = STATE_DONE) then State := STATE_FINALIZE;
Result := State;
end;
end;

← →
Павиа (2013-02-13 18:09) [52]

Бред какойто.
1) Скорость измеряется в МБайт/с
2) Во вторых непонятно какой алгоритм записи тестируем.
3) Кто же тестирует без учёта кэша?
4) Зачем грузить систему вторым поток, если можно асинхронно писать?

Автору рано такое писать. Он ничего незнает и знать не хочет.

← →
Игорь Шевченко © (2013-02-13 19:43) [53]

Павиа (13.02.13 18:09) [52]

Это ты совсем не по теме наехал

← →
DevilDevil © (2013-02-13 19:49) [54]

> 3) Кто же тестирует без учёта кэша?
> 4) Зачем грузить систему вторым поток, если можно асинхронно писать?

исходники отрыты, милости прошу редактировать

← →
Sapersky (2013-02-13 21:32) [55]

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

Вот результаты чтения с кэшем и без (после /). Кэш сбрасывал утилитой RamMap (Empty standby list), также отключил Superfetch. Вообще лучше использовать FILE_FLAG_NO_BUFFERING в самом тесте, но там нужно спец. выранивание буферов и т.п.

1) "Standard TStringList reader"... 5437 / 6735ms
2) "Fast buffering reader"... 718ms / 1657ms
3) "Using CachedFileReader"... 563ms / 953ms
4) "Using CachedFileReader+DoubleThreading"... 859ms / 891ms

900 ms - близко к реальной максимальной скорости диска (100-120 мб/c).

Не очень понятно, что здесь делает многопоточность (по коду вникать лень). Теоретически с обычным HDD попытки одновременно читать из разных мест ничего не ускорят, на практике получилось чуть быстрее, но м.б. это погрешность.

DVM © (13.02.13 17:48) [51]
Obj там должен быть указателем, иначе модифицируется локальная копия.

← →
DevilDevil © (2013-02-13 21:48) [56]

> Sapersky (13.02.13 21:32) [55]

> Насчёт кэша Павиа прав

никто не спорит
я говорю - скажите что вставить, чтобы лучше тестировать

> Вообще лучше использовать FILE_FLAG_NO_BUFFERING

ok. Кстати. Будет ли негативно сказывать этот флаг, если файл кэшируется в ОС? Как узнать размер на который надо выравнивать ?

> Не очень понятно, что здесь делает многопоточность (по коду
> вникать лень).

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

← →
Игорь Шевченко © (2013-02-13 22:08) [57]

Sapersky (13.02.13 21:32) [55]

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

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

Например, вызов System.Write 32 раза по 32 байта будет выполняться медленнее, чем вызов Windows.WriteFile с заранее подготовленным буфером размером 32*32 байта, вне зависимости от того, какого размера буфер установлен для файла, куда пишется System.Write, здесь срабатывает скорость заполнения буфера.

512 вызовов Windows.WriteFile с порцией для записи в 1К будут медленнее, чем один вызов Windows.WriteFile с 512К буфером, потому что запросы на ввод-вывод будут генерироваться чаще в 512 раз.

1 вызов Windows.WriteFile с порцией для записи в 32М будет медленнее, чем 64 вызова Windows.WriteFile с 512К буфером, и т.д.

И наконец, на RAMDrive запись может быть медленнее при прочих равных, чем на HDD или на SSD, потому что драйвер сам по себе медленно обрабатывает запросы на ввод/вывод, как бы это не казалось странным.

Вывод простой - серебряной пули нет.

← →
DevilDevil © (2013-02-13 22:15) [58]

> Вывод простой - серебряной пули нет.

я заводил ветку здесь, опытным путём было определено, что оптимальный размер буфера - 256кб.

← →
Игорь Шевченко © (2013-02-13 22:30) [59]

unit Main; interface procedure Run; implementation uses Windows, SysUtils, DateUtils; const SFileData: AnsiString = "123456789012345678901234567890"#13#10; {$WARN SYMBOL_PLATFORM OFF} procedure RunWriteFileTest (const AFileName: string; ABufferSizeKBytes: Integer); function PrepareBuffer: PByte; var I, J: Integer; Worker: PByte; begin Result := PByte(AllocMem(ABufferSizeKBytes * 1024)); Worker := Result; for I := 1 to ABufferSizeKBytes do for J := 1 to 32 do begin Move(PAnsiChar(SFileData)^, Worker^, 32); Inc(Worker, 32); end; end; var Buf: PByte; I: Integer; BytesWritten: DWORD; F: THandle; begin // Buffered WriteFile, write 512M file using prepared buffer Buf := PrepareBuffer; try F := CreateFile(PChar(AFileName), GENERIC_WRITE, 0, nil, CREATE_NEW, 0, 0); Win32Check(F <> INVALID_HANDLE_VALUE); try for I := 1 to (512 * 1024) div ABufferSizeKBytes do Win32Check(WriteFile(F, Buf^, ABufferSizeKBytes * 1024, BytesWritten, nil) and (BytesWritten = DWORD(ABufferSizeKBytes * 1024))); finally CloseHandle(F); end; finally FreeMem(Buf); end; DeleteFile(AFileName); end; procedure RunWriteTest (const AFileName: string; ABufferSizeKBytes: Integer); var F: TextFile; I, J: Integer; Buf: Pointer; begin // Write 512M file using writeln by portions of 30bytes + CRLF, using pre-allocated buffer Buf := AllocMem(ABufferSizeKBytes * 1024); try AssignFile(F, AFileName); Rewrite(F); SetTextBuf(F, Buf^, ABufferSizeKBytes*1024); try for I := 1 to 512 * 1024 do for J := 1 to 32 do write(F, SFileData); finally CloseFile(F); end; DeleteFile(AFileName) finally FreeMem(Buf); end; end; procedure Run; const BufferSizes: array[1..17] of Integer = ( 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536); var StartTime, ElapsedTime: TDateTime; Seconds: Integer; I, K, Times: Integer; begin Times := 10; for K in BufferSizes do begin StartTime := Now; for I := 1 to Times do RunWriteFileTest (Format("%dK.txt", [K]), K); ElapsedTime := Now - StartTime; Seconds := SecondOf(ElapsedTime); writeln(Format("%d seconds to write 512M (WriteFile using %dK buffer) %d times", [Seconds, K, Times])); end; for K in BufferSizes do begin StartTime := Now; for I := 1 to Times do RunWriteTest (Format("%dK.txt", [K]), K); ElapsedTime := Now - StartTime; Seconds := SecondOf(ElapsedTime); writeln(Format("%d seconds to write 512M (Write using %dK buffer) %d times", [Seconds, K, Times])); end; end; end.

14 seconds to write 512M (WriteFile using 1K buffer) 10 times 10 seconds to write 512M (WriteFile using 2K buffer) 10 times 7 seconds to write 512M (WriteFile using 4K buffer) 10 times 4 seconds to write 512M (WriteFile using 8K buffer) 10 times 3 seconds to write 512M (WriteFile using 16K buffer) 10 times 2 seconds to write 512M (WriteFile using 32K buffer) 10 times 2 seconds to write 512M (WriteFile using 64K buffer) 10 times 2 seconds to write 512M (WriteFile using 128K buffer) 10 times 2 seconds to write 512M (WriteFile using 256K buffer) 10 times 2 seconds to write 512M (WriteFile using 512K buffer) 10 times 2 seconds to write 512M (WriteFile using 1024K buffer) 10 times 2 seconds to write 512M (WriteFile using 2048K buffer) 10 times 2 seconds to write 512M (WriteFile using 4096K buffer) 10 times 2 seconds to write 512M (WriteFile using 8192K buffer) 10 times 3 seconds to write 512M (WriteFile using 16384K buffer) 10 times 22 seconds to write 512M (WriteFile using 32768K buffer) 10 times 32 seconds to write 512M (WriteFile using 65536K buffer) 10 times 24 seconds to write 512M (Write using 1K buffer) 10 times 20 seconds to write 512M (Write using 2K buffer) 10 times 19 seconds to write 512M (Write using 4K buffer) 10 times 16 seconds to write 512M (Write using 8K buffer) 10 times 14 seconds to write 512M (Write using 16K buffer) 10 times 13 seconds to write 512M (Write using 32K buffer) 10 times 13 seconds to write 512M (Write using 64K buffer) 10 times 13 seconds to write 512M (Write using 128K buffer) 10 times 12 seconds to write 512M (Write using 256K buffer) 10 times 12 seconds to write 512M (Write using 512K buffer) 10 times 12 seconds to write 512M (Write using 1024K buffer) 10 times 12 seconds to write 512M (Write using 2048K buffer) 10 times 12 seconds to write 512M (Write using 4096K buffer) 10 times 13 seconds to write 512M (Write using 8192K buffer) 10 times 13 seconds to write 512M (Write using 16384K buffer) 10 times 33 seconds to write 512M (Write using 32768K buffer) 10 times 44 seconds to write 512M (Write using 65536K buffer) 10 times

HDD: ST2000DL003

← →
DevilDevil © (2013-02-14 00:25) [60]

> Игорь Шевченко © (13.02.13 22:30) [59]

хороший тест
но
1) обычно время мериют миллисекундами. Самый плохой способ GetTockCount. Но он лучше чем Now

2) что-то не совсем верится. За 2 секунды записать 5Гб

3) что если использовать FILE_FLAG_NO_BUFFERING

4) надо бы выложить сразу exe-шник, чтобы можно было потестить

← →
Игорь Шевченко © (2013-02-14 00:34) [61]

DevilDevil © (14.02.13 00:25) [60]

> 1) обычно время мериют миллисекундами. Самый плохой способ
> GetTockCount. Но он лучше чем Now

Обычно меряют rdtsc.

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

> 2) что-то не совсем верится. За 2 секунды записать 5Гб

Вот это меня и смущает. Менеджер кэша работает быстро, но чтобы настолько - это странно.

> 4) надо бы выложить сразу exe-шник, чтобы можно было потестить

Выкладываю dpr, можно собрать, там сложностей нет.

program FileWriteSpeed; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, Main in "Main.pas"; begin try Run; except on E: Exception do Writeln(E.ClassName, ": ", E.Message); end; end.

> 3) что если использовать FILE_FLAG_NO_BUFFERING

Нецелесообразно

← →
Игорь Шевченко © (2013-02-14 00:47) [62]

Все эти тесты целесообразно проводить, наблюдая выдачу утилит от Sysinternals и параллельно запуская профайлер, тот же AQTime, чтобы было видно, какая часть времени на что тратится и в какие действия системы (в частности, в какие IRP) выливаются те или иные конструкции прикладной программы или вызовы API.

← →
DevilDevil © (2013-02-14 09:28) [63]

> Игорь Шевченко © (14.02.13 00:47) [62]
> Все эти тесты целесообразно проводить, наблюдая выдачу утилит
> от Sysinternals и параллельно запуская профайлер, тот же
> AQTime, чтобы было видно, какая часть времени на что тратится
> и в какие действия системы (в частности, в какие IRP) выливаются
> те или иные конструкции прикладной программы или вызовы
> API.

Что я могу сказать. В плане заполнения и чтения буфера, CachedBuffers не имеет равных, как минимум среди более-менее стандартных средств. Потому что он построен так, чтобы иметь максимально быстрый доступ к буферу.

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

(нужно понимать, как лучше всего читать с диска. и писать на диск. А так же понять, как эту эффективность можно замерить)

← →
DVM © (2013-02-14 10:21) [64]

> Sapersky (13.02.13 21:32) [55]

> DVM © (13.02.13 17:48) [51]
> Obj там должен быть указателем, иначе модифицируется локальная
> копия.

Да, действительно:

function FuncThreadFinalizing(Parameter: pointer): integer; var Obj: PCachedBufferThreadMemory; begin Obj := PCachedBufferThreadMemory(Parameter); with Obj^ do begin if (State = STATE_DONE) then State := STATE_FINALIZE; Result := State; end; end;

Такая конструкция компилятор устраивает, как оно реально будет работать не проверял.

← →
DevilDevil © (2013-02-14 12:24) [65]

господа, давайте активизироваться с идеями
максимально производительного доступа к диску
и способами замера такой производительности

← →
Владислав © (2013-02-14 13:23) [66]

> Игорь Шевченко © (14.02.13 00:34) [61]
> > 2) что-то не совсем верится. За 2 секунды записать 5Гб
>
>
> Вот это меня и смущает. Менеджер кэша работает быстро, но
> чтобы настолько - это странно.

Flush не хватает.
А еще SecondOf возвращает количество секунд от 0 до 59.

Немного переделал твой вариант. Вот что получилось на моем HDD ST3500418AS.

С Flush 6443 ms to write 512M (WriteFile using 1K buffer) 1 times 5210 ms to write 512M (WriteFile using 2K buffer) 1 times 5460 ms to write 512M (WriteFile using 4K buffer) 1 times 5101 ms to write 512M (WriteFile using 8K buffer) 1 times 4743 ms to write 512M (WriteFile using 16K buffer) 1 times 4602 ms to write 512M (WriteFile using 32K buffer) 1 times 4571 ms to write 512M (WriteFile using 64K buffer) 1 times 4742 ms to write 512M (WriteFile using 128K buffer) 1 times 4727 ms to write 512M (WriteFile using 256K buffer) 1 times 4664 ms to write 512M (WriteFile using 512K buffer) 1 times 4634 ms to write 512M (WriteFile using 1024K buffer) 1 times 4695 ms to write 512M (WriteFile using 2048K buffer) 1 times 4821 ms to write 512M (WriteFile using 4096K buffer) 1 times 4960 ms to write 512M (WriteFile using 8192K buffer) 1 times 4868 ms to write 512M (WriteFile using 16384K buffer) 1 times 4914 ms to write 512M (WriteFile using 32768K buffer) 1 times 4773 ms to write 512M (WriteFile using 65536K buffer) 1 times 154441 ms to write 512M (no buf WriteFile using 4K buffer) 1 times 79701 ms to write 512M (no buf WriteFile using 8K buffer) 1 times 41559 ms to write 512M (no buf WriteFile using 16K buffer) 1 times 23057 ms to write 512M (no buf WriteFile using 32K buffer) 1 times 16146 ms to write 512M (no buf WriteFile using 64K buffer) 1 times 12184 ms to write 512M (no buf WriteFile using 128K buffer) 1 times 10639 ms to write 512M (no buf WriteFile using 256K buffer) 1 times 9906 ms to write 512M (no buf WriteFile using 512K buffer) 1 times 8720 ms to write 512M (no buf WriteFile using 1024K buffer) 1 times 8253 ms to write 512M (no buf WriteFile using 2048K buffer) 1 times 5990 ms to write 512M (no buf WriteFile using 4096K buffer) 1 times 5788 ms to write 512M (no buf WriteFile using 8192K buffer) 1 times 4758 ms to write 512M (no buf WriteFile using 16384K buffer) 1 times 4976 ms to write 512M (no buf WriteFile using 32768K buffer) 1 times 4712 ms to write 512M (no buf WriteFile using 65536K buffer) 1 times 5054 ms to write 512M (no buf WriteFile using 131072K buffer) 1 times 4774 ms to write 512M (no buf WriteFile using 262144K buffer) 1 times 4820 ms to write 512M (no buf WriteFile using 524288K buffer) 1 times 74990 ms to write 512M (Write using 1K buffer) 1 times 73320 ms to write 512M (Write using 2K buffer) 1 times 73695 ms to write 512M (Write using 4K buffer) 1 times 73867 ms to write 512M (Write using 8K buffer) 1 times 74240 ms to write 512M (Write using 16K buffer) 1 times 73898 ms to write 512M (Write using 32K buffer) 1 times 74116 ms to write 512M (Write using 64K buffer) 1 times 73758 ms to write 512M (Write using 128K buffer) 1 times 74287 ms to write 512M (Write using 256K buffer) 1 times 74101 ms to write 512M (Write using 512K buffer) 1 times 74334 ms to write 512M (Write using 1024K buffer) 1 times Без Flush 2746 ms to write 512M (WriteFile using 1K buffer) 1 times 1170 ms to write 512M (WriteFile using 2K buffer) 1 times 920 ms to write 512M (WriteFile using 4K buffer) 1 times 406 ms to write 512M (WriteFile using 8K buffer) 1 times 312 ms to write 512M (WriteFile using 16K buffer) 1 times 577 ms to write 512M (WriteFile using 32K buffer) 1 times 250 ms to write 512M (WriteFile using 64K buffer) 1 times 234 ms to write 512M (WriteFile using 128K buffer) 1 times 686 ms to write 512M (WriteFile using 256K buffer) 1 times 234 ms to write 512M (WriteFile using 512K buffer) 1 times 234 ms to write 512M (WriteFile using 1024K buffer) 1 times 1514 ms to write 512M (WriteFile using 2048K buffer) 1 times 265 ms to write 512M (WriteFile using 4096K buffer) 1 times 296 ms to write 512M (WriteFile using 8192K buffer) 1 times 531 ms to write 512M (WriteFile using 16384K buffer) 1 times 2465 ms to write 512M (WriteFile using 32768K buffer) 1 times 3229 ms to write 512M (WriteFile using 65536K buffer) 1 times 150978 ms to write 512M (no buf WriteFile using 4K buffer) 1 times 78062 ms to write 512M (no buf WriteFile using 8K buffer) 1 times 40779 ms to write 512M (no buf WriteFile using 16K buffer) 1 times 23385 ms to write 512M (no buf WriteFile using 32K buffer) 1 times 15647 ms to write 512M (no buf WriteFile using 64K buffer) 1 times 12324 ms to write 512M (no buf WriteFile using 128K buffer) 1 times 9578 ms to write 512M (no buf WriteFile using 256K buffer) 1 times 9579 ms to write 512M (no buf WriteFile using 512K buffer) 1 times 8673 ms to write 512M (no buf WriteFile using 1024K buffer) 1 times 8331 ms to write 512M (no buf WriteFile using 2048K buffer) 1 times 6099 ms to write 512M (no buf WriteFile using 4096K buffer) 1 times 5226 ms to write 512M (no buf WriteFile using 8192K buffer) 1 times 5055 ms to write 512M (no buf WriteFile using 16384K buffer) 1 times 4664 ms to write 512M (no buf WriteFile using 32768K buffer) 1 times 4415 ms to write 512M (no buf WriteFile using 65536K buffer) 1 times 4649 ms to write 512M (no buf WriteFile using 131072K buffer) 1 times 4758 ms to write 512M (no buf WriteFile using 262144K buffer) 1 times 4181 ms to write 512M (no buf WriteFile using 524288K buffer) 1 times 75270 ms to write 512M (Write using 1K buffer) 1 times 74335 ms to write 512M (Write using 2K buffer) 1 times 73757 ms to write 512M (Write using 4K buffer) 1 times 73944 ms to write 512M (Write using 8K buffer) 1 times 74116 ms to write 512M (Write using 16K buffer) 1 times 73867 ms to write 512M (Write using 32K buffer) 1 times 73664 ms to write 512M (Write using 64K buffer) 1 times

← →
Владислав © (2013-02-14 13:27) [67]

"no buf WriteFile using " это с флагом FILE_FLAG_NO_BUFFERING.

> Игорь Шевченко © (14.02.13 00:34) [61]

Интересно. Твой тест:
3 seconds to write 512M (WriteFile using 16384K buffer) 10 times
22 seconds to write 512M (WriteFile using 32768K buffer) 10 times

Мой тест:
531 ms to write 512M (WriteFile using 16384K buffer) 1 times
2465 ms to write 512M (WriteFile using 32768K buffer) 1 times

У тебя тоже кэш диска 16 МБ? :)

← →
DevilDevil © (2013-02-14 15:09) [68]

> Владислав © (14.02.13 13:23) [66]

> 4571 ms to write 512M (WriteFile using 64K buffer) 1 times

получается оптимальный размер для записи 64кб.
какая у тебя ОС кстати ?

похоже это размер сектора
можешь потестировать с FILE_FLAG_NO_BUFFERING и другими указанными тобой флагами ?

← →
Игорь Шевченко © (2013-02-14 18:45) [69]

Продолжаем поиски серебряной пули...
В оба варианта моего проекта добавлен вызов FlushFileBuffers, чтобы время доступа к диску было более приемлемым. Измерение скорости выполнено в миллисекундах.

Результаты:
HDD ST3000VX000

61671 milliseconds to write 512M (WriteFile using 1K buffer and flush) 10 times average speed is 83,02 Mb per second 56515 milliseconds to write 512M (WriteFile using 2K buffer and flush) 10 times average speed is 90,60 Mb per second 53359 milliseconds to write 512M (WriteFile using 4K buffer and flush) 10 times average speed is 95,95 Mb per second 51989 milliseconds to write 512M (WriteFile using 8K buffer and flush) 10 times average speed is 98,48 Mb per second 51359 milliseconds to write 512M (WriteFile using 16K buffer and flush) 10 times average speed is 99,69 Mb per second 49785 milliseconds to write 512M (WriteFile using 32K buffer and flush) 10 times average speed is 102,84 Mb per second 47507 milliseconds to write 512M (WriteFile using 64K buffer and flush) 10 times average speed is 107,77 Mb per second 41578 milliseconds to write 512M (WriteFile using 128K buffer and flush) 10 times average speed is 123,14 Mb per second 38431 milliseconds to write 512M (WriteFile using 256K buffer and flush) 10 times average speed is 133,23 Mb per second 37517 milliseconds to write 512M (WriteFile using 512K buffer and flush) 10 times average speed is 136,47 Mb per second 36331 milliseconds to write 512M (WriteFile using 1024K buffer and flush) 10 times average speed is 140,93 Mb per second 35018 milliseconds to write 512M (WriteFile using 2048K buffer and flush) 10 times average speed is 146,21 Mb per second 34068 milliseconds to write 512M (WriteFile using 4096K buffer and flush) 10 times average speed is 150,29 Mb per second 33748 milliseconds to write 512M (WriteFile using 8192K buffer and flush) 10 times average speed is 151,71 Mb per second 33334 milliseconds to write 512M (WriteFile using 16384K buffer and flush) 10 times average speed is 153,60 Mb per second 36456 milliseconds to write 512M (WriteFile using 32768K buffer and flush) 10 times average speed is 140,44 Mb per second 34382 milliseconds to write 512M (WriteFile using 65536K buffer and flush) 10 times average speed is 148,92 Mb per second 70368 milliseconds to write 512M (Write using 1K buffer and flush) 10 times average speed is 72,76 Mb per second 65331 milliseconds to write 512M (Write using 2K buffer and flush) 10 times average speed is 78,37 Mb per second 63093 milliseconds to write 512M (Write using 4K buffer and flush) 10 times average speed is 81,15 Mb per second 61048 milliseconds to write 512M (Write using 8K buffer and flush) 10 times average speed is 83,87 Mb per second 60412 milliseconds to write 512M (Write using 16K buffer and flush) 10 times average speed is 84,75 Mb per second 59725 milliseconds to write 512M (Write using 32K buffer and flush) 10 times average speed is 85,73 Mb per second 55658 milliseconds to write 512M (Write using 64K buffer and flush) 10 times average speed is 91,99 Mb per second 51288 milliseconds to write 512M (Write using 128K buffer and flush) 10 times average speed is 99,83 Mb per second 49588 milliseconds to write 512M (Write using 256K buffer and flush) 10 times average speed is 103,25 Mb per second 47676 milliseconds to write 512M (Write using 512K buffer and flush) 10 times average speed is 107,39 Mb per second 46793 milliseconds to write 512M (Write using 1024K buffer and flush) 10 times average speed is 109,42 Mb per second 44979 milliseconds to write 512M (Write using 2048K buffer and flush) 10 times average speed is 113,83 Mb per second 43733 milliseconds to write 512M (Write using 4096K buffer and flush) 10 times average speed is 117,07 Mb per second 44161 milliseconds to write 512M (Write using 8192K buffer and flush) 10 times average speed is 115,94 Mb per second 43346 milliseconds to write 512M (Write using 16384K buffer and flush) 10 times average speed is 118,12 Mb per second 48728 milliseconds to write 512M (Write using 32768K buffer and flush) 10 times average speed is 105,07 Mb per second 45770 milliseconds to write 512M (Write using 65536K buffer and flush) 10 times average speed is 111,86 Mb per second

← →
Игорь Шевченко © (2013-02-14 18:47) [70]

SSD INTEL_SSDSA2M160G2GC

16382 milliseconds to write 512M (WriteFile using 1K buffer and flush) 1 times
average speed is 31,25 Mb per second
12268 milliseconds to write 512M (WriteFile using 2K buffer and flush) 1 times
average speed is 41,73 Mb per second
8902 milliseconds to write 512M (WriteFile using 4K buffer and flush) 1 times
average speed is 57,52 Mb per second
7215 milliseconds to write 512M (WriteFile using 8K buffer and flush) 1 times
average speed is 70,96 Mb per second
9802 milliseconds to write 512M (WriteFile using 16K buffer and flush) 1 times
average speed is 52,23 Mb per second
5875 milliseconds to write 512M (WriteFile using 32K buffer and flush) 1 times
average speed is 87,15 Mb per second
7754 milliseconds to write 512M (WriteFile using 64K buffer and flush) 1 times
average speed is 66,03 Mb per second
10311 milliseconds to write 512M (WriteFile using 128K buffer and flush) 1 times
average speed is 49,66 Mb per second
5840 milliseconds to write 512M (WriteFile using 256K buffer and flush) 1 times
average speed is 87,67 Mb per second
7652 milliseconds to write 512M (WriteFile using 512K buffer and flush) 1 times
average speed is 66,91 Mb per second
5460 milliseconds to write 512M (WriteFile using 1024K buffer and flush) 1 times
average speed is 93,77 Mb per second
5731 milliseconds to write 512M (WriteFile using 2048K buffer and flush) 1 times
average speed is 89,34 Mb per second
7762 milliseconds to write 512M (WriteFile using 4096K buffer and flush) 1 times
average speed is 65,96 Mb per second
5103 milliseconds to write 512M (WriteFile using 8192K buffer and flush) 1 times
average speed is 100,33 Mb per second
7576 milliseconds to write 512M (WriteFile using 16384K buffer and flush) 1 times
average speed is 67,58 Mb per second
5261 milliseconds to write 512M (WriteFile using 32768K buffer and flush) 1 times
average speed is 97,32 Mb per second
7899 milliseconds to write 512M (WriteFile using 65536K buffer and flush) 1 times
average speed is 64,82 Mb per second

18333 milliseconds to write 512M (Write using 1K buffer and flush) 1 times
average speed is 27,93 Mb per second
10755 milliseconds to write 512M (Write using 2K buffer and flush) 1 times
average speed is 47,61 Mb per second
9397 milliseconds to write 512M (Write using 4K buffer and flush) 1 times
average speed is 54,49 Mb per second
10584 milliseconds to write 512M (Write using 8K buffer and flush) 1 times
average speed is 48,37 Mb per second
8517 milliseconds to write 512M (Write using 16K buffer and flush) 1 times
average speed is 60,12 Mb per second
7000 milliseconds to write 512M (Write using 32K buffer and flush) 1 times
average speed is 73,14 Mb per second
8749 milliseconds to write 512M (Write using 64K buffer and flush) 1 times
average speed is 58,52 Mb per second
6726 milliseconds to write 512M (Write using 128K buffer and flush) 1 times
average speed is 76,12 Mb per second
8092 milliseconds to write 512M (Write using 256K buffer and flush) 1 times
average speed is 63,27 Mb per second
7304 milliseconds to write 512M (Write using 512K buffer and flush) 1 times
average speed is 70,10 Mb per second
6830 milliseconds to write 512M (Write using 1024K buffer and flush) 1 times
average speed is 74,96 Mb per second
6324 milliseconds to write 512M (Write using 2048K buffer and flush) 1 times
average speed is 80,96 Mb per second
8997 milliseconds to write 512M (Write using 4096K buffer and flush) 1 times
average speed is 56,91 Mb per second
6333 milliseconds to write 512M (Write using 8192K buffer and flush) 1 times
average speed is 80,85 Mb per second
5914 milliseconds to write 512M (Write using 16384K buffer and flush) 1 times
average speed is 86,57 Mb per second
6776 milliseconds to write 512M (Write using 32768K buffer and flush) 1 times
average speed is 75,56 Mb per second
6412 milliseconds to write 512M (Write using 65536K buffer and flush) 1 times
average speed is 79,85 Mb per second

← →
Игорь Шевченко © (2013-02-14 18:49) [71]

Изменения в коде:

unit ElapsedTimer; interface type TElapsedTimer = class private FStarted: Boolean; FPerformanceFrequency: int64; FStartCounter: int64; FStopCounter: int64; function GetElapsedMilliseconds: Integer; public constructor Create; procedure Start; procedure Stop; property ElapsedMilliseconds: Integer read GetElapsedMilliseconds; end; implementation uses Windows; { TElaspedTimer } constructor TElapsedTimer.Create; begin QueryPerformanceFrequency(FPerformanceFrequency); end; function TElapsedTimer.GetElapsedMilliseconds: Integer; begin Result := (FStopCounter - FStartCounter) * 1000 div FPerformanceFrequency; end; procedure TElapsedTimer.Start; begin FStarted := True; QueryPerformanceCounter(FStartCounter); end; procedure TElapsedTimer.Stop; begin Assert(FStarted); QueryPerformanceCounter(FStopCounter); FStarted := False; end; end.

unit Main; interface procedure Run; implementation uses Windows, SysUtils, ElapsedTimer; const SFileData: AnsiString = "123456789012345678901234567890"#13#10; {$WARN SYMBOL_PLATFORM OFF} procedure RunWriteFileTest(const AFileName: string; ABufferSizeKBytes: Integer); function PrepareBuffer: PByte; var I, J: Integer; Worker: PByte; begin Result := PByte(AllocMem(ABufferSizeKBytes * 1024)); Worker := Result; for I := 1 to ABufferSizeKBytes do for J := 1 to 32 do begin Move(PAnsiChar(SFileData)^, Worker^, 32); Inc(Worker, 32); end; end; var Buf: PByte; I: Integer; BytesWritten: DWORD; F: THandle; begin // Buffered WriteFile, write 512M file using prepared buffer Buf := PrepareBuffer; try F := CreateFile(PChar(AFileName), GENERIC_WRITE, 0, nil, CREATE_NEW, 0, 0); Win32Check(F <> INVALID_HANDLE_VALUE); try for I := 1 to (512 * 1024) div ABufferSizeKBytes do Win32Check(WriteFile(F, Buf^, ABufferSizeKBytes * 1024, BytesWritten, nil) and (BytesWritten = DWORD(ABufferSizeKBytes * 1024))); finally FlushFileBuffers(F); CloseHandle(F); end; finally FreeMem(Buf); end; DeleteFile(AFileName); end; procedure RunWriteTest(const AFileName: string; ABufferSizeKBytes: Integer); var F: TextFile; I, J: Integer; Buf: Pointer; begin // Write 512M file using writeln by portions of 30bytes + CRLF, using pre-allocated buffer Buf := AllocMem(ABufferSizeKBytes * 1024); try AssignFile(F, AFileName); Rewrite(F); SetTextBuf(F, Buf^, ABufferSizeKBytes * 1024); try for I := 1 to 512 * 1024 do for J := 1 to 32 do write(F, SFileData); finally Flush(F); FlushFileBuffers(TTextRec(F).Handle); CloseFile(F); end; DeleteFile(AFileName) finally FreeMem(Buf); end; end; procedure Run; const BufferSizes: array [1 .. 17] of Integer = (1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536); var Timer: TElapsedTimer; I, K, Times: Integer; begin Timer := TElapsedTimer.Create; Times := 10; for K in BufferSizes do begin Timer.Start; for I := 1 to Times do RunWriteFileTest(Format("%dK.txt", [K]), K); Timer.Stop; writeln(Format ("%d milliseconds to write 512M (WriteFile using %dK buffer and flush) %d times", [Timer.ElapsedMilliseconds, K, Times])); if Timer.ElapsedMilliseconds > 0 then writeln(Format("average speed is %f Mb per second", [512*Times*1000 / Timer.ElapsedMilliseconds])); end; for K in BufferSizes do begin Timer.Start; for I := 1 to Times do RunWriteTest(Format("%dK.txt", [K]), K); Timer.Stop; writeln(Format ("%d milliseconds to write 512M (Write using %dK buffer and flush) %d times", [Timer.ElapsedMilliseconds, K, Times])); if Timer.ElapsedMilliseconds > 0 then writeln(Format("average speed is %f Mb per second", [512*Times*1000 / Timer.ElapsedMilliseconds])); end; Timer.Free; end; end.

← →
Игорь Шевченко © (2013-02-14 18:52) [72]

ну и выводы: буферизация да, в целом улучшает общее время.

Никаких
волшебных комбинаций настроек, скрываемых от общественности мудрецами из Microsoft не существует.

Надо улучшать производительность бизнес-задач в целом, а не рассматривать отдельные этапы.

← →
DevilDevil © (2013-02-14 22:33) [73]

> Надо улучшать производительность бизнес-задач в целом, а
> не рассматривать отдельные этапы.

дисковые операции обычно самые затратные по времени

> Никаких волшебных комбинаций настроек, скрываемых от общественности
> мудрецами из Microsoft не существует.

так а ты же так и не попробовал FILE_FLAG_NO_BUFFERING, FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_WRITE_THROUGH

> QueryPerformanceCounter

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

> F: TextFile;

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

← →
Игорь Шевченко © (2013-02-14 22:39) [74]

DevilDevil © (14.02.13 22:33) [73]

> так а ты же так и не попробовал FILE_FLAG_NO_BUFFERING,
> FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_WRITE_THROUGH

Нецелесообразно. Очевидно, что с кэшем быстрее, чем без него.

← →
DevilDevil © (2013-02-14 22:53) [75]

> FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_WRITE_THROUGH

мне кажется это вообще никак негативно не влияет на кеш, скорее наоборот позитивно

> FILE_FLAG_NO_BUFFERING

надо посмотреть как работает. в режиме кеша и в режиме flush
я думаю если буфер выровнен, и если есть такой особый режим - должны быть какие-то оптимизации

----------
я у себя не тестирую по двум причинам:
во-первых, у меня старое оборудование: и дома, и на работе. Т.е. не получу актуальных цифр
во-вторых, я не доверяю себе тестирование. Особенно когда являюсь разработчиком

← →
Игорь Шевченко © (2013-02-14 23:26) [76]

то же самое, только без кэша:

HDD ST3000VX000 (64М внутренний кэш)

41517 milliseconds to write 512M (WriteFile using 4K buffer, bypassing cache) average speed is 12,33 Mb per second 21815 milliseconds to write 512M (WriteFile using 8K buffer, bypassing cache) average speed is 23,47 Mb per second 12224 milliseconds to write 512M (WriteFile using 16K buffer, bypassing cache) average speed is 41,88 Mb per second 7415 milliseconds to write 512M (WriteFile using 32K buffer, bypassing cache) average speed is 69,05 Mb per second 5157 milliseconds to write 512M (WriteFile using 64K buffer, bypassing cache) average speed is 99,28 Mb per second 4685 milliseconds to write 512M (WriteFile using 128K buffer, bypassing cache) average speed is 109,28 Mb per second 4915 milliseconds to write 512M (WriteFile using 256K buffer, bypassing cache) average speed is 104,17 Mb per second 4832 milliseconds to write 512M (WriteFile using 512K buffer, bypassing cache) average speed is 105,96 Mb per second 4874 milliseconds to write 512M (WriteFile using 1024K buffer, bypassing cache) average speed is 105,05 Mb per second 6158 milliseconds to write 512M (WriteFile using 2048K buffer, bypassing cache) average speed is 83,14 Mb per second 5180 milliseconds to write 512M (WriteFile using 4096K buffer, bypassing cache) average speed is 98,84 Mb per second 3807 milliseconds to write 512M (WriteFile using 8192K buffer, bypassing cache) average speed is 134,49 Mb per second 3547 milliseconds to write 512M (WriteFile using 16384K buffer, bypassing cache) average speed is 144,35 Mb per second 3505 milliseconds to write 512M (WriteFile using 32768K buffer, bypassing cache) average speed is 146,08 Mb per second 3066 milliseconds to write 512M (WriteFile using 65536K buffer, bypassing cache) average speed is 166,99 Mb per second 3210 milliseconds to write 512M (WriteFile using 131072K buffer, bypassing cache) average speed is 159,50 Mb per second

SSD

31649 milliseconds to write 512M (WriteFile using 4K buffer, bypassing cache) average speed is 16,18 Mb per second 23655 milliseconds to write 512M (WriteFile using 8K buffer, bypassing cache) average speed is 21,64 Mb per second 16716 milliseconds to write 512M (WriteFile using 16K buffer, bypassing cache) average speed is 30,63 Mb per second 13769 milliseconds to write 512M (WriteFile using 32K buffer, bypassing cache) average speed is 37,18 Mb per second 10789 milliseconds to write 512M (WriteFile using 64K buffer, bypassing cache) average speed is 47,46 Mb per second 9882 milliseconds to write 512M (WriteFile using 128K buffer, bypassing cache) average speed is 51,81 Mb per second 8814 milliseconds to write 512M (WriteFile using 256K buffer, bypassing cache) average speed is 58,09 Mb per second 8338 milliseconds to write 512M (WriteFile using 512K buffer, bypassing cache) average speed is 61,41 Mb per second 7929 milliseconds to write 512M (WriteFile using 1024K buffer, bypassing cache) average speed is 64,57 Mb per second 8363 milliseconds to write 512M (WriteFile using 2048K buffer, bypassing cache) average speed is 61,22 Mb per second 8172 milliseconds to write 512M (WriteFile using 4096K buffer, bypassing cache) average speed is 62,65 Mb per second 4830 milliseconds to write 512M (WriteFile using 8192K buffer, bypassing cache) average speed is 106,00 Mb per second 9245 milliseconds to write 512M (WriteFile using 16384K buffer, bypassing cache) average speed is 55,38 Mb per second 4934 milliseconds to write 512M (WriteFile using 32768K buffer, bypassing cache) average speed is 103,77 Mb per second 7711 milliseconds to write 512M (WriteFile using 65536K buffer, bypassing cache) average speed is 66,40 Mb per second 6501 milliseconds to write 512M (WriteFile using 131072K buffer, bypassing cache) average speed is 78,76 Mb per second

Видно, что SSD с мелкими порциями быстрее справляется

← →
Игорь Шевченко © (2013-02-14 23:28) [77]

код

procedure RunWriteFileNoCacheTest(const AFileName: string; ABufferSizeKBytes: Integer); // Ensure allocated resgion is page-boundary alighed function PrepareBuffer: PByte; var I, J: Integer; Worker: PByte; begin Result := PByte(VirtualAlloc(nil, ABufferSizeKBytes * 1024, MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE)); Worker := Result; for I := 1 to ABufferSizeKBytes do for J := 1 to 32 do begin Move(PAnsiChar(SFileData)^, Worker^, 32); Inc(Worker, 32); end; end; var Buf: PByte; I: Integer; BytesWritten: DWORD; F: THandle; begin // Unbuffered WriteFile, write 512M file using prepared buffer Buf := PrepareBuffer; try F := CreateFile(PChar(AFileName), GENERIC_WRITE, 0, nil, CREATE_NEW, FILE_FLAG_NO_BUFFERING or FILE_FLAG_WRITE_THROUGH, 0); Win32Check(F <> INVALID_HANDLE_VALUE); try for I := 1 to (512 * 1024) div ABufferSizeKBytes do Win32Check(WriteFile(F, Buf^, ABufferSizeKBytes * 1024, BytesWritten, nil) and (BytesWritten = DWORD(ABufferSizeKBytes * 1024))); finally CloseHandle(F); end; finally VirtualFree(Buf, ABufferSizeKBytes * 1024, MEM_DECOMMIT or MEM_RELEASE); end; DeleteFile(AFileName); end;

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

← →
DevilDevil © (2013-02-14 23:39) [78]

> Игорь Шевченко © (14.02.13 23:28) [77]

так а ты же вроде не выравниваешь буфер на границу сектора О_о?
я у себя попробовал с выравнивание на 4кб и FILE_FLAG_NO_BUFFERING - у меня были ошибки с записью, вроде FileWrite возвращает не то значение

← →
Игорь Шевченко © (2013-02-14 23:52) [79]

> так а ты же вроде не выравниваешь буфер на границу сектора
> О_о?

> VirtualAlloc(nil, ABufferSizeKBytes * 1024,
> MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE));

http://msdn.microsoft.com/ru-ru/library/windows/desktop/cc644950(v=vs.85).aspx

← →
Sapersky (2013-02-15 00:21) [80]

говорят замер времени таким образом не совсем точный на многоядерных процессорах

Я читал, что в Висте/7 пофиксили, так что сейчас уже не особо актуально. Да и глюки были только со старыми AthlonX2, вроде.

FILE_FLAG_NO_BUFFERING - надо посмотреть как работает

Под "лучше использовать FILE_FLAG_NO_BUFFERING" я подразумевал - для теста, чтобы не сбрасывать кэш вручную. И скорее для чтения, чем для записи, на чтении больше вероятность, что кэш не сработает.

Запись (или чтение) на диск - достаточно затратная операция. Причём в этот момент проц почти не грузится, а мы тупо ждём работы HDD. Для повышения производительности я попробовал реализовать двойной буфер. Пока один буфер используется нами, второй взаимодействует с диском в дополнительном потоке.

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

Интересно, можно ли получить какую-то выгоду от асинхронных операций, есть ли разница между просто вводом-выводом в отдельном потоке и асинхронными запросами.
Вот здесь товарищ получил:
http://blog.gamedeff.com/?p=142#more-142
хотя, конечно, задача у него сильно другая - случайное чтение с минимальными задержками. На последовательном, наверное, куча асинхронных запросов не поможет, разве что файл сильно фрагментирован.

← →
Игорь Шевченко © (2013-02-15 00:27) [81]

Sapersky (15.02.13 00:21) [80]

> Теоретически неплохая идея, при условии, что второй поток
> занят чем-то существенным

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

← →
Jeer © (2013-02-15 00:30) [82]

Чисто методически:

Нет смысла гонять "примитивные" методы доступа к той или иной памяти, если не поставлена общая задача обработки данных. (С)

← →
Игорь Шевченко © (2013-02-15 00:56) [83]

Jeer © (15.02.13 00:30) [82]

+100500

← →
Sapersky (2013-02-15 01:23) [84]

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

← →
Jeer © (2013-02-15 01:40) [85]

> Sapersky (15.02.13 01:23) [84]

"Смысл оптимизации частного не может быть выше смысла оптимизации общего" (С) Jeer.

← →
DevilDevil © (2013-02-15 09:50) [86]

> Sapersky (15.02.13 00:21) [80]

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

обижаете, товарищ!
в данном примере (reading_benchmark.exe) как раз происходит распарсивание текста, подсчёт суммы всех чисел в файле. В correct_file.txt 22млн строк, каждую из которых мы распарсиваем и переводим к инту.

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

В том то и дело...
Получается, нужно протестировать чтение: с FILE_FLAG_SEQUENTIAL_SCAN, с асинхронным чтением, FILE_FLAG_NO_BUFFERING.

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

← →
DevilDevil © (2013-02-15 10:00) [87]

> Jeer ©

видимо ты слишком редко сталкивался с такими задачами, если не врубился "зачем всё это"
потоковое чтение или потоковая запись больших файлов - одна из сложнейших задач, особенно если стоит задача выжать максимальную производительность. К примеру в writing_benchmark.exe показано, как можно записать 100мб текста стандартным способом

← →
Jeer © (2013-02-15 10:27) [88]

Удалено модератором

← →
Jeer © (2013-02-15 10:28) [89]

Удалено модератором

← →
DevilDevil © (2013-02-15 10:33) [90]

напоминаю, актуальный (мой) бенчмарк здесь:http://zalil.ru/34257617
для удобства есть "benchmarks.bat", который выдаёт "benchmarks.log"

можете закомментировать строки "DoubleBuffered" варианты
можно вписывать флаги CreateFile() в TCachedFileWriter.Initialize() и заменить FileOpen() на CreateFile() с флагами в TCachedFileReader.Initialize()

← →
DevilDevil © (2013-02-15 10:34) [91]

Удалено модератором

← →
Sapersky (2013-02-15 19:28) [92]

в данном примере (reading_benchmark.exe) как раз происходит распарсивание текста, подсчёт суммы всех чисел в файле.

Пардон, не смотрел в исходник.
Тем не менее, 2 потока в среднем быстрее всего на 2-3%, если это не погрешность измерений. И с NO_BUFFERING, когда система не должна делать упреждающее чтение, тоже (сам диск делает?).
Не знаю уж, в чём дело. Возможно, в том, что скорость некэшированного чтения и так уже близка к максимально возможной (у меня 100-120 мб/c), больше ускоряться некуда. Т.е. и правда, не нужно "серебряной пули", обычные свинцовые нормально работают.
В NO_BUFFERING смысла нет, только замедляется всё на 5-10%. Кэш при этом сбрасывается (кстати, удобно для тестирования некэшированного чтения - сначала открыть с NO_BUFFERING, закрыть, открыть как обычно).
В FILE_FLAG_SEQUENTIAL_SCAN тоже особой магии нет (и на практике эффекта не видно), к тому же менеджер кэша может автоматически переключаться в этот режим:
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/20/10258690.aspx

Асинхронное чтение здесь тестировали:
http://www.gamasutra.com/view/feature/129988/fast_file_loading_pt_1.php?print=1
Результат тот же, что и с обычным. Вывод забавный: лучший способ ускорить загрузку - уменьшить (сжать) файл. Но для тебя это неприемлемо, как я понимаю.

← →
DevilDevil © (2013-02-15 21:23) [93]

> Sapersky (15.02.13 19:28) [92]

за выходные постараюсь соорудить тест, который будет работать с разными размерами буфера и опциями

> Не знаю уж, в чём дело. Возможно, в том, что скорость некэшированного
> чтения и так уже близка к максимально возможной (у меня
> 100-120 мб/c), больше ускоряться некуда. Т.е. и правда,
> не нужно "серебряной пули", обычные свинцовые нормально работают.

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

← →
DevilDevil © (2013-02-17 03:08) [94]

я думаю надо в лог выводить название операционной системы и винчестера
поделитесь кодом у кого есть

← →
Sapersky (2013-02-17 04:29) [95]

Мог бы и сам поискать, вроде без проблем такие вещи находятся:
http://www.delphidabbler.com/download?id=sysinfo&type=src
http://home.earthlink.net/~akonshin/files/IdeInfo2.zip (нужны админские права)

← →
DevilDevil © (2013-02-17 10:09) [96]

> Sapersky (17.02.13 04:29) [95]

я просто за разделение труда
выуди пожалуйста оттуда код, берущий ProductName из PJSysInfo.pas
и ModelNumber из Ioctl.pas (только он берёт инфо первого диска, а надо инфо диска, с которого запускается exe)

← →
DevilDevil © (2013-02-17 19:55) [97]

Мне кажется я склепал толковый тест. И на чтение, и на запись
Каждая из тестовых утилит ведёт лог, можно взять данные оттуда
http://zalil.ru/34269667

Мои цифры:

write_test.exe Windows XP, ST380011A Top 8: 3895ms: 256kb, Overlapped | WriteThrough 4116ms: 128kb, Overlapped | Sequential | WriteThrough 4125ms: 256kb, NoBuffering 4146ms: 128kb, Overlapped | WriteThrough 4186ms: 256kb, NoBuffering | Sequential 4227ms: 256kb, NoBuffering | Overlapped | Sequential 4297ms: 256kb, NoBuffering | Overlapped 4396ms: 256kb, Overlapped | Sequential | WriteThrough Worse 8: 10776ms: 16kb, WriteThrough 10505ms: 16kb, Sequential | WriteThrough 10465ms: 16kb, NoBuffering | Overlapped | WriteThrough 9954ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 9815ms: 16kb, NoBuffering | WriteThrough 9754ms: 16kb, NoBuffering | Sequential | WriteThrough 8452ms: 32kb, Sequential | WriteThrough 8302ms: 16kb, Overlapped | WriteThrough

read_test.exe Windows XP, ST380011A Top 5: 2333ms: 256kb, NoBuffering | Overlapped | Sequential 2353ms: 64kb, NoBuffering | Overlapped 2354ms: 64kb, NoBuffering | Overlapped | Sequential 2394ms: 256kb, NoBuffering | Overlapped 2394ms: 16kb, Default Worse 5: 5878ms: 256kb, Overlapped 5048ms: 256kb, Default 4696ms: 16kb, NoBuffering 4587ms: 256kb, NoBuffering | Sequential 4326ms: 256kb, NoBuffering

← →
Sapersky (2013-02-17 21:45) [98]

Пока смотрел только чтение.
NoBuffering специально через один чтобы сбрасывать кэш? Но в самом начале файл тоже может быть закэширован (и у меня сначала первый тест выдал результат в 2 раза лучше). И даже если не закэширован, результаты первого теста могут отличаться, надо бы сначала сделать прогон "для разогрева". Вообще результаты довольно сильно "болтает", может из-за того, что они близки друг к другу. Но Sequential почти всегда оказывается в топе. Чистый NoBuffering - кхм, в боттоме.
Windows 7, ST3500412AS Top 5 (с пяти прогонов): 904ms: 64kb, Sequential 920ms: 32kb, Default 920ms: 128kb, Sequential 921ms: 64kb, Overlapped | Sequential 921ms: 16kb, Overlapped | Sequential 905ms: 64kb, Sequential 920ms: 64kb, Overlapped 920ms: 32kb, Default 920ms: 128kb, Sequential 921ms: 128kb, Default 905ms: 32kb, Sequential 920ms: 256kb, NoBuffering | Overlapped 921ms: 32kb, NoBuffering | Overlapped | Sequential 936ms: 128kb, NoBuffering | Overlapped | Sequential 936ms: 64kb, Overlapped | Sequential 936ms: 64kb, Sequential 951ms: 16kb, Sequential 952ms: 32kb, Default 952ms: 32kb, Sequential 952ms: 16kb, Overlapped | Sequential 920ms: 32kb, Overlapped | Sequential 920ms: 128kb, Overlapped 921ms: 64kb, Default 936ms: 16kb, Overlapped 936ms: 64kb, NoBuffering | Overlapped Worse 5: 1436ms: 16kb, NoBuffering 1419ms: 16kb, NoBuffering | Sequential 1279ms: 32kb, NoBuffering | Sequential 1264ms: 32kb, NoBuffering 1263ms: 256kb, NoBuffering | Overlapped | Sequential

Sequential задаёт поведение менеджера кэша (я же давал ссылку), поэтому при NoBuffering ни на что не влияет.
Можно ещё тестировать отдельно чтение из кэша. Чисто ради интереса, насколько эффективен кэш на разных ОС, например.

← →
DevilDevil © (2013-02-17 21:50) [99]

> Sapersky (17.02.13 21:45) [98]

в модуле TestPlatform.pas есть цикл в RUN_BENCHMARK()
там для каждого размера буфера запускается разный набор опций

у тебя кстати достаточно близкие значения
у меня разброс больше

выводи сразу и запись

← →
DevilDevil © (2013-02-17 21:54) [100]

а FlushFileBuffers я вызываю дважды
при старте и при завершении
но судя по всему это не всегда правильное действие оказывает
хз

кстати не забывай, что начиная с семёрки (или висты) используется особое кеширование файлов

← →
Игорь Шевченко © (2013-02-17 22:56) [101]

http://blog.dummzeuch.de/2013/02/16/35-gigabyte-text-file-meet-largetextviewer/

← →
Sapersky (2013-02-17 23:09) [102]

← →
DevilDevil © (2013-02-17 23:43) [103]

> Sapersky (17.02.13 23:09) [102]

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

> Игорь Шевченко © (17.02.13 22:56) [101]

зачем ?

← →
Sapersky (2013-02-18 09:31) [104]

Нет там особенных проблем с кэшем, только на первом тесте могут быть. Поменяй условие:
if (i and 1 = 0) then Include(Mode.Options, foNoBuffering);
тогда тесты будут начинаться с небуферизованного режима, который сбрасывает кэш.
Неплохо бы ещё вместе с лучшими и худшими результатами выводить вариант без спец. флагов, чтобы понять, сколько собственно выгадано этими экспериментами. Судя по логам, заметный прирост получился на записи, раза полтора. На чтении не очень, 0-10%.

В [101] вероятно был вариант улучшения отклика программы с т.з. пользователя (вроде тебе это и требуется): начинать выводить данные, не загружая их полностью, вместо попыток ускорить загрузку ещё на несколько процентов. Ну или вместе с попытками, если хочется.

из загрузки. оптимизации загрузки до одурения. Ну или вместе с оптимизацией.

← →
Sapersky (2013-02-18 09:33) [105]

Последняя строчка лишняя :)

← →
DevilDevil © (2013-02-18 09:47) [106]

> Sapersky (18.02.13 09:31) [104]

> if (i and 1 = 0) then Include(Mode.Options, foNoBuffering);
> тогда тесты будут начинаться с небуферизованного режима,
> который сбрасывает кэш.

сделано
http://zalil.ru/34271095

> Неплохо бы ещё вместе с лучшими и худшими результатами выводить
> вариант без спец. флагов

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

> В [101] вероятно был вариант улучшения отклика программы
> с т.з. пользователя

не совсем понял, что ты имеешь ввиду

← →
megavoid © (2013-02-18 10:00) [107]

← →
megavoid © (2013-02-18 10:05) [108]

← →
megavoid © (2013-02-18 10:09) [109]

Windows 8, [Kingston KVR16N11] (RAM)

write_test.exe
Top 8: 1265ms: 128kb, NoBuffering | WriteThrough 1265ms: 256kb, Overlapped | WriteThrough 1266ms: 128kb, Overlapped | WriteThrough 1266ms: 128kb, NoBuffering | Sequential | WriteThrough 1266ms: 256kb, NoBuffering | Overlapped 1266ms: 256kb, NoBuffering | Sequential 1266ms: 256kb, NoBuffering | Overlapped | WriteThrough 1266ms: 64kb, Overlapped | Sequential | WriteThrough Worse 8: 1375ms: 16kb, Sequential | WriteThrough 1375ms: 16kb, NoBuffering 1375ms: 16kb, WriteThrough 1360ms: 32kb, WriteThrough 1344ms: 16kb, NoBuffering | WriteThrough 1344ms: 128kb, WriteThrough 1344ms: 16kb, NoBuffering | Sequential | WriteThrough 1343ms: 32kb, Sequential | WriteThrough

read_test.exe
Top 5: 344ms: 32kb, Sequential 344ms: 256kb, Overlapped | Sequential 359ms: 32kb, Default 359ms: 32kb, Overlapped 359ms: 16kb, Overlapped Worse 5: 406ms: 16kb, NoBuffering 375ms: 32kb, NoBuffering | Sequential 375ms: 16kb, NoBuffering | Overlapped | Sequential 375ms: 256kb, Sequential 375ms: 256kb, NoBuffering | Sequential

← →
DevilDevil © (2013-02-18 10:13) [110]

> megavoid ©

респект!

Вот мой тест на рабочем месте (правда касперский у нас дикий - может всё тормозить):

read_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 2156ms: 16kb, Default 2156ms: 16kb, Sequential 2156ms: 64kb, Sequential 2157ms: 32kb, Default 2171ms: 128kb, NoBuffering | Sequential Worse 5: 8312ms: 64kb, NoBuffering 5328ms: 64kb, Default 4125ms: 32kb, NoBuffering | Overlapped | Sequential 4078ms: 32kb, Overlapped | Sequential 3469ms: 16kb, NoBuffering Top 5: 2156ms: 128kb, Default 2157ms: 16kb, Default 2157ms: 128kb, NoBuffering | Sequential 2171ms: 16kb, NoBuffering | Overlapped 2171ms: 128kb, Overlapped Worse 5: 3500ms: 32kb, NoBuffering | Overlapped | Sequential 3422ms: 16kb, NoBuffering 3344ms: 256kb, Overlapped 3282ms: 256kb, Default 3204ms: 16kb, Overlapped Top 5: 2156ms: 32kb, Sequential 2156ms: 32kb, Overlapped | Sequential 2156ms: 64kb, Default 2156ms: 128kb, Sequential 2172ms: 32kb, Overlapped Worse 5: 4188ms: 16kb, Overlapped 3828ms: 16kb, NoBuffering 3234ms: 256kb, Default 3187ms: 128kb, NoBuffering 3187ms: 16kb, NoBuffering | Sequential

write_test.exe
Windows XP, SAMSUNG SP1213N
Top 8: 5859ms: 128kb, Overlapped | WriteThrough 6110ms: 256kb, Overlapped | WriteThrough 6156ms: 64kb, Default 6172ms: 128kb, Default 6234ms: 128kb, Overlapped 6297ms: 32kb, Default 6406ms: 256kb, Overlapped 6406ms: 256kb, Sequential Worse 8: 14672ms: 16kb, Sequential | WriteThrough 14250ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 14156ms: 16kb, WriteThrough 13828ms: 16kb, NoBuffering | WriteThrough 13640ms: 32kb, NoBuffering | Overlapped | Sequential 13235ms: 16kb, NoBuffering | Overlapped | WriteThrough 12812ms: 16kb, NoBuffering | Sequential | WriteThrough 11953ms: 64kb, NoBuffering | Overlapped | WriteThrough

← →
dmk © (2013-02-18 10:24) [111]

← →
DevilDevil © (2013-02-18 10:35) [112]

Провели тест у коллеги

read_test.exe
Windows XP, Hitachi HDS721616PLA380
Top 5: 1406ms: 16kb, Default 1406ms: 16kb, NoBuffering | Overlapped 1406ms: 16kb, Overlapped 1406ms: 16kb, Sequential 1406ms: 16kb, NoBuffering | Overlapped | Sequential Worse 5: 3891ms: 32kb, Sequential 3172ms: 128kb, Sequential 2938ms: 16kb, NoBuffering | Sequential 2891ms: 16kb, NoBuffering 2016ms: 32kb, Overlapped

write_test.exe
Windows XP, Hitachi HDS721616PLA380

Top 8: 4110ms: 256kb, Overlapped | WriteThrough 4187ms: 256kb, Overlapped | Sequential | WriteThrough 4359ms: 128kb, Sequential 4359ms: 256kb, Sequential 4375ms: 256kb, Default 4500ms: 32kb, Default 4516ms: 128kb, Default 4516ms: 64kb, Default Worse 8: 34234ms: 16kb, WriteThrough 12157ms: 16kb, NoBuffering | Overlapped | WriteThrough 11797ms: 16kb, NoBuffering | Sequential | WriteThrough 11609ms: 16kb, Sequential | WriteThrough 11313ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 11031ms: 16kb, NoBuffering | WriteThrough 10796ms: 64kb, NoBuffering | Sequential | WriteThrough 8140ms: 16kb, Overlapped | WriteThrough

← →
Inovet © (2013-02-18 10:50) [113]

← →
DevilDevil © (2013-02-18 11:18) [114]

убрал из тестирования в среднем слабенькие размеры буфера 16кб и 32кб
чтобы тесты выдавали более объективную картину насчёт отпций
и чтобы выполнялись быстрее
http://zalil.ru/34271269

read_test.exe
Windows XP, SAMSUNG SP1213N
Top 5: 2157ms: 64kb, Overlapped | Sequential 2171ms: 128kb, Default 2172ms: 128kb, NoBuffering 2172ms: 128kb, NoBuffering | Overlapped | Sequential 2187ms: 256kb, NoBuffering | Overlapped | Sequential Worse 5: 5688ms: 256kb, Overlapped | Sequential 5344ms: 256kb, NoBuffering 4469ms: 128kb, NoBuffering | Sequential 4187ms: 256kb, Default 3984ms: 256kb, Overlapped Top 5: 2156ms: 64kb, Overlapped | Sequential 2172ms: 64kb, NoBuffering | Overlapped | Sequential 2172ms: 64kb, NoBuffering | Overlapped 2172ms: 128kb, NoBuffering 2172ms: 128kb, NoBuffering | Overlapped Worse 5: 6141ms: 256kb, NoBuffering | Overlapped 5266ms: 64kb, Sequential 3781ms: 256kb, NoBuffering | Sequential 3453ms: 256kb, Overlapped 3375ms: 64kb, Overlapped

write_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 6421ms: 128kb, Overlapped | Sequential | WriteThrough 6453ms: 256kb, Overlapped | WriteThrough 6484ms: 128kb, Overlapped | WriteThrough 6563ms: 256kb, Overlapped | Sequential | WriteThrough 6625ms: 64kb, Overlapped | Sequential Worse 5: 11687ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough 9812ms: 256kb, WriteThrough 9625ms: 256kb, NoBuffering | WriteThrough 9079ms: 128kb, NoBuffering | Sequential | WriteThrough 8954ms: 64kb, NoBuffering | WriteThrough

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

я вот думаю надо принципиально разделять тесты по операционным системам. Условно говоря есть "старые винды" где работа с диском происходит старым образом, есть "новые винды", где всю свободную память занимает кеш файлов (кстати с какой версии? с семёрки или с висты?)

← →
DevilDevil © (2013-02-18 11:38) [115]

(hint: качать тесты http://zalil.ru/34271269)

read_test.exe
Windows 7, ST3250410AS ATA Device
Top 5: 843ms: 64kb, Sequential 843ms: 256kb, Sequential 844ms: 256kb, NoBuffering | Overlapped | Sequential 859ms: 64kb, Overlapped | Sequential 860ms: 128kb, NoBuffering | Overlapped | Sequential Worse 5: 1312ms: 64kb, NoBuffering 1047ms: 128kb, NoBuffering 1032ms: 64kb, NoBuffering | Sequential 1016ms: 128kb, NoBuffering | Sequential 1015ms: 256kb, NoBuffering

write_test.exe
Windows 7, ST3250410AS ATA Device

Top 5: 3906ms: 128kb, Overlapped | WriteThrough 4125ms: 64kb, Overlapped | WriteThrough 4187ms: 256kb, NoBuffering 4188ms: 256kb, NoBuffering | Overlapped | Sequential 4266ms: 256kb, NoBuffering | Overlapped Worse 5: 23344ms: 64kb, Overlapped | Sequential | WriteThrough 19172ms: 64kb, NoBuffering | WriteThrough 10515ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough 10297ms: 64kb, NoBuffering | Sequential | WriteThrough 9484ms: 128kb, NoBuffering | WriteThrough

какие лично у меня выводы пока напрашиваются

пока я совершенно точно вижу, что в write_test в худших преобладает NoBuffering. В "новых виндах" вредность этого флага очевидна. Потому что там вообще редко на диск скидывается, в основном пишется в память. Но для "старых виндов" вредность этого флага не совсем понятна. По идее NoBuffering + Overlapped должно работать лучше буферизированных аналогов. Но тесты говорят об обратном. Может это связано с тем, что NoBuffering файлы после записи надо обрезать?

с удовольствием выслушаю ваши рассуждения

> [113] Inovet © (18.02.13 10:50)
> Сигейт 5900 2ТБ

Ближе к началу диска

read_test.exe

Windows 7, unknown drive model

Top 5:
951ms: 128kb, Default
951ms: 256kb, Default
952ms: 128kb, Overlapped | Sequential
952ms: 64kb, NoBuffering | Overlapped
952ms: 256kb, Sequential

Worse 5:
1046ms: 128kb, NoBuffering | Overlapped
1046ms: 256kb, NoBuffering | Overlapped
1030ms: 128kb, NoBuffering
1030ms: 256kb, NoBuffering | Sequential
1029ms: 128kb, NoBuffering | Sequential

write_test.exe

Windows 7, unknown drive model

Top 5:
2075ms: 128kb, Overlapped | Sequential | WriteThrough
2075ms: 256kb, Overlapped | Sequential | WriteThrough
2090ms: 128kb, Overlapped | WriteThrough
2168ms: 256kb, Overlapped | WriteThrough
2168ms: 64kb, Overlapped | WriteThrough

Worse 5:
4056ms: 64kb, NoBuffering | Sequential | WriteThrough
4040ms: 64kb, NoBuffering | Overlapped | WriteThrough
4040ms: 64kb, NoBuffering | WriteThrough
3993ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough
3806ms: 64kb, NoBuffering

read_test.exe

Windows 7, unknown drive model Сигейт 7200 320ГБ системный в районе средины диска

Top 5:
1435ms: 128kb, NoBuffering | Overlapped
1435ms: 128kb, Overlapped | Sequential
1435ms: 256kb, NoBuffering | Overlapped
1435ms: 256kb, Sequential
1436ms: 64kb, Default

Worse 5:
2839ms: 64kb, NoBuffering
2028ms: 64kb, NoBuffering | Overlapped
1997ms: 256kb, NoBuffering | Sequential
1966ms: 64kb, NoBuffering | Sequential
1888ms: 128kb, Overlapped

write_test.exe

Windows 7, unknown drive model тот же

Top 5:
2965ms: 128kb, Overlapped | WriteThrough
3261ms: 256kb, Overlapped | WriteThrough
3370ms: 128kb, Overlapped | Sequential | WriteThrough
3510ms: 256kb, Sequential | WriteThrough
3744ms: 256kb, Overlapped | Sequential | WriteThrough

Worse 5:
8721ms: 64kb, NoBuffering
8284ms: 128kb, NoBuffering
7316ms: 64kb, Default
7129ms: 64kb, Overlapped
6630ms: 64kb, NoBuffering | Overlapped

Windows 8, Hitachi HDT725032VLA360

write_test.exe
Top 5: 2406ms: 256kb, Overlapped | WriteThrough 2703ms: 256kb, Overlapped | Sequential | WriteThrough 2718ms: 256kb, NoBuffering 2719ms: 256kb, NoBuffering | Sequential 2719ms: 128kb, Overlapped | WriteThrough Worse 5: 4828ms: 64kb, Sequential | WriteThrough 4640ms: 64kb, NoBuffering | Overlapped | WriteThrough 4625ms: 64kb, WriteThrough 4610ms: 64kb, NoBuffering | WriteThrough 4437ms: 64kb, NoBuffering | Sequential | WriteThrough

read_test.exe
Top 5: 1734ms: 256kb, Overlapped 1735ms: 128kb, Sequential 1735ms: 64kb, Overlapped | Sequential 1750ms: 128kb, Default 1750ms: 128kb, NoBuffering | Overlapped Worse 5: 2062ms: 256kb, Sequential 1844ms: 256kb, NoBuffering | Sequential 1844ms: 128kb, NoBuffering 1828ms: 256kb, Default 1813ms: 256kb, Overlapped | Sequential

Windows 8, OCZ-VERTEX4

write_test.exe
Top 5: 1985ms: 256kb, Overlapped | WriteThrough 2000ms: 128kb, Overlapped | Sequential | WriteThrough 2062ms: 128kb, Overlapped | WriteThrough 2063ms: 64kb, Overlapped | Sequential | WriteThrough 2110ms: 128kb, Overlapped Worse 5: 3016ms: 64kb, Sequential | WriteThrough 2719ms: 64kb, NoBuffering | WriteThrough 2703ms: 64kb, NoBuffering | Overlapped | Sequential 2656ms: 64kb, NoBuffering | Overlapped 2656ms: 128kb, NoBuffering | Overlapped

read_test.exe
Top 5: 359ms: 128kb, Overlapped 359ms: 128kb, Overlapped | Sequential 359ms: 256kb, Default 359ms: 256kb, Overlapped 359ms: 256kb, NoBuffering | Overlapped | Sequential Worse 5: 656ms: 64kb, NoBuffering 641ms: 256kb, NoBuffering 641ms: 256kb, NoBuffering | Sequential 609ms: 64kb, NoBuffering | Sequential 594ms: 128kb, NoBuffering | Sequential

А нельзя ли сделать оболочку, прогресс бар и галочки, чтобы включать/отключать флаги?! И скорость в Мб/с показывать. А то не наглядно как-то :)

> Inovet © (18.02.13 12:56) [120]
> Статистики маловато.

согласен !

> dmk © (18.02.13 14:45) [123]
>
> А нельзя ли сделать оболочку, прогресс бар и галочки, чтобы
> включать/отключать флаги?! И скорость в Мб/с показывать.
> А то не наглядно как-то :)

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

если есть время/желание - сооруди такую утилиту, о которой ты говоришь
пример можно посмотреть в TestPlatform.pas

Не знаю, насколько правильно
но я увеличил загруженность процессора при чтении
и убрал NoBuffering для записи, потому что всёравно самый плохой результат выдают
качать здесь: http://zalil.ru/34271961

read_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 6984ms: 128kb, NoBuffering | Overlapped | Sequential 7015ms: 64kb, NoBuffering | Overlapped | Sequential 7031ms: 128kb, NoBuffering | Overlapped 7047ms: 64kb, NoBuffering | Overlapped 7360ms: 256kb, NoBuffering | Overlapped Worse 5: 10844ms: 64kb, NoBuffering 10359ms: 256kb, Sequential 10235ms: 256kb, NoBuffering | Sequential 10109ms: 256kb, NoBuffering 9547ms: 128kb, Sequential Top 5: 7000ms: 256kb, NoBuffering | Overlapped | Sequential 7015ms: 64kb, NoBuffering | Overlapped | Sequential 7047ms: 256kb, NoBuffering | Overlapped 7093ms: 128kb, NoBuffering | Overlapped | Sequential 7282ms: 128kb, Overlapped Worse 5: 10875ms: 64kb, NoBuffering 10750ms: 64kb, Sequential 9953ms: 64kb, Default 9282ms: 64kb, NoBuffering | Sequential 9281ms: 128kb, NoBuffering

write_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 5922ms: 128kb, Overlapped | WriteThrough 5968ms: 256kb, Overlapped | Sequential | WriteThrough 5984ms: 256kb, Overlapped | WriteThrough 6015ms: 128kb, Overlapped | Sequential | WriteThrough 6203ms: 128kb, Sequential Worse 5: 14703ms: 64kb, WriteThrough 8390ms: 128kb, WriteThrough 8219ms: 64kb, Sequential | WriteThrough 8094ms: 256kb, Sequential | WriteThrough 7953ms: 64kb, Overlapped | Sequential Top 5: 5875ms: 128kb, Overlapped | Sequential | WriteThrough 5969ms: 128kb, Overlapped | WriteThrough 6000ms: 256kb, Overlapped | WriteThrough 6015ms: 256kb, Overlapped | Sequential | WriteThrough 6156ms: 64kb, Overlapped | Sequential Worse 5: 7813ms: 64kb, WriteThrough 7750ms: 64kb, Sequential | WriteThrough 7359ms: 128kb, Default 7328ms: 64kb, Default 7141ms: 128kb, WriteThrough

read_test.exe
Windows XP, Hitachi HDS721616PLA380

Top 5: 4813ms: 64kb, Overlapped 4828ms: 128kb, NoBuffering | Overlapped 4921ms: 256kb, Overlapped 4937ms: 256kb, Overlapped | Sequential 4984ms: 64kb, NoBuffering | Overlapped Worse 5: 14953ms: 64kb, NoBuffering | Overlapped | Sequential 8875ms: 256kb, Sequential 8219ms: 64kb, Sequential 6329ms: 64kb, NoBuffering 6328ms: 64kb, NoBuffering | Sequential Top 5: 4687ms: 256kb, NoBuffering | Overlapped 4703ms: 128kb, Overlapped 4719ms: 128kb, Overlapped | Sequential 4734ms: 64kb, Overlapped | Sequential 4735ms: 128kb, NoBuffering | Overlapped | Sequential Worse 5: 6313ms: 64kb, NoBuffering 5844ms: 64kb, NoBuffering | Sequential 5672ms: 128kb, NoBuffering 5672ms: 256kb, NoBuffering | Sequential 5656ms: 128kb, NoBuffering | Sequential

write_test.exe
Windows XP, Hitachi HDS721616PLA380

Top 5: 4140ms: 256kb, Overlapped | Sequential | WriteThrough 4156ms: 256kb, Overlapped | WriteThrough 4422ms: 256kb, Sequential 4438ms: 256kb, Default 4578ms: 128kb, Sequential Worse 5: 11438ms: 128kb, WriteThrough 7140ms: 64kb, Sequential | WriteThrough 6687ms: 64kb, WriteThrough 5562ms: 128kb, Overlapped | WriteThrough 5500ms: 64kb, Overlapped | WriteThrough Top 5: 4109ms: 256kb, Overlapped | Sequential | WriteThrough 4250ms: 256kb, Sequential 4344ms: 256kb, Default 4360ms: 128kb, Sequential 4469ms: 128kb, Default Worse 5: 7375ms: 64kb, Sequential | WriteThrough 6703ms: 64kb, WriteThrough 5625ms: 128kb, WriteThrough 5609ms: 256kb, Overlapped | WriteThrough 5313ms: 128kb, Sequential | WriteThrough

read_test.exe
Windows 7, ST3250410AS ATA Device

Top 5: 3938ms: 128kb, Overlapped | Sequential 3953ms: 128kb, Overlapped 3953ms: 64kb, Overlapped 3953ms: 256kb, NoBuffering | Overlapped 3954ms: 128kb, NoBuffering | Overlapped Worse 5: 5438ms: 64kb, NoBuffering 4813ms: 64kb, NoBuffering | Sequential 4781ms: 128kb, NoBuffering 4766ms: 256kb, NoBuffering | Sequential 4750ms: 256kb, NoBuffering

write_test.exe
Windows 7, ST3250410AS ATA Device

Top 5: 3734ms: 256kb, Overlapped | WriteThrough 3765ms: 64kb, Overlapped | WriteThrough 3828ms: 128kb, Overlapped | Sequential | WriteThrough 3907ms: 64kb, Overlapped | Sequential | WriteThrough 4046ms: 256kb, Overlapped | Sequential | WriteThrough Worse 5: 10469ms: 64kb, Sequential | WriteThrough 9172ms: 256kb, WriteThrough 6140ms: 64kb, WriteThrough 5937ms: 128kb, Sequential | WriteThrough 5859ms: 256kb, Overlapped

> DevilDevil © (18.02.13 15:29) [126]
> read_test.exe
> Windows 7, ST3250410AS ATA Device

Это ты я как понял с моей рабочей данные показал.

На тебе с домашней.
Диск: ST3500320AS ATA Device (тоже барракуда 7200.11)
Ось в обоих случаях семерка 32 бита с 2Гб памяти на борту.

Read
Starting: 1) 64kb, NoBuffering... 15007ms 2) 64kb, Default... 6209ms 3) 64kb, NoBuffering | Overlapped... 6802ms 4) 64kb, Overlapped... 4212ms 5) 64kb, NoBuffering | Sequential... 8502ms 6) 64kb, Sequential... 4212ms 7) 64kb, NoBuffering | Overlapped | Sequential... 4025ms 8) 64kb, Overlapped | Sequential... 3931ms 9) 128kb, NoBuffering... 5195ms 10) 128kb, Default... 4290ms 11) 128kb, NoBuffering | Overlapped... 3915ms 12) 128kb, Overlapped... 3729ms 13) 128kb, NoBuffering | Sequential... 4945ms 14) 128kb, Sequential... 3994ms 15) 128kb, NoBuffering | Overlapped | Sequential... 3775ms 16) 128kb, Overlapped | Sequential... 3728ms 17) 256kb, NoBuffering... 4821ms 18) 256kb, Default... 4305ms 19) 256kb, NoBuffering | Overlapped... 3744ms 20) 256kb, Overlapped... 3791ms 21) 256kb, NoBuffering | Sequential... 5819ms 22) 256kb, Sequential... 4072ms 23) 256kb, NoBuffering | Overlapped | Sequential... 3806ms 24) 256kb, Overlapped | Sequential... 3978ms Top 5: 3728ms: 128kb, Overlapped | Sequential 3729ms: 128kb, Overlapped 3744ms: 256kb, NoBuffering | Overlapped 3775ms: 128kb, NoBuffering | Overlapped | Sequential 3791ms: 256kb, Overlapped Worse 5: 15007ms: 64kb, NoBuffering 8502ms: 64kb, NoBuffering | Sequential 6802ms: 64kb, NoBuffering | Overlapped 6209ms: 64kb, Default 5819ms: 256kb, NoBuffering | Sequential

write

Starting: 1) 64kb, Default... 5210ms 2) 64kb, Overlapped... 5211ms 3) 64kb, Sequential... 5320ms 4) 64kb, Overlapped | Sequential... 5210ms 5) 64kb, WriteThrough... 6349ms 6) 64kb, Overlapped | WriteThrough... 3962ms 7) 64kb, Sequential | WriteThrough... 6193ms 8) 64kb, Overlapped | Sequential | WriteThrough... 3978ms 9) 128kb, Default... 5211ms 10) 128kb, Overlapped... 5195ms 11) 128kb, Sequential... 5039ms 12) 128kb, Overlapped | Sequential... 5117ms 13) 128kb, WriteThrough... 5304ms 14) 128kb, Overlapped | WriteThrough... 3573ms 15) 128kb, Sequential | WriteThrough... 5210ms 16) 128kb, Overlapped | Sequential | WriteThrough... 3681ms 17) 256kb, Default... 5133ms 18) 256kb, Overlapped... 5367ms 19) 256kb, Sequential... 5210ms 20) 256kb, Overlapped | Sequential... 4945ms 21) 256kb, WriteThrough... 5070ms 22) 256kb, Overlapped | WriteThrough... 3853ms 23) 256kb, Sequential | WriteThrough... 5086ms 24) 256kb, Overlapped | Sequential | WriteThrough... 3588ms Top 5: 3573ms: 128kb, Overlapped | WriteThrough 3588ms: 256kb, Overlapped | Sequential | WriteThrough 3681ms: 128kb, Overlapped | Sequential | WriteThrough 3853ms: 256kb, Overlapped | WriteThrough 3962ms: 64kb, Overlapped | WriteThrough Worse 5: 6349ms: 64kb, WriteThrough 6193ms: 64kb, Sequential | WriteThrough 5367ms: 256kb, Overlapped 5320ms: 64kb, Sequential 5304ms: 128kb, WriteThrough

Кстати тесты плывут.

В качестве примера опять запустил тест на чтение, показатели вообще не те:

Starting: 1) 64kb, NoBuffering... 5117ms 2) 64kb, Default... 5023ms 3) 64kb, NoBuffering | Overlapped... 4196ms 4) 64kb, Overlapped... 4181ms 5) 64kb, NoBuffering | Sequential... 6630ms 6) 64kb, Sequential... 3978ms 7) 64kb, NoBuffering | Overlapped | Sequential... 3713ms 8) 64kb, Overlapped | Sequential... 3822ms 9) 128kb, NoBuffering... 4945ms 10) 128kb, Default... 4243ms 11) 128kb, NoBuffering | Overlapped... 3697ms 12) 128kb, Overlapped... 3698ms 13) 128kb, NoBuffering | Sequential... 4882ms 14) 128kb, Sequential... 3963ms 15) 128kb, NoBuffering | Overlapped | Sequential... 3853ms 16) 128kb, Overlapped | Sequential... 3760ms 17) 256kb, NoBuffering... 4914ms 18) 256kb, Default... 4227ms 19) 256kb, NoBuffering | Overlapped... 3682ms 20) 256kb, Overlapped... 3744ms 21) 256kb, NoBuffering | Sequential... 4836ms 22) 256kb, Sequential... 3947ms 23) 256kb, NoBuffering | Overlapped | Sequential... 3697ms 24) 256kb, Overlapped | Sequential... 3713ms Top 5: 3682ms: 256kb, NoBuffering | Overlapped 3697ms: 128kb, NoBuffering | Overlapped 3697ms: 256kb, NoBuffering | Overlapped | Sequential 3698ms: 128kb, Overlapped 3713ms: 64kb, NoBuffering | Overlapped | Sequential Worse 5: 6630ms: 64kb, NoBuffering | Sequential 5117ms: 64kb, NoBuffering 5023ms: 64kb, Default 4945ms: 128kb, NoBuffering 4914ms: 256kb, NoBuffering

← →
Sapersky (2013-02-18 17:58) [129]

У меня тоже результаты на запись в 1.5 раза отличались - потом заметил, что забыл выключить торренты. Или может памяти под кэш не хватает. Или процессор загружен (новый тест, похоже, упирается в процессор).
Сейчас проверил чтение, болтанка результатов в пределах 200 мс.
Windows 7, ST3500418AS (другая машина) Starting: 1) 64kb, NoBuffering... 4407ms 2) 64kb, Default... 4265ms 3) 64kb, NoBuffering | Overlapped... 3735ms 4) 64kb, Overlapped... 3640ms 5) 64kb, NoBuffering | Sequential... 4610ms 6) 64kb, Sequential... 3859ms 7) 64kb, NoBuffering | Overlapped | Sequential... 3641ms 8) 64kb, Overlapped | Sequential... 3656ms 9) 128kb, NoBuffering... 4328ms 10) 128kb, Default... 4109ms 11) 128kb, NoBuffering | Overlapped... 3641ms 12) 128kb, Overlapped... 3656ms 13) 128kb, NoBuffering | Sequential... 4532ms 14) 128kb, Sequential... 3843ms 15) 128kb, NoBuffering | Overlapped | Sequential... 3610ms 16) 128kb, Overlapped | Sequential... 3703ms 17) 256kb, NoBuffering... 4297ms 18) 256kb, Default... 4156ms 19) 256kb, NoBuffering | Overlapped... 3719ms 20) 256kb, Overlapped... 3640ms 21) 256kb, NoBuffering | Sequential... 4547ms 22) 256kb, Sequential... 3875ms 23) 256kb, NoBuffering | Overlapped | Sequential... 3610ms 24) 256kb, Overlapped | Sequential... 3656ms Top 5: 3610ms: 128kb, NoBuffering | Overlapped | Sequential 3610ms: 256kb, NoBuffering | Overlapped | Sequential 3640ms: 256kb, Overlapped 3640ms: 64kb, Overlapped 3641ms: 128kb, NoBuffering | Overlapped Worse 5: 4610ms: 64kb, NoBuffering | Sequential 4547ms: 256kb, NoBuffering | Sequential 4532ms: 128kb, NoBuffering | Sequential 4407ms: 64kb, NoBuffering 4328ms: 128kb, NoBuffering Starting: 1) 64kb, NoBuffering... 4359ms 2) 64kb, Default... 4328ms 3) 64kb, NoBuffering | Overlapped... 3656ms 4) 64kb, Overlapped... 3625ms 5) 64kb, NoBuffering | Sequential... 4641ms 6) 64kb, Sequential... 3859ms 7) 64kb, NoBuffering | Overlapped | Sequential... 3657ms 8) 64kb, Overlapped | Sequential... 3656ms 9) 128kb, NoBuffering... 4406ms 10) 128kb, Default... 4281ms 11) 128kb, NoBuffering | Overlapped... 3719ms 12) 128kb, Overlapped... 3656ms 13) 128kb, NoBuffering | Sequential... 4657ms 14) 128kb, Sequential... 3953ms 15) 128kb, NoBuffering | Overlapped | Sequential... 3609ms 16) 128kb, Overlapped | Sequential... 3656ms 17) 256kb, NoBuffering... 4297ms 18) 256kb, Default... 4250ms 19) 256kb, NoBuffering | Overlapped... 3656ms 20) 256kb, Overlapped... 3641ms 21) 256kb, NoBuffering | Sequential... 4625ms 22) 256kb, Sequential... 3875ms 23) 256kb, NoBuffering | Overlapped | Sequential... 3625ms 24) 256kb, Overlapped | Sequential... 3656ms Top 5: 3609ms: 128kb, NoBuffering | Overlapped | Sequential 3625ms: 64kb, Overlapped 3625ms: 256kb, NoBuffering | Overlapped | Sequential 3641ms: 256kb, Overlapped 3656ms: 64kb, NoBuffering | Overlapped Top 5: 3609ms: 128kb, NoBuffering | Overlapped | Sequential 3625ms: 64kb, NoBuffering | Overlapped | Sequential 3640ms: 256kb, NoBuffering | Overlapped | Sequential 3641ms: 64kb, Overlapped | Sequential 3641ms: 128kb, Overlapped Top 5: 3656ms: 128kb, Overlapped | Sequential 3657ms: 128kb, NoBuffering | Overlapped | Sequential 3657ms: 256kb, NoBuffering | Overlapped | Sequential 3672ms: 128kb, NoBuffering | Overlapped 3672ms: 256kb, NoBuffering | Overlapped

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

если есть идеи по минимизации "заплывов" - милости прошу озвучить

а лучше корректируйте тест (он с исходниками) - и выкладывайте

На ноутбуке

read_test.exe

Windows 7, unknown drive model Сигейт 5400 320ГБ

Top 5:
1185ms: 64kb, Overlapped | Sequential
1185ms: 128kb, Default
1185ms: 128kb, Sequential
1201ms: 64kb, Default
1201ms: 128kb, Overlapped | Sequential

Worse 5:
2075ms: 64kb, NoBuffering
1622ms: 64kb, NoBuffering | Sequential
1436ms: 128kb, NoBuffering
1404ms: 128kb, NoBuffering | Sequential
1404ms: 256kb, NoBuffering

write_test.exe

Windows 7, unknown drive model

Top 5:
4384ms: 256kb, Overlapped | WriteThrough
4430ms: 256kb, Overlapped | Sequential | WriteThrough
4743ms: 64kb, Overlapped | Sequential | WriteThrough
4930ms: 64kb, Overlapped | WriteThrough
5319ms: 256kb, Sequential | WriteThrough

Worse 5:
12340ms: 128kb, NoBuffering
11201ms: 64kb, NoBuffering
10343ms: 64kb, NoBuffering | Sequential
9485ms: 64kb, NoBuffering | Sequential | WriteThrough
9453ms: 64kb, Default

Ещё с одного компьютера

read_test.exe

Windows 7, unknown drive model 7200 120ГБ

Top 5:
2199ms: 64kb, Sequential
2200ms: 64kb, Default
2200ms: 256kb, Default
2215ms: 128kb, Default
2215ms: 128kb, Overlapped

Worse 5:
2636ms: 64kb, NoBuffering
2449ms: 256kb, NoBuffering
2278ms: 128kb, NoBuffering | Sequential
2262ms: 256kb, NoBuffering | Overlapped
2262ms: 64kb, NoBuffering | Sequential

write_test.exe

Windows 7, unknown drive model

Top 5:
4992ms: 256kb, Overlapped | Sequential | WriteThrough
5055ms: 256kb, Overlapped | WriteThrough
5741ms: 128kb, Overlapped | WriteThrough
5834ms: 128kb, Overlapped | Sequential | WriteThrough
6832ms: 256kb, Overlapped

Worse 5:
10499ms: 64kb, NoBuffering | Sequential | WriteThrough
10218ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough
10187ms: 64kb, NoBuffering | Overlapped | WriteThrough
10125ms: 64kb, NoBuffering | Overlapped
9968ms: 64kb, NoBuffering | WriteThrough

(hint: текущая ссылка http://zalil.ru/34271961)

All

У меня пока выводы такие. Что думаете ?

Чтение:

"новые винды" ( >= 7): Overlapped | Sequential
"старые винды": не могу понять "Overlapped | Sequential" или "NoBuffering | Overlapped | Sequential"

Запись:

Overlapped | Sequential | WriteThrough

кто что думает ?

Думаю, если не выпендриваться - 256 самое оно :)
Тест получился достаточно синтетический.

> Тест получился достаточно синтетический.

что в твоём понимании "несинтетический тест" ?
по моему очень приближённо к реальным условиям ?

один знак вопроса лишний )

← →
Sapersky (2013-02-19 08:39) [139]

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

Про запись: ну да, Overlapped | Sequential | WriteThrough. Но до меня сейчас дошло, что в реальном приложении никто не заставляет делать Flush после записи файла. В этом случае банальное "без флажков" (кэшированная запись) запишет не быстрее, но вернёт управление раньше. При условии, что приложение не пишет много и постоянно, как редактор видео, и кэш не переполняется.

Я помню, что сброс кэшей это моя идея, но меня больше чтение интересовало (которое таки да, часто бывает некэшированное). С записью - уже и сам не знаю. Конечно, несколько обидно возвращаться к тому, что тестировали в самом начале. Ну можно и WriteThrough оставить, тоже хороший вариант, особенно если начнёшь подряд писать несколько Гб.

Лови, коли надо. Винт Hitachi HDT721025SLA380

read_test.exe
We test different buffer sizes and options to read/parse files most fast
Testing file is "correct_file.txt" (about 100Mb)
Total sum of numbers must be equal 0x2904E86C0

Windows XP, unknown drive model

Starting:
1) 64kb, NoBuffering... 4875ms
2) 64kb, Default... 5891ms
3) 64kb, NoBuffering | Overlapped... 3640ms
4) 64kb, Overlapped... 4297ms
5) 64kb, NoBuffering | Sequential... 4515ms
6) 64kb, Sequential... 3875ms
7) 64kb, NoBuffering | Overlapped | Sequential... 3672ms
8) 64kb, Overlapped | Sequential... 3703ms
9) 128kb, NoBuffering... 4329ms
10) 128kb, Default... 4281ms
11) 128kb, NoBuffering | Overlapped... 3562ms
12) 128kb, Overlapped... 3657ms
13) 128kb, NoBuffering | Sequential... 4281ms
14) 128kb, Sequential... 3812ms
15) 128kb, NoBuffering | Overlapped | Sequential... 3672ms
16) 128kb, Overlapped | Sequential... 3578ms
17) 256kb, NoBuffering... 4235ms
18) 256kb, Default... 4328ms
19) 256kb, NoBuffering | Overlapped... 3594ms
20) 256kb, Overlapped... 3562ms
21) 256kb, NoBuffering | Sequential... 4328ms
22) 256kb, Sequential... 3766ms
23) 256kb, NoBuffering | Overlapped | Sequential... 3656ms
24) 256kb, Overlapped | Sequential... 3547ms

Top 5:
3547ms: 256kb, Overlapped | Sequential
3562ms: 256kb, Overlapped
3562ms: 128kb, NoBuffering | Overlapped
3578ms: 128kb, Overlapped | Sequential
3594ms: 256kb, NoBuffering | Overlapped

Worse 5:
5891ms: 64kb, Default
4875ms: 64kb, NoBuffering
4515ms: 64kb, NoBuffering | Sequential
4329ms: 128kb, NoBuffering
4328ms: 256kb, Default
__________________________________________________

write_test.exe
We test different buffer sizes and options to write files most fast
Destination file must be same as "correct_file.txt" (about 100Mb)

Windows XP, unknown drive model

Starting:
1) 64kb, Default... 3781ms
2) 64kb, Overlapped... 5578ms
3) 64kb, Sequential... 3640ms
4) 64kb, Overlapped | Sequential... 4704ms
5) 64kb, WriteThrough... 5531ms
6) 64kb, Overlapped | WriteThrough... 4937ms
7) 64kb, Sequential | WriteThrough... 5688ms
8) 64kb, Overlapped | Sequential | WriteThrough... 4297ms
9) 128kb, Default... 3515ms
10) 128kb, Overlapped... 4782ms
11) 128kb, Sequential... 3625ms
12) 128kb, Overlapped | Sequential... 4453ms
13) 128kb, WriteThrough... 4766ms
14) 128kb, Overlapped | WriteThrough... 3891ms
15) 128kb, Sequential | WriteThrough... 4828ms
16) 128kb, Overlapped | Sequential | WriteThrough... 5031ms
17) 256kb, Default... 3609ms
18) 256kb, Overlapped... 4766ms
19) 256kb, Sequential... 3437ms
20) 256kb, Overlapped | Sequential... 4516ms
21) 256kb, WriteThrough... 3891ms
22) 256kb, Overlapped | WriteThrough... 3453ms
23) 256kb, Sequential | WriteThrough... 4375ms
24) 256kb, Overlapped | Sequential | WriteThrough... 3688ms

Top 5:
3437ms: 256kb, Sequential
3453ms: 256kb, Overlapped | WriteThrough
3515ms: 128kb, Default
3609ms: 256kb, Default
3625ms: 128kb, Sequential

Worse 5:
5688ms: 64kb, Sequential | WriteThrough
5578ms: 64kb, Overlapped
5531ms: 64kb, WriteThrough
5031ms: 128kb, Overlapped | Sequential | WriteThrough
4937ms: 64kb, Overlapped | WriteThrough

> Труп Васи Доброго ©

спасиб

> Sapersky (19.02.13 08:39) [139]

> Про запись: ну да, Overlapped | Sequential | WriteThrough.
> Но до меня сейчас дошло, что в реальном приложении никто
> не заставляет делать Flush после записи файла. В этом случае
> банальное "без флажков" (кэшированная запись) запишет не
> быстрее, но вернёт управление раньше. При условии, что приложение
> не пишет много и постоянно, как редактор видео, и кэш не
> переполняется.

Так а "Overlapped | Sequential | WriteThrough" это и есть кешированная запись
или нет ?

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

это да...
но что лучше: "Sequential", "Overlapped | Sequential" или "NoBuffering | Overlapped | Sequential" ?

и самое важное :)
какой размер буфера брать ?

← →
Sapersky (2013-02-19 20:07) [142]

Так а "Overlapped | Sequential | WriteThrough" это и есть кешированная запись

Скорее некэшированная. Там что-то странное, как я понял, пишется сразу, но при этом кэшируется (на случай чтения):
http://support.microsoft.com/kb/99794/en-us
Поэтому и быстрее - диск сразу начинает писаться, параллельно (за счёт Overlapped) с твоим кодом; а без флагов сначала забивается кэш, потом ты пинаешь Flush, виндовс говорит "ах, да" и только тогда пишет файл.
Но если тебе пофиг, когда оно на самом деле запишется - то быстрее второй метод без Flush.

но что лучше: "Sequential", "Overlapped | Sequential" или "NoBuffering | Overlapped | Sequential" ?

Я ж говорю, по первому тесту чтения (из [97]) - просто Sequential, без всего. Но если ты второй считаешь более правильным (с большой нагрузкой на CPU) - тогда + Overlapped. Хотя мне кажется странным тестировать HDD, упираясь в CPU...

какой размер буфера брать ?

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

Надо было, пожалуй, группировать очень близкие (разница не более чем на 5%, скажем) результаты тестов. И/или как-то автоматизированно обрабатывать статистику, на глаз уже тяжело, когда много данных.
В идеале прогонять одни и те же настройки несколько раз, сравнивать результаты, отбрасывать экстремальные значения - как там положено по науке обрабатывать результаты экспериментов.

> DevilDevil © (18.02.13 22:23) [137]
> что в твоём понимании "несинтетический тест" ?

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

> Sapersky (19.02.13 20:07) [142]

В документации, конечно, разбросано все, но все же все написано. Наши волшебные тесты показывают, что ничего волшебного нет.

> Rouse_ © (19.02.13 21:24) [143]
>
> > DevilDevil © (18.02.13 22:23) [137]
> > что в твоём понимании "несинтетический тест" ?
>
> Дим, я думаю что у правильного теста значения плыть не должны.
>

Предлагаю удалить все программы, которые с диском общаются. Ну или установить много программ, которые активно работают с диском. :о)

> DevilDevil © (13.02.13 12:25) [2]
> > А зачем это все?
>
> для того чтобы сравнить различные способы записи в файл

Печалька. Скатились к тому, что тестируем размер буфера (который на скорость чтения/записи в разумных пределах практически не влияет). Пора переходить к написанию волшебной библиотеки.

> Rouse_ © (19.02.13 21:24) [143]

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

Саш :)
Лично я ничего странного не вижу в том, что результаты "плывут". Windows - многозадачная ОС, да ещё и частенько работает с несколькими ядрами, несколькими дисками. Задача - выявить оптимальные параметры. Тесты специально таким образом делаются - чтобы подзагрузить ЦПУ при чтении, и не очень загружать при записи.

Когда я представляю потоковое чтение файла, я представляю например большой текстовый файл, в котором нужно определить начала и длины строк, выделить для них место в куче, скопировать. Или например большой XML. Нужно не только читать данные из файла, но и на лету осуществлять его распарсивание. Выделяя опять таки данные в куче, копируя туда память, проводя различные инициализации. Ну или например какую-нибудь базу ;), в которой уложены разные идентификаторы, которые тоже нужно читать и укладывать в кучу.

А вот при потоковом чтении мне представляется другая картина. Если мы пишем текстовый файл - то все строки у нас уже есть. Пиши только данные строки да #13#10. Если мы сохраняем XML, то мы уже видим иерархию тегов - и пишем текст, иногда приводя строковые значения к строкам-xml. Если мы пишем базу - ещё проще. Все данные уже есть - пишем сразу данные.

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

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

Говорят в споре рождается истина. Но слово "спор" я считаю плохим. Давай прибегнем к другой пословице. "Одна голова хорошо - а две лучше". Или в данном случае сразу 10.

Поэтому выкладывайте свои тесты, с удовольствием протестирую. Если сделаешь такие что не плывут - будет замечательно. Или почти не плывут

> Владислав © (20.02.13 01:19) [144]

> Печалька. Скатились к тому, что тестируем размер буфера
> (который на скорость чтения/записи в разумных пределах практически
> не влияет). Пора переходить к написанию волшебной библиотеки.

В самом начале ветки был представлен тест записи стандартным способом, и буферизированным. Если бы разницы не было - я бы этот размер и набор опций не искал. Как мы видим, разница есть и в 2 и в 3 раза. А если писать вообще стандартным образом через TFileStream - получается опа

Поэтому лучше присоединяйся.

> Sapersky (19.02.13 20:07) [142]

я думаю мож запиндюрить одни и те же тесты по 3 раза
наверное будет лучше видна картина по "топам"

DevilDevil © (20.02.13 17:30) [145]

> В обоих случаях достаточно слабое звено - работа с файловой
> системой

работу с файловой системой прекрасно показывают утилиты от SysInternals,
в частности, они показывают причину:

> А если писать вообще стандартным образом через TFileStream
> - получается опа

> А я уже все сказал. В [57] и [72]

нууу... скучно
во-первых, ты не учитываешь разные опции, которые мы тут рассматриваем
во-вторых, ты игнорируешь многочисленные тесты, в которых явно видно, что отличия по производительности есть. Иногда даже в разы

Заметь, среди топов практически нет вариантов Default (т.е. без особых опций)
В конечном счёте задача одна - какие опции и размер буфера использовать в универсальной библиотеке для потокового чтения/записи. Чтобы раз выставить и уже не париться. Если считаешь, что размер буфера и опции должны зависеть от параметров, задаваемых пользователем - ok, какие это параметры и как они влияют на опции CreateFile(...)

DevilDevil © (20.02.13 23:37) [151]

> во-вторых, ты игнорируешь многочисленные тесты, в которых
> явно видно, что отличия по производительности есть. Иногда
> даже в разы

В моих тестах тоже есть отличия по производительности. Это и не тесты даже, а иллюстрации. И выводов ровно три:

1. Разумная буферизация улучшает быстродействие совокупности операций ввода-вывода.
2. Использование системного кэша улучшает быстродействие.
3. Серебряной пули нет

> во-первых, ты не учитываешь разные опции, которые мы тут
> рассматриваем

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

Теперь по сабжу:

Хочется тестировать быстродействие диска - надо тестировать без файловой системы. Диск устройство медленное, на перемещение механизма чтения/записи или на работу контроллера памяти в SSD (я деталей не знаю) требуется время. Если файл фрагментирован, на доступ к нему потребуется гарантировано больше времени при прочих равных, поэтому нельзя сказать, что в этом запуске сыграл нужный размер буфера, потому что время изменилось, возможно, для доступа к файлу потребовалось больше (или меньше) работы устройства хранения.

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

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

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

> Игорь Шевченко © (20.02.13 23:58) [152]

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

Удалено модератором

Качать здесь: http://zalil.ru/34316287
Новая идея заключается в том, чтобы все тесты прогнать несколько раз. Сейчас 4. Тогда несмотря на гуляния результатов, общая картина будет чётче

Intel i3-2120 3,30G Hz
Windows 7, WDC WD5000AAKX-001CA0

read_test.exe
Top 10: 2480ms: 256kb, Overlapped 2480ms: 256kb, Overlapped 2481ms: 128kb, Overlapped | Sequential 2481ms: 256kb, Overlapped | Sequential 2496ms: 256kb, Overlapped 2496ms: 64kb, Overlapped 2496ms: 128kb, NoBuffering | Overlapped 2496ms: 128kb, Overlapped 2496ms: 256kb, Overlapped | Sequential 2511ms: 128kb, NoBuffering | Overlapped

write_test.exe
Top 10: 2402ms: 128kb, Overlapped | WriteThrough 2402ms: 128kb, Overlapped | WriteThrough 2434ms: 256kb, Overlapped | Sequential | WriteThrough 2481ms: 64kb, Overlapped | WriteThrough 2511ms: 128kb, Overlapped | Sequential | WriteThrough 2512ms: 64kb, Overlapped | WriteThrough 2527ms: 64kb, Overlapped | WriteThrough 2527ms: 128kb, Overlapped | WriteThrough 2605ms: 128kb, Overlapped | Sequential | WriteThrough 2605ms: 64kb, Overlapped | WriteThrough

Удалено модератором

> [155] DevilDevil © (04.03.13 17:29)
> несмотря на гуляния результатов

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

> [159] DevilDevil © (04.03.13 20:41)
> давай свои цифры :)

Ну на, коль надо

read_test.exe

Windows 7, unknown drive model

Top 10:
2168ms: 256kb, Overlapped | Sequential
2184ms: 64kb, Overlapped
2199ms: 256kb, NoBuffering | Overlapped
2199ms: 64kb, NoBuffering | Overlapped
2199ms: 128kb, Overlapped
2199ms: 256kb, NoBuffering | Overlapped
2200ms: 64kb, Overlapped | Sequential
2200ms: 128kb, Overlapped
2200ms: 128kb, NoBuffering | Overlapped | Sequential
2200ms: 256kb, NoBuffering | Overlapped | Sequential

Worse 10:
3401ms: 64kb, NoBuffering
3229ms: 64kb, NoBuffering | Sequential
3214ms: 64kb, NoBuffering
3214ms: 64kb, NoBuffering
3213ms: 64kb, NoBuffering | Sequential
3198ms: 64kb, NoBuffering
3198ms: 64kb, NoBuffering | Sequential
3198ms: 64kb, NoBuffering | Sequential
3182ms: 128kb, NoBuffering | Sequential
3152ms: 128kb, NoBuffering | Sequential

write_test.exe

Windows 7, unknown drive model

Top 10:
2043ms: 256kb, Overlapped | WriteThrough
2043ms: 128kb, Overlapped | WriteThrough
2043ms: 128kb, Overlapped | Sequential | WriteThrough
2043ms: 256kb, Overlapped | Sequential | WriteThrough
2059ms: 256kb, Overlapped | Sequential | WriteThrough
2059ms: 128kb, Overlapped | WriteThrough
2059ms: 256kb, Overlapped | Sequential | WriteThrough
2090ms: 256kb, Overlapped | WriteThrough
2091ms: 128kb, Overlapped | WriteThrough
2106ms: 128kb, Overlapped | WriteThrough

Worse 10:
3853ms: 128kb, Overlapped
3791ms: 64kb, Overlapped | Sequential
3760ms: 64kb, WriteThrough
3713ms: 64kb, Overlapped | Sequential
3697ms: 64kb, Overlapped | Sequential
3666ms: 128kb, Overlapped
3635ms: 64kb, Overlapped
3557ms: 64kb, Sequential
3541ms: 256kb, Sequential
3541ms: 64kb, Default

> Inovet © (04.03.13 21:28) [161]

данкешон
зови друзей, пусть тоже выкладывают
и мне кажется достаточно Top-10 выкладывать

Удалено модератором
Примечание: Создание пустых сообщений

проц можно брать из самого проца (getcpuid), чтобы руками не писать.
ЗЫ на геймдеве запостил результаты

[b]antonn[/b]

спасибо!

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

Ребят, потестите пожалуйста Найти похожие ветки