|
|
Linux Programming
As Linux becomes a more mainstream player in the Internet infrastructure
market, there is a tremendous need for lucid programming texts
that also convey some of the philosophy behind the Linux and
GNU movements.
Currently there are many different languages
to program Linux in. Some are BASH programming, while some are
core development. What ever it is MVI Solutions's programmers can
customize your Linux operating system to meet your specific
business need.
High-performance programming techniques for the Linux and Windows 2000 operating systems.
Useful and efficient programming practices; solving the same problems on Linux and Windows 2000. Once solved, we'll measure at least one aspect of the performance of each platform. A variety of performance testing scripts and programs will demonstrate the speed of operating system features. The goal is to show how to get the best possible performance from each operating system and, as an aside, compare the performance of the two platforms.
Performance test overview. Our tests will examine memory speeds, system call speeds, IO throughput, context switching speeds, and a number of other programming facilities common to both platforms. Access to the Windows Registry will not be measured.
We'll treat Linux as two operating systems: the Linux 2.2.16 kernel and the 2.4.2 kernel. Windows 2000 will be considered the Windows 2000 build 2195 system and, when released, the Windows XP kernel. All runs for a given test will be carried out on exactly the same hardware. Primarily the hardware will be a dual-booting IBM ThinkPad 600X with 576 MB of memory and two 12-GB disk drives.
Our programs will be written in C++ although very little object-oriented code will be used. C++ for our purposes is just C with strong type checking. On Linux we will be using the g-cc that is included with the Red Hat 7.0 distribution. On Windows 2000, we will use the Microsoft C++ Version 12.00.8168 from Visual Studio 6.0.
Measurement utilities will define the utility routines we will need for making and reporting measurements on Windows 2000 and Linux. The list of tools is short: an interface for measuring time, a routine that returns a string describing the operating system, a simple and more efficient interface to the simple malloc() memory allocation routine, and an input routine for handling large numbers.
Our memory allocation is called Malloc(int). All it does is call the malloc(int) routine, and if malloc(int) fails, Malloc() prints an error message and exits. When we test memory allocation performance, we won't use this routine, but in the meantime, it streamlines coding. We use malloc() because it is available on both Windows 2000 and Linux. Malloc() is uninteresting and identical on both systems.
The next routine is atoik(char *). This routine is identical to the atoi() routine but also takes a trailing "k" or "m". A trailing "k" or "m" means to multiply the already parsed number by 1024 for "k" or by 1024*1024 for "m". Either "k" or "m" can be upper or lower case, and any number of them can be appended. Atoik() only returns 32 bits, so any number greater than or equal to 2 GB is probably not going to work. When that becomes an issue, we will invent atoik64(). This routine is identical on both systems.
Measuring time is going to measure the time on our two operating systems? Let's look at our choices. On Windows 2000, there are two APIs for measuring time intervals. The first is Get Tick Count (). This function reports the number of milliseconds elapsed since the system was booted. Get Tick Count() has a "clock tick" granularity. That means that it is only updated when the system clock ticks. In Windows' case, it is only updated every 10 milliseconds. Therefore its granularity is no better than 10 milliseconds or ten thousand microseconds.
Windows 2000 also has a Query Performance Counter() API that retrieves the current value of the 64-bit high-resolution performance counter. The meaning of each "tick" included in the result of a call to Query Performance Counter() depends on the value returned by Query Performance Frequency(). The frequency is the number of counter increments per second, so seconds are expressed as:
Because of the resolution issues associated with Get Tick Count() we will be using Query Performance Counter exclusively. We must, however, be mindful that if a timing is as short as the overhead of the Query Performance Counter() API, then our results are probably not credible. We will measure the overhead of our timing routines below.
On Linux we use the gettimeofday() API. It is the only API that meets our need to time at the sub-millisecond level.
Now that we have chosen the APIs to use, we need to define our own APIs so that our program can use them without having to know about the host operating system. We chose the following interface for this function:
T start() records the time value in static memory of when it is called. Tend() records the time value in static memory of when it is called. T val() takes the t start and tend time values, converts them to double precision numbers, subtracts them, and returns the result as a double. The interface is simple to implement on Linux and Windows, and it performs the needed timing functions.
The implementation of timing routines for Linux and Windows 2000 follows. We cannot avoid system dependencies, but our goal will be to write optimal code while minimizing the number of conditional definitions.
The last routine is "char *ver()". This simple function returns a string describing the current operating system environment.
The ver.exe program will be used to log operating system version information to output files.
The program was written to take a single optional argument. By default, the program calls tend() 100,000 times. Repeated runs of the program should guarantee that a reproducible time results. We ran the program with the default count 10 times. The results are shown in the table for Linux 2.2.16, Linux 2.4.2, and Windows 2000.
MVI Solutions defined the timing routines we use and how we will identify the results using a simple ver.cpp program, and lastly, measured and documented the overhead of our timing routines. The measurements we produce will inevitably lead to a performance characterization of the operating systems.
Using a program called time-timers.cpp , we learned that the overhead of the timing routines is less than 2 microseconds on Windows and less than 1 microsecond on Linux. Please feel free to make use of the discussion forum for your reactions, thoughts, questions, etc. on this article.
|
|