On Thursday, 22 March 2012 at 04:29:41 UTC, Jay Norwood wrote:
> On the use of larger files ... yes that will be interesting, but for these current measurements  the file reads are only taking on the order of 30ms for 20MB, which tells me they are already either being cached by win7, or else by the ssd's cache.
>
>  I'll use the article instructions below and put the files being read into the cache prior to the test,  so that the file read time  should be small and consistent relative to the other buffer processing time inside the loops.
>
> http://us.generation-nt.com/activate-windows-file-caching-tip-tips-tricks-2130881-0.html
>
>
> Thanks

I tried using a ramdisk from imdisk, because the above article was just for caching network drives to your local disk.  The first set of times are from the ssd, the second from the ram disk, and both are about the same.  So I guess win7 is caching these file reads already.

I got imdisk for the ramdisk here
http://www.ltr-data.se/opencode.html/#ImDisk


These are the times for the imdisk reads (still executing from G hard drive , but reading from F ram disk)
G:\d\a7\a7\Release>wctest f:\al*.txt
finished wcp_nothing! time: 1 ms
finished wcp_whole_file! time: 31 ms
finished wcp_byLine! time: 525 ms
finished wcp_byChunk! time: 22 ms
finished wcp_lcByChunk! time: 33 ms
finished wcp_lcDcharByChunk! time: 30 ms
finished wcp_lcRegex! time: 141 ms
finished wcp_lcCtRegex! time: 104 ms
finished wcp_lcStdAlgoCount! time: 139 ms
finished wcp_lcChar! time: 37 ms
finished wcp_wcPointer! time: 121 ms
finished wcp_wcCtRegex! time: 1269 ms
finished wcp_wcRegex! time: 2908 ms
finished wcp_wcRegex2! time: 2693 ms
finished wcp_wcSlices! time: 179 ms
finished wcp_wcStdAscii! time: 222 ms

This is reading from the ssd Intel 510 series 120GB
G:\d\a7\a7\Release>wctest h:\al*.txt
finished wcp_nothing! time: 1 ms
finished wcp_whole_file! time: 32 ms
finished wcp_byLine! time: 518 ms
finished wcp_byChunk! time: 23 ms
finished wcp_lcByChunk! time: 33 ms
finished wcp_lcDcharByChunk! time: 31 ms
finished wcp_lcRegex! time: 159 ms
finished wcp_lcCtRegex! time: 89 ms
finished wcp_lcStdAlgoCount! time: 144 ms
finished wcp_lcChar! time: 34 ms
finished wcp_wcPointer! time: 118 ms
finished wcp_wcCtRegex! time: 1273 ms
finished wcp_wcRegex! time: 2889 ms
finished wcp_wcRegex2! time: 2688 ms
finished wcp_wcSlices! time: 175 ms
finished wcp_wcStdAscii! time: 220 ms

I added the source and the test text files on github

https://github.com/jnorwood/wc_test

On Monday, 26 March 2012 at 07:10:00 UTC, Jay Norwood wrote:
> On Thursday, 22 March 2012 at 04:29:41 UTC, Jay Norwood wrote:
>> On the use of larger files ... yes that will be interesting, but for these current measurements  the file reads are only taking on the order of 30ms for 20MB, which tells me they are already either being cached by win7, or else by the ssd's cache.
>>
>> I'll use the article instructions below and put the files being read into the cache prior to the test,  so that the file read time  should be small and consistent relative to the other buffer processing time inside the loops.
>>
>> http://us.generation-nt.com/activate-windows-file-caching-tip-tips-tricks-2130881-0.html
>>
>>
>> Thanks
>
> I tried using a ramdisk from imdisk, because the above article was just for caching network drives to your local disk.  The first set of times are from the ssd, the second from the ram disk, and both are about the same.  So I guess win7 is caching these file reads already.
>
> I got imdisk for the ramdisk here
> http://www.ltr-data.se/opencode.html/#ImDisk
>
>
> These are the times for the imdisk reads (still executing from G hard drive , but reading from F ram disk)
> G:\d\a7\a7\Release>wctest f:\al*.txt
> finished wcp_nothing! time: 1 ms
> finished wcp_whole_file! time: 31 ms
> finished wcp_byLine! time: 525 ms
> finished wcp_byChunk! time: 22 ms
> finished wcp_lcByChunk! time: 33 ms
> finished wcp_lcDcharByChunk! time: 30 ms
> finished wcp_lcRegex! time: 141 ms
> finished wcp_lcCtRegex! time: 104 ms
> finished wcp_lcStdAlgoCount! time: 139 ms
> finished wcp_lcChar! time: 37 ms
> finished wcp_wcPointer! time: 121 ms
> finished wcp_wcCtRegex! time: 1269 ms
> finished wcp_wcRegex! time: 2908 ms
> finished wcp_wcRegex2! time: 2693 ms
> finished wcp_wcSlices! time: 179 ms
> finished wcp_wcStdAscii! time: 222 ms
>
> This is reading from the ssd Intel 510 series 120GB
> G:\d\a7\a7\Release>wctest h:\al*.txt
> finished wcp_nothing! time: 1 ms
> finished wcp_whole_file! time: 32 ms
> finished wcp_byLine! time: 518 ms
> finished wcp_byChunk! time: 23 ms
> finished wcp_lcByChunk! time: 33 ms
> finished wcp_lcDcharByChunk! time: 31 ms
> finished wcp_lcRegex! time: 159 ms
> finished wcp_lcCtRegex! time: 89 ms
> finished wcp_lcStdAlgoCount! time: 144 ms
> finished wcp_lcChar! time: 34 ms
> finished wcp_wcPointer! time: 118 ms
> finished wcp_wcCtRegex! time: 1273 ms
> finished wcp_wcRegex! time: 2889 ms
> finished wcp_wcRegex2! time: 2688 ms
> finished wcp_wcSlices! time: 175 ms
> finished wcp_wcStdAscii! time: 220 ms
>
> I added the source and the test text files on github
>
> https://github.com/jnorwood/wc_test




I downloaded and tried your benchmark. I first tried it
with the ten 10Mb files that you put in github, then
truncated them to 2Mb to get results comparable to
the test you said did.

* Used dmd 2.058.

* I tested both Windows7 64bit and then booted
into Linux Kubuntu 64bits to test there too.

* I tested in the following desktop computer, previously
disabling cpu throttling (disabled cool&quiet in the bios setup).

vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping        : 1
cpu MHz         : 2109.443
cache size      : 512 KB

* The computer has 4Gb of RAM.

* Runned wcTest many times (more than 10) before saving
the results.

Results in Windows7 x64 with ten 10Mb files:
-------------------------------------------
finished wcp_nothing! time: 1 ms
finished wcp_whole_file! time: 130 ms
finished wcp_byLine! time: 1574 ms
finished wcp_byChunk! time: 133 ms
finished wcp_lcByChunk! time: 207 ms
finished wcp_lcDcharByChunk! time: 181 ms
finished wcp_lcRegex! time: 579 ms
finished wcp_lcCtRegex! time: 365 ms
finished wcp_lcStdAlgoCount! time: 511 ms
finished wcp_lcChar! time: 188 ms
finished wcp_wcPointer! time: 438 ms
finished wcp_wcCtRegex! time: 5448 ms
finished wcp_wcRegex! time: 17277 ms
finished wcp_wcRegex2! time: 15524 ms
finished wcp_wcSlices! time: 632 ms
finished wcp_wcStdAscii! time: 814 ms


Results in Windows7 x64 with ten 2Mb files:
-------------------------------------------
finished wcp_nothing! time: 1 ms
finished wcp_whole_file! time: 27 ms
finished wcp_byLine! time: 329 ms
finished wcp_byChunk! time: 34 ms
finished wcp_lcByChunk! time: 79 ms
finished wcp_lcDcharByChunk! time: 79 ms
finished wcp_lcRegex! time: 298 ms
finished wcp_lcCtRegex! time: 150 ms
finished wcp_lcStdAlgoCount! time: 216 ms
finished wcp_lcChar! time: 77 ms
finished wcp_wcPointer! time: 127 ms
finished wcp_wcCtRegex! time: 3250 ms
finished wcp_wcRegex! time: 6164 ms
finished wcp_wcRegex2! time: 5724 ms
finished wcp_wcSlices! time: 171 ms
finished wcp_wcStdAscii! time: 194 ms


Results in Kubuntu 64bits with ten 2Mb files:
----------------------------------------------
finished wcp_nothing! time: 0 ms
finished wcp_whole_file! time: 28 ms
finished wcp_byLine! time: 212 ms
finished wcp_byChunk! time: 20 ms
finished wcp_lcByChunk! time: 90 ms
finished wcp_lcDcharByChunk! time: 77 ms
finished wcp_lcRegex! time: 190 ms
finished wcp_lcCtRegex! time: 108 ms
finished wcp_lcStdAlgoCount! time: 132 ms
finished wcp_lcChar! time: 71 ms
finished wcp_wcPointer! time: 159 ms
finished wcp_wcCtRegex! time: 2308 ms
finished wcp_wcRegex! time: 4382 ms
finished wcp_wcRegex2! time: 3819 ms
finished wcp_wcSlices! time: 171 ms
finished wcp_wcStdAscii! time: 296 ms


Results in Kubuntu 64bits with ten 10Mb files:
----------------------------------------------
finished wcp_nothing! time: 0 ms
finished wcp_whole_file! time: 104 ms
finished wcp_byLine! time: 958 ms
finished wcp_byChunk! time: 85 ms
finished wcp_lcByChunk! time: 340 ms
finished wcp_lcDcharByChunk! time: 345 ms
finished wcp_lcRegex! time: 911 ms
finished wcp_lcCtRegex! time: 434 ms
finished wcp_lcStdAlgoCount! time: 614 ms
finished wcp_lcChar! time: 340 ms
finished wcp_wcPointer! time: 558 ms
finished wcp_wcCtRegex! time: 11300 ms
finished wcp_wcRegex! time: 19368 ms
finished wcp_wcRegex2! time: 17721 ms
finished wcp_wcSlices! time: 796 ms
finished wcp_wcStdAscii! time: 1216 ms


About the cache:
----------------
Each I/O operation carries also overhead not mitigated by
the cache. Depending on the OS, kernel, and filesystem,
every syscall that deals with I/O might or might not acquire
a mutex or wait on a mutex. Your process is not the only
one doing I/O, and might not be the only one accessing
a filesystem object or attribute, or reading or writing
to the memory disk cache's entries.


About byChunk vs std.file.read;
-------------------------------
Well, surprises are fun! In windows I got them about
the same in the ten 10Mb files test (depending on the run,
wcp_byChunk was below or above wcp_whole_file).
    But, in linux, I got wcp_byChunk consistently faster than
wcp_whole_file. I even inverted the order in which they
are tested to see if there was any effect there, and it
was the same. Though the difference shrank (in percentage)
when testing 10Mb files instead of 2Mb files.
    I'd like to change the benchmark to make automatic
repetitions and get the standard deviation, but I first
wanted to run it as is.
    I would jump to conclude that in the desktop computer I tested,
byChunk and std.file.read are the same in windows, and byChunk
is faster in Linux, but very little faster (might or might not
be explained by the extra stat call that it does to get the size
before reading).
    But since I didn't add repetitions, averaging and standard
deviation to your test, I can't really conclude anything for those
two (bychunk and std.file.read) which are too close.


-inline
-------
I tried to compile with -inline, but got 0ms for all the
tests. This is because there is a bug in the globbed overload
version of dirEntries() (or in the globbed matcher).
I don't know if it has been reported already.

--jm

On Tuesday, 27 March 2012 at 00:23:46 UTC, Juan Manuel Cabo wrote:
[....]

I forgot to mention that for Linux Kubuntu x64 I had to put
change the type of a variable to auto in this line of wcTest.d:
   auto c_cnt = input.length;
And that in windows7 x64, the default for dmd is -m32, so I
compiled and tried your benchmark that way in windows.

--jm

On Tuesday, 27 March 2012 at 00:23:46 UTC, Juan Manuel Cabo wrote:
 > I downloaded and tried your benchmark. I first tried it
> with the ten 10Mb files that you put in github, then
> truncated them to 2Mb to get results comparable to
> the test you said did.
 > --jm

All my times were with the 10 10MB files that I uploaded.  I tried on ssd, on hd and on an imdisk ramdrive, and got about the same times for all. I suppose win7 is caching these.   I'd expect several of the measured times  to be dominated by disk read time if they weren't somehow being cached.

Thanks for testing on the other systems.