Dear DDJ,
I was delighted to see an issue devoted to real-time programming (June issue). As a person who has followed and worked with real-time Unix on PCs for many years, I recognize it as being a vehicle for fixing many of the serious complaints people have with Unix.
What the articles failed to convey are some of the dramatic effects real time has by turbo-charging some commonly used Unix software. Too often people have just focused on communication servers or special time dependent access to hardware. It is true that real time is important here, and some of the most important effects of real time are dramatically realized in these areas, but performance improvements can occur in many other areas.
For example, the server technology improvements due to real-time scheduling, which Dan Hildebrand used to make his communications servers work reliably, can also provide dramatic improvements in X-windows as well as other windowing software. Problems which are solved are Mouse tracking on a loaded system, and a signaling process doing intensive I/O to the screen. Real time can give a totally different feel to the responsiveness of X-windows.
Real-time graphics systems, such as those used to trace the path of a football or weather pattern on your TV have been employing real-time Unix for many years.
Networking servers, often a bottleneck on distributed systems-particularly on the remote file system (RFS) implementations--can be significantly improved.
In addition, the database world of on-line transaction processing (OLTP) benefits from the real-time technology. A base-line factor of 2x improvement in throughput is achieved with asynchronous disk I/O. Asynchronous I/O allows processing at a user level to continue while a read or write system call is being processed. Direct disk I/O, allowing multi-block transfers to occur to the Unix file system, can produce a factor of 10x improvement in some cases.
In the factory automation process control world, where interrupt latencies and rapid context switching are important for basic real-time control of machinery and monitoring systems, a revolution in software is occurring. The availability of cheap high performance CPUs have meant that real-time Unix systems with general-purpose software can be used, whereas previously oniy dedicated controllers with special purpose software were required.
Many companies are moving quickly to get these real-time features for some of the basic features described above. Venix/386 and Venix/286, AT&T certified ports of Unix System V to the PC AT and compatibles, contain all these features of real time and many more. VenturCom has ported the real-time enhancements of Venix to Interactive System's 386/IX and is now working with DEC to incorporate them into Ultrix. There is more to come in the future.
It is nice to see real-time technology take its place among standard desirable features of an operating system. In the past, it has been relegated to only process control applications or to scientific experiments. It works there as well, but its features offer much more than the name suggests.
William P. Spencer, PhD
Cambridge, Mass.
Dear DDJ,
When I read Kent Porter's comparison of Turbo Pascal, Version 4.0 and Microsoft Pascal, Version 4.0 (June issue), it occurred to me that the difference in execution times for some floating point benchmarks stems primarily from the differences in the numerical format used by the two compilers. One may observe the same effect in the reduction in number-crunching speed between QuickBasic 3.0 and 4.0 when used without the assistance of an FPU.
Mr. Porter mentions that the last set of benchmarks were run without an FPU. Thus, the Turbo Pascal version would use the old six byte "real" type, which is obligatory on machines lacking an FPU; whereas, the Microsoft Pascal would be using IEEE floating point numbers and FPU emulation in software. I would guess that any additional optimization the Microsoft compiler might do would tend to pale to insignificance when compared to the substantial loss of speed due to the FPU emulation. The same effect is somewhat noticeable, though less pronounced, in the "fib" benchmark. If I'm correct, the differences should largely disappear on a machine equipped with an FPU. With the fact that only a small percentage of micros have an FPU, one can reasonably question Microsoft's decision to go to exclusive use of the IEEE floating point number in their latest series of compilers.
As to the size of the executables produced, Microsoft's linker still (unless recently changed) appears to include any and all runtime library functions in the executable, regardless of whether or not the application needs them. I expect that Microsoft collectively feels that with the increasing memory sizes available in micros, the size of executable files is irrelevant. I disagree and live in hope that they will soon bring out a "smarter" linker. I also applaud Borland's linker's intelligence and hope that they will make it available in a stand-alone form in the near future.
Dan Dixon
Woodward, Okla.
Dear DDJ,
I just read Kent Porter's review of PC/Forms, Version 1.21b in the May issue and was struck by the resemblance to Zortech's Pro-Screen. I purchased the Turbo C version from Zortech Inc. for $50.
Although I have not had the time to use Pro-Screen enough to be thoroughly familiar with it, there are a few quirks which may or may not prove to be serious. First, it is produced by a British company so all the financial functions are in pounds and pence (at least the documentation is). Second, while sold as a stand-alone library, it is designed primarily to work with Zortech's window library. And, third, the emphasis is on business functions: the Zortech B-tree/ISAM library is touted. So, Zortech's Pro-Screen is not quite the general purpose library if you believe the documentation; so far, however, it is doing what I bought it to do.
Richard B. Shepard, PhD
Palatka, Fla.
In the August issue on "Speed Trials: Five Cs Compared," Version 6.0 and Version 6.5 of Watcom's C compiler were benchmarked. While the text of the article accurately pointed out that Watcom C 6.5 outperformed all other compilers evaluated -- running the Dhrystone at 8.8 seconds -- Table 1 made reference to only Version 6.0 (which performed the same test in 10.6 seconds). Although both figures are correct, both versions should have been included in Table 1.
On page 24 of the same article, the captions for Examples 2 and 3 were reversed. They should read: "Example 2: Test suite results for Borland's Turbo C, Version 1.5" (no errors detected) and "Example 3: Test suite results for Watcom C, Version 6.0" (failed). We apologize for this discrepancy. -- ed