March 26, 2012 Re: some regex vs std.ascii vs handcode times | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jay Norwood | 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 |
March 27, 2012 Re: some regex vs std.ascii vs handcode times | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jay Norwood | 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 |
March 27, 2012 Re: some regex vs std.ascii vs handcode times | ||||
---|---|---|---|---|
| ||||
Posted in reply to Juan Manuel Cabo | 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 |
March 27, 2012 Re: some regex vs std.ascii vs handcode times | ||||
---|---|---|---|---|
| ||||
Posted in reply to Juan Manuel Cabo | 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.
|
Copyright © 1999-2021 by the D Language Foundation