![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hi, I have noticed very slow I/O performance in Windows XP while performing certain tasks, and I have been able to write a small test which reliably demonstrates the problem. I'd like to explain this problem and ask if anyone knows a workaround or set of tweaks to improve the situation. I create two large files (each too large to fit in memory, so they are not entirely cached), and attempt to read them back. When I read the files from beginning to end, one after the other, I get certain performance (around 35 MiB/s). When I change to reading each file in the same way, but read both files concurrently using threads, the performance drops to something miserable (around 1-2 MiB/s). While running the latter test I can hear my hard disk thrash heavily, it is clearly seeking backwards and forwards reading very little after each seek. The same test under Linux (same hardware) results in the parallel reads running only slightly slower than the sequential (around 32 MiB/s total throughput), and the disk is clearly seeking much less frequently. The same test on Mac OS X (different hardware) has the same characteristic as Linux. I have noticed this being a problem for real tasks. If I run any I/O intensive operation in the background while attempting any moderate I/ O in the foreground the performance is unbearable. This typically happens while compiling a large codebase. My setup is Windows XP SP2 with a bog standard SATA disk and 2GiB of RAM.. Does anyone know of any settings or tweaks I can apply to mitigate this problem? |
#3
| |||
| |||
|
|
The issue here is that UNIXes and UNIX-like OSes (such as Linux) have long been optimized for multiple users running processes in paralell. As an effect, reads are optimized and extensiv prefetching is done. After all, reading a bit more cost not much more time, but the seek is slow. Microsoft is (again) lagging behind by decades with its technology. They still expect you to run one thing only on your box. Annie shows himself to be a fucking moron yet again. |
|
The only reasonable solution I see is to put up separate disks for separate tasks, so that only one process is reading per disk. Or, alternatively, do your work on Linux ;-) Ignore the ignorant troll. |
#4
| |||
| |||
|
|
Hi, I have noticed very slow I/O performance in Windows XP while performing certain tasks, and I have been able to write a small test which reliably demonstrates the problem. I'd like to explain this problem and ask if anyone knows a workaround or set of tweaks to improve the situation. I create two large files (each too large to fit in memory, so they are not entirely cached), and attempt to read them back. When I read the files from beginning to end, one after the other, I get certain performance (around 35 MiB/s). When I change to reading each file in the same way, but read both files concurrently using threads, the performance drops to something miserable (around 1-2 MiB/s). Are you using buffered or unbuffered I/O? Buffered lets the OS do read-ahead. |
|
While running the latter test I can hear my hard disk thrash heavily, it is clearly seeking backwards and forwards reading very little after each seek. The same test under Linux (same hardware) results in the parallel reads running only slightly slower than the sequential (around 32 MiB/s total throughput), and the disk is clearly seeking much less frequently. The same test on Mac OS X (different hardware) has the same characteristic as Linux. |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |