Windows System Programming Third Edition [Electronic resources]

While the results are averages of five test runs, the elapsed time can vary widely. For example, cpUC (last row), with an average of 7.71 seconds in the third column (W2000 laptop), had a minimum elapsed time of 1.87 seconds and a maximum of 11.71 seconds. This wide variation was typical of nearly all the cases on all the systems.

Comments

1. The NTFS does not necessarily give better performance than the FAT file system. On the contrary, the FAT can be faster, as can be seen by comparing columns 1 and 2.

2. The C and UNIX compatibility libraries give competitive performance that is superior to the simplest Windows implementation in many cases.

3. CPU time, both kernel ("System") and user, are minimal. Consequently, processor speed has very little impact on the elapsed time performance.

4. High-end SMP server systems do produce fast file processing compared to laptops and PCs, as would be expected. Informal tests on a faster W2003 system produced even better results (not shown here), with elapsed times about half those of the right-most column.

5. There are no consistent or significant elapsed time performance advantages obtained by using large buffers, sequential scan flags, or a function such as CopyFile. However, the very small user times for cpwFA and cpCF are interesting and potentially helpful in some situations, even if they do not improve elapsed time. One system, the Pentium laptop, is an exception to this generalization. As mentioned earlier, CPU time is a small part of the elapsed time.

6. Elapsed time results are highly variable, with as much as a 10:1 difference between identical tests run under identical circumstances.

ASCII to Unicode Conversion

Eight programs were measured, all converting the same 12.8MB file to a 25.6MB file. Program 2-4 and is comparable to cpW using a small buffer.Program 5-3.Chapter 14's multiple buffer scheme without asynchronous I/O.

Comments

1. These results show that there is a small advantage to using large buffers and the sequential scan flags, possibly in conjunction.

2. Presizing the output file (atouLSFP) is very effective, giving dramatic performance improvements on all the single-processor systems. The SMP benefits, however, were marginal. This technique could also be used with the previous file copying examples.

3. CPU time is insignificant in these tests.

4. Overlapped I/O, in addition to being limited to Windows NT and very difficult to program, gives poor performance. Notice that the time is predominantly real time and not user or system time. Using NT4, it appears that the system has difficulty scheduling the disk access, and experiments with different buffer sizes (larger and smaller) did not help until 65K buffers were used. NT5 has eliminated this problem.

5. Extended I/O and multiple threads do not provide any significant benefit.

6. Memory-mapped I/O can give very good performance, usually about 30 percent faster than the other versions. The SMP server results were even better.

Pattern Searching

Three pattern searching methods were tested to compare the efficiencies of multiple threads and processes as well as sequential processing (see Program 6-1, searches with parallel processes, each processing a separate file. The system and user times are not given, because timep measures only the parent process.Program 7-1, uses parallel threads.

The 20 target files used in the test vary in size from a few kilobytes to more than one megabyte.

Comments

1. In most cases, all three techniques provide similar results on single-processor systems. The Pentium laptop is an exception, where grepMP version was consistently slow.

2. Multithreading offers a slight advantage over multiple processes, even on single-processor systems.

3. User and system times are only meaningful in the multithreaded version.

4. SMP systems show the performance gains that are possible using threads or multiple single-threaded processes. Notice that the total user time exceeds the real time because the user time represents all four processors.

5. The fact that the sequential processing gave such similar results on single-processor systems indicates that the simplest solution is sometimes the best.

File Sorting

A target sort file of 100,000 64-byte records (6.4MB) was used to test four sort implementations from Chapter 5, as shown in the first four rows in Program 7-2, of a 25MB file with 400,000 64-byte records was tested with one, two, and four threads. Each individual run used a different file, created by the RandFile program that is in the Chapter 5 directory. There was considerable variation from one run to the next.

1. sortBT is Program 5-1, which creates a binary search tree, requiring a memory allocation for each record. This program is CPU-intensive.Program 5-4, which maps the file before using qsort. sortFLSR (heap access was serialized) was also tested but showed no measurable difference.Program 5-5, which creates a permanent index file.Program 7-2, the multithreaded sort-merge. The results are shown as sortMT1, sortMT2, and sortMT4, according to the number of parallel threads. Results can differ significantly depending on the nature of the data in the file to be sorted, although the size and randomness of the data minimizes this variation, which, in general, is a characteristic of the underlying quicksort algorithm used to implement the qsort C library function.

Comments

1. The binary tree implementation, sortBT, is CPU-intensive; it must allocate storage for each record one at a time.

2. Memory mapping and reading the file into a preallocated buffer yield similar performance, but the memory mapping was not as good in these tests, and, in several cases, was considerably worse. However, sortFL and sortHP gave some excellent results.

3. The total of user and system times sometimes exceeds the elapsed time, even when using a single thread.

4. sortMT demonstrates the potential of SMP systems. Additional threads also helped, in some cases, on single-processor systems.

Multiple Threads Contending for a Single Resource

This test sequence compares different strategies for implementing the queue management functions of Program 10-4, using Program 10-5 (the three-stage pipeline) as a test application. The tests were run on a four-processor (1GHz) Intel Xeon Windows 2000 Server using 1, 2, 4, 8, 16, 32, and 64 threads, but in all seven cases each thread was asked to perform 1,000 units of work. Ideally, we would then expect real time to increase linearly with the number of threads, but contention for a single mutex (or CS) can cause nonlinear degradation as the number of threads increases. Note that these tests do not exercise the file system.

Six different implementation strategies were used, and the results are shown in separate columns in Program 10-4 discuss the results and explain the merits of the different implementations, but notice that the signal model does scale with the number of threads, while the broadcast model does not scale, especially with 32 and 64 threads. Also notice how the broadcast model results in large amounts of system CPU time as multiple threads run, test the predicate, and immediately return to the wait state.

1. Broadcast model, mutex, event, separate release and wait calls. The tunable time-out was set to 5 milliseconds, which optimized the 16-thread case.

2. Broadcast model, CRITICAL_SECTION, event, separate release and wait calls. The tunable time-out was set to 25 milliseconds, which optimized the 16-thread case.

3. Broadcast model, mutex, event, atomic SignalObjectAndWait call.

4. Signal model, mutex, event, separate release and wait calls.

5. Signal model, CRITICAL_SECTION, event, separate release and wait calls.

6. Signal model, mutex, event, atomic SignalObjectAndWait call.