Main Area and Open Discussion > Living Room
Use video RAM as a swap disk?
f0dder:
Ah, but you are writing one char at a time. As stated previously, check your CPU usage, especially the time spent in kernelmode...
Crush:
Here´s the kernalmode usage with normal IO (CFile normal in ~10 second bench):
Results for User Mode Process BENCHMARKER.EXE (PID = 3180)
User Time = 1.73% of the Elapsed Time // the time used by the program itself is very small
Kernel Time = 48.11% of the Elapsed Time // a rather big kernalmode usage!!!
Total Avg. Rate
Page Faults , 0, 0/sec.
I/O Read Operations , 0, 0/sec.
I/O Write Operations , 2779646, 268322/sec.
I/O Other Operations , 0, 0/sec.
I/O Read Bytes , 0, 0/ I/O
I/O Write Bytes , 2779646, 1/ I/O // the IO-Scanner shows that the bytes are written seperately with no cache!
I/O Other Bytes , 0, 0/ I/O
OutputResults: ProcessModuleCount (Including Managed-Code JITs) = 22
Percentage in the following table is based on the Total Hits for this Process
Time 196 hits, 25000 events per hit --------
Module Hits msec %Total Events/Sec
ntdll 117 10359 59 % 282363 // too much
kernel32 48 10359 24 % 115841 // too much
MFC80U 27 10359 13 % 65160 // too much
Benchmarker 4 10359 2 % 9653 // ok
And here are the results with QuickFile (write caching in ~10 second bench)
Results for User Mode Process BENCHMARKER.EXE (PID = 4028)
User Time = 19.27% of the Elapsed Time // The main cpu time is spend for the program itself, that´s fine
Kernel Time = 1.79% of the Elapsed Time // This is something I can accept
Total Avg. Rate
Page Faults , 0, 0/sec.
I/O Read Operations , 0, 0/sec.
I/O Write Operations , 2749, 274/sec. // the caching leads to less hardware write actions
I/O Other Operations , 0, 0/sec.
I/O Read Bytes , 0, 0/ I/O
I/O Write Bytes , 180158464, 65536/ I/O // here you see my standard IO-cacheblock size (0x10000)
I/O Other Bytes , 0, 0/ I/O
Time 1576 hits, 25000 events per hit --------
Module Hits msec %Total Events/Sec
Benchmarker 961 10015 60 % 2398901 // great! most time is spend to create the cache!
MSVCR80 614 10015 38 % 1532700 // I think this cpu time is used by the CFile-Class itself
ntdll 1 10015 0 % 2496 // this is acceptable :D
This shows that writecache releases the kernal32 & ntdll - there is definately some kinds of caches are active in WinXP with ntfs, but its not very effective in write actions with small portions. The coders of M$ perhaps concentrated in optimizing read-caching more than writing. I´d like to know how Linux filesystems would perform in such a test.
f0dder:
You're interpreting the results wrongly - your bottleneck is certainly the user<>kernel switching, very evident with such a high kernel usage in the first test. The filesystem caches are efficient enough, but writing one byte at a time has never been a good idea :)
Crush:
I have no idea how to reduce the usermode<>kernalmode switching without an own buffer. Do you have a simple solution?
Nevertheless, I´ll use my own caching-system in the future and don´t trust in the "normal" filesystem too much. Let´s next see how caching with VMem will work compared to normal memory.
f0dder:
I have no idea how to reduce the usermode<>kernalmode switching without an own buffer. Do you have a simple solution?
Nevertheless, I´ll use my own caching-system in the future and don´t trust in the "normal" filesystem too much. Let´s next see how caching with VMem will work compared to normal memory.
-Crush (October 13, 2007, 06:21 PM)
--- End quote ---
Simple solution: do larger writes - user your own buffer is one decent way to do larger writes. But you can probably find other ways to increase efficiency as well (ie., don't write an integer at a time, write out chunks of integers from your array).
Caching with video memory is going to be slower than normal memory, transfers there are a bit more expensive... especially if you're stuck with AGP instead of PCI-e, sinced AGP readbacks are slooooow.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version