сравнение 2-х TFileStream

← →
DVM © (2012-11-17 00:17) [40]

> bems © (16.11.12 21:08) [39]

> или вызывать CompareMem поблочно, но при этом блоки не
> копировать лишний раз

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

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

← →
bems © (2012-11-17 13:15) [41]

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

может блоки слишком маленькие брались?

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

да, на х32 могут быть проблемы с размером, но х64 будет жить дольше

← →
QAZ9 (2012-11-17 17:11) [42]

> Если память процесса представляет собой решето

а в х64 типа решета не будет? :)

← →
DVM © (2012-11-17 17:20) [43]

> QAZ9 (17.11.12 17:11) [42]

будет, но с более большими дырками, огромными.

← →
QAZ9 (2012-11-17 17:26) [44]

> DVM © (17.11.12 17:20) [43]

эммм...
ну было 2 гига памяти - стало 4, где огромность ?
как был через Ж написан софт в х32, так его и перекомпилили на х64
и?
на данный момент времени программисты деградируют быстрей чем развиваются производители железа, зато работают удобно и на расслабоне

← →
bems © (2012-11-17 17:35) [45]

стало не 4 гига а 256 байт в восьмой степени

← →
bems © (2012-11-17 17:36) [46]

вообще да, они деградируют

← →
QAZ9 (2012-11-17 17:48) [47]

> bems © (17.11.12 17:35) [45]

я не про диапазон адресов из википедии, а про стандартные бытовые компы которые продаются в магазине, было 2ядра\2гига , стало 4ядра\4гига

← →
DVM © (2012-11-17 17:49) [48]

> QAZ9 (17.11.12 17:26) [44]
>
> > DVM © (17.11.12 17:20) [43]
>
> эммм...
> ну было 2 гига памяти - стало 4, где огромность ?

во-первых, адресное пространство 32 бит программы - 4 гб, а не 2.
во-вторых, адресное пространство 64 бит программы - 48 бит в реале для AMD64 расширения (которое в интел тоже используется), а это 4 петабайта 256 терабайт.

← →
DVM © (2012-11-17 17:51) [49]

> QAZ9 (17.11.12 17:48) [47]
>
> > bems © (17.11.12 17:35) [45]
>
> я не про диапазон адресов из википедии, а про стандартные
> бытовые компы которые продаются в магазине, было 2ядра\2гига
> , стало 4ядра\4гига

причем тут это вообще.

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

← →
DVM © (2012-11-17 17:58) [50]

> DVM © (17.11.12 17:49) [48]

> 4 петабайта 256 терабайт.

правда в Windows есть еще свое ограничение, а именно вот http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx но все равно это 8 терабайт

← →
QAZ9 (2012-11-17 18:07) [51]

> DVM © (17.11.12 17:51) [49]

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

← →
DVM © (2012-11-17 18:13) [52]

> QAZ9 (17.11.12 18:07) [51]

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

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

← →
QAZ9 (2012-11-17 18:24) [53]

> того, кто проецирует

т.е. ленивого программиста которому надо проще а не лучше?

> есть больше адресов, куда можно спроецировать

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

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

← →
DVM © (2012-11-17 18:39) [54]

> QAZ9 (17.11.12 18:24) [53]

> > того, кто проецирует
>
> т.е. ленивого программиста которому надо проще а не лучше?
>

Использование MMF вовсе не проще и не лучше, чем их неиспользование. Что лучше, что хуже, надо решать в конкретном случае. Сами по себе MMF отличное средство во многих случаях.

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

И что? Фрагментируется именно виртуальное пространство, про физическое вообще речи не идет, т.к. мы с ним напрямую не работаем. В 32 бит системах фрагментация будет более выражена.

Я не понимаю, что ты ко мне пристал, что ты мне хочешь доказать?

Тот факт, что в 32 бит программах меньше шансов спроецировать даже 2 гб файл, чем в 64 бит сомнений не вызывает. Что еще?

← →
QAZ9 (2012-11-17 18:48) [55]

ну как?
тут же на форуме принято как минимум на 6 страниц разводить дискуссии до которых ТС уже давно наплевать :)
ты же МАСТЕР - должен знать уже ...

← →
bems © (2012-11-17 18:58) [56]

> я не про диапазон адресов из википедии, а про стандартные
> бытовые компы которые продаются в магазине

ограничение по реальной оперативе одинаково действует и на MMF и на ручное чтение. Проблемы с размером MMF вытекают только из количества доступных адресов.

Мне удалось забить $63B22D5F377 байт виртуального АП, да это далеко не 64 бита. Но и далеко не 32

← →
bems © (2012-11-17 19:06) [57]

> Проблемы с размером MMF вытекают только из количества доступных
> адресов.

непрерывных свободных адресов, конечно же

← →
QAZ9 (2012-11-17 19:32) [58]

> Мне удалось забить $63B22D5F377

что значит забить? и заметь, ключевое слово "виртуальное"

← →
bems © (2012-11-17 22:49) [59]

> что значит забить?

замаппить туда файл. Не всю память забивал единым куском, но при этом тесте я ставил цель проверить инфу DVM про 48 бит. Кажется он прав.

> и заметь, ключевое слово "виртуальное"

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

← →
DVM © (2012-11-17 23:08) [60]

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

Эээ. Если это про [40], то я же там про 32 бит говорил, в 64 бит пожалуйста, и терабайт замаппируется.

← →
bems © (2012-11-18 00:40) [61]

в [41] и я говорил что на х64 уже норм.
не, там выше товарисч утверждал сначала что и на х64 все плохо, потому что тоже самое решето (только на 4 гектара почему-то), потом говорил что там какое-то значение имеет физическая оператива и по сумме всего этого получалось что и на х64 они хуже чтения вручную.
Вот я собственно и доказываю что по скорости не хуже, а по размеру на х64 не хуже.

← →
QAZ9 (2012-11-18 17:10) [62]

> только на 4 гектара почему-то

это объем озу на котором стоит бо"льшая часть х64 ОСей на данный момент, всего лиш...

> Вот я собственно и доказываю что по скорости не хуже

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

← →
bems © (2012-11-19 03:54) [63]

> это объем озу на котором стоит бо"льшая часть х64 ОСей на
> данный момент, всего лиш...
это отфонарное значение, которое ты сказал неподумав

> у раз пошла такая пьянка давай код сравнения скорости ,проверим
моё утверждение основывается на том, что в обоих случаях одинаковое количество чтений с диска (при правильном размере буффера).
За кодом к DVM, он провёл сравнение и показал результаты

← →
Unknown1 (2012-11-19 10:35) [64]

> DVM © (16.11.12 15:09) [12]
>
> class function TStreamHelper.CompareStreams(A, B: TStream;
>
> BufferSize: Integer = DefStreamBufferSize): Boolean;
> var
> BufferA, BufferB: array of Byte;
> ByteCountA, ByteCountB: Longint;
> begin
> SetLength(BufferA, BufferSize);
> try
> SetLength(BufferB, BufferSize);
> try
> repeat
> ByteCountA := A.Read(BufferA[0], BufferSize);
> ByteCountB := B.Read(BufferB[0], BufferSize);
>
> Result := (ByteCountA = ByteCountB);
> Result := Result and CompareMem(BufferA, BufferB,
> ByteCountA);
> until (ByteCountA <> BufferSize) or (ByteCountB <>
> BufferSize) or not Result;
> finally
> SetLength(BufferB, 0);
> end;
> finally
> SetLength(BufferA, 0);
> end;
> end;
>
>

А зачем здесь SetLength(BufferB, 0); и SetLength(BufferA, 0);?

← →
DVM © (2012-11-19 11:07) [65]

> Unknown1 (19.11.12 10:35) [64]

> А зачем здесь SetLength(BufferB, 0); и SetLength(BufferA,
> 0);?

Привык убирать за собой.

Иногда бывает полезно даже для автоматически освобождаемых типов как например строки это делать. Если, например строка объявлена как threadvar S: string, то не выполнив для нее SetLength(S, 0); мы в конце получим утечку, о которой FastMem нам радостно сообщит.

← →
QAZ9 (2012-11-19 11:18) [66]

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

ага, интересно, значит у меня отфонарно, а ты у нас исключительно утверждаеш :) даже не проводя тест
и какой такой размер "правильный" , он в MMF вообще не задается :)

DVM давай код теста и параметры окружающей среды :)

← →
DVM © (2012-11-19 11:22) [67]

> QAZ9 (19.11.12 11:18) [66]

> DVM давай код теста и параметры окружающей среды :)

Все тебе дай, сам бы давно написал.

← →
DVM © (2012-11-19 11:24) [68]

Код для сравнения с помощью буфера выше. Соответственно нужен код, для маппинга файлов. Я использовал опять же свою обертку для MMF в виде TStream:

//////////////////////////////////////////////////////////////////////////////// // TCustomMappedStream //////////////////////////////////////////////////////////////////////////////// TCustomMappedStream = class(TStream) private FMapHandle: THandle; FFileHandle: THandle; FReadOnly: Boolean; FMemory: Pointer; FPosition, FSize: Int64; protected function CreateMapView(APageSize: Int64; AName: PChar = nil): Int64; procedure CloseMapView; public function Read(var Buffer; Count: Longint): Longint; override; function Seek(const Offset: Int64; Origin: TSeekOrigin): Int64; override; property Memory: Pointer read FMemory; property MapHandle: THandle read FMapHandle; property FileHandle: THandle read FFileHandle; property ReadOnly: Boolean read FReadOnly; end; //////////////////////////////////////////////////////////////////////////////// // TFileMappedStream //////////////////////////////////////////////////////////////////////////////// TFileMappedStream = class(TCustomMappedStream) private FFilename: String; protected procedure SetSize(NewSize: Longint); overload; override; procedure SetSize(const NewSize: Int64); overload; override; public constructor Create(const Filename: String; Mode: Word); destructor Destroy; override; function Write(const Buffer; Count: Longint): Longint; override; procedure Clear; end; resourcestring rsNoDataAvailable = "No data available."; rsCannotAccessMemoryData = "Cannot access memory data."; ..... //////////////////////////////////////////////////////////////////////////////// // TCustomMappedStream //////////////////////////////////////////////////////////////////////////////// function TCustomMappedStream.CreateMapView(APageSize: Int64; AName: PChar = nil): Int64; var Inf: TMemoryBasicInformation; begin if APageSize = 0 then APageSize := 1; if not Readonly then FMapHandle := CreateFileMapping(FFileHandle, nil, PAGE_READWRITE, 0, APageSize, AName) else FMapHandle := CreateFileMapping(FFileHandle, nil, PAGE_READONLY, 0, APageSize, AName); Win32Check(FMapHandle <> 0); if not FReadOnly then FMemory := MapViewOfFile(FMapHandle, FILE_MAP_READ or FILE_MAP_WRITE, 0, 0, 0) else FMemory := MapViewOfFile(FMapHandle, FILE_MAP_READ, 0, 0, 0); if (Assigned(FMemory)) and (AName = nil) then Result := APageSize else if (Assigned(FMemory)) and (Assigned(AName)) then begin VirtualQuery(FMemory,inf,SizeOf(TMemoryBasicInformation)); Result := inf.RegionSize; end else raise EStreamError.Create(SysErrorMessage(GetLastError)); end; //------------------------------------------------------------------------------ procedure TCustomMappedStream.CloseMapView; begin if Memory <> nil then UnmapViewOfFile(Memory); if FMapHandle <> 0 then CloseHandle(FMapHandle); end; //------------------------------------------------------------------------------ function TCustomMappedStream.Read(var Buffer; Count: Integer): Longint; begin if FMemory <> nil then begin if FPosition + Count > Size then Count := FSize - FPosition; Move(Pointer(PtrInt(FMemory) + FPosition)^, Buffer, Count); Inc(FPosition, Count); Result := Count; end else raise EStreamError.Create(rsNoDataAvailable); end; //------------------------------------------------------------------------------ function TCustomMappedStream.Seek(const Offset: Int64; Origin: TSeekOrigin): Int64; begin case Origin of soBeginning: FPosition := Offset; soCurrent : FPosition := FPosition + Offset; soEnd : FPosition := FSize + Offset; end; Result := FPosition; end; //////////////////////////////////////////////////////////////////////////////// // TFileMappedStream //////////////////////////////////////////////////////////////////////////////// constructor TFileMappedStream.Create(const Filename: String; Mode: Word); const Access: array[0..4] of Cardinal = (GENERIC_READ, GENERIC_WRITE, GENERIC_READ or GENERIC_WRITE, GENERIC_READ or GENERIC_WRITE, GENERIC_READ or GENERIC_WRITE); CreateFlag: array[0..4] of Cardinal = (OPEN_EXISTING, OPEN_EXISTING, OPEN_EXISTING, CREATE_ALWAYS, CREATE_ALWAYS); var FileFlag: Cardinal; begin inherited Create; FFilename := Filename; FReadOnly := Mode = 0; if Mode = fmCreate then Mode := 3; if Mode <> 4 then FileFlag := FILE_ATTRIBUTE_NORMAL else FileFlag := FILE_FLAG_DELETE_ON_CLOSE; FFileHandle := CreateFile(PChar(FFilename), Access[Mode], 0, nil, CreateFlag[Mode], FileFlag, 0); Win32Check(FFileHandle <> INVALID_HANDLE_VALUE); FSize := CreateMapView(GetFileSize(FFileHandle, nil)); end; //------------------------------------------------------------------------------ procedure TFileMappedStream.SetSize(NewSize: Integer); begin SetSize(Int64(NewSize)); end; //------------------------------------------------------------------------------ procedure TFileMappedStream.SetSize(const NewSize: Int64); begin CloseMapView; SetFilePointer(FFileHandle, NewSize, nil, FILE_BEGIN); SetEndOfFile(FFileHandle); FSize := CreateMapView(NewSize); end; //------------------------------------------------------------------------------ destructor TFileMappedStream.Destroy; begin CloseMapView; CloseHandle(FFileHandle); inherited Destroy; end; //------------------------------------------------------------------------------ function TFileMappedStream.Write(const Buffer; Count: Integer): Longint; begin if (FMemory <> nil) and (not Readonly) then begin if (FPosition + Count > FSize) then SetSize(FPosition+Count); Move(Buffer,Pointer(PtrInt(FMemory) + FPosition)^,Count); inc(FPosition,Count); Result := Count; end else raise EStreamError.Create(rsCannotAccessMemoryData); end; //------------------------------------------------------------------------------ procedure TFileMappedStream.Clear; begin SetSize(0); FPosition := 0; end;

Сам код тестирования я не сохранял, там кода то 5 строчек.

Кому обертки не нравятся я не настаиваю.

← →
QAZ9 (2012-11-19 12:18) [70]

так не интересно :( надо готовый проект в архивчике

> ага, интересно, значит у меня отфонарно, а ты у нас исключительно
> утверждаеш :) даже не проводя тест
> и какой такой размер "правильный" , он в MMF вообще не задается
> :)
размер задаётся при ручном чтении, и когда он правильный достигает быстродействия MMF
Ну конечно число у тебя отфонарное. Хотя бы потому что тебе уже показали что размер реальной оперативы не влияет на MMF (вернее влияет, но не более чем и на ручное чтение).
Про то что 4 гигабайта это и для физической оперативы средняя температура по больнице.
Короч хватит, вывод из обсуждения уже давно очевиден, а ты всё трепыхаешься

> При размере буфера 64к скорости сравнялись. До 64к сравнение
> отображенных в память было быстрее, чем по блокам.

а если по 2 гб ?

> DevilDevil © (27.11.12 00:25) [72]

> а если по 2 гб ?

Буфер на 2 Гб? Это в 32 бит системе еще надо постараться распределить. Речь о вот этом же временном буфере то, а не о всем файле:

class function TStreamHelper.CompareStreams(A, B: TStream; BufferSize: Integer = DefStreamBufferSize): Boolean; var BufferA, BufferB: array of Byte; ByteCountA, ByteCountB: Longint; begin SetLength(BufferA, BufferSize); // <<= этот буфер try SetLength(BufferB, BufferSize); // <<= и этот try repeat ByteCountA := A.Read(BufferA[0], BufferSize); ByteCountB := B.Read(BufferB[0], BufferSize); Result := (ByteCountA = ByteCountB); Result := Result and CompareMem(BufferA, BufferB, ByteCountA); until (ByteCountA <> BufferSize) or (ByteCountB <> BufferSize) or not Result; finally SetLength(BufferB, 0); end; finally SetLength(BufferA, 0); end; end;

← →
QAZ9 (2012-11-27 11:48) [74]

наилучший по скорости чтения размер буфера при чтении с хардов 256 Кб

> DVM © (27.11.12 11:43) [73]

я говорю как с помощью Mapped сравнить 2 файла размером 2гб ?
эффективно ли это будет, на сколько затратно по ОЗУ

> при чтении с хардов 256 Кб

с чего бы?

> DevilDevil © (27.11.12 14:11) [75]

> я говорю как с помощью Mapped сравнить 2 файла размером
> 2гб ?

В 32 бит никак. Не хватит виртуального адресного пространства.
В 64 бит все нормально сравнивается. Собственно я и сравнивал примерно такие файлы.

> на сколько затратно по ОЗУ

Смотря что понимать под ОЗУ. Если виртуальное адресное пространство, то его израсходуется около 4 гб, реального физического же совсем мало.

← →
anatoly pogoretsky (2012-11-27 17:42) [78]

> DVM (27.11.2012 16:35:17) [77]

Ты не пугай

HANDLE WINAPI CreateFileMapping(
_In_ HANDLE hFile,
_In_opt_ LPSECURITY_ATTRIBUTES lpAttributes,
_In_ DWORD flProtect,
_In_ DWORD dwMaximumSizeHigh,
_In_ DWORD dwMaximumSizeLow,
_In_opt_ LPCTSTR lpName
);

LPVOID WINAPI MapViewOfFile(
_In_ HANDLE hFileMappingObject,
_In_ DWORD dwDesiredAccess,
_In_ DWORD dwFileOffsetHigh,
_In_ DWORD dwFileOffsetLow,
_In_ SIZE_T dwNumberOfBytesToMap
);

Ограничение на размер файла 2^64, просто работать придется кусками, виртуальное пространство не ограничивает.

> anatoly pogoretsky (27.11.12 17:42) [78]
> > DVM (27.11.2012 16:35:17) [77]
>
> Ты не пугай
>

> Ограничение на размер файла 2^64, просто работать придется
> кусками, виртуальное пространство не ограничивает.

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

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

сравнение 2-х TFileStream Найти похожие ветки