A Call For Benchmarks

By Kirk Chase, Editor, MacTutor

Mouser Info Needed

David Landowne

Help! I’ve been reading MacTutor for four years, great mag, but today I’m trying to track down a hot tip from the April 90 issue. In your Letter column, Greg Poole talks about the Mouser 1.2d5 and says it is available on AppleLink in the MacApp discussion folder. Soo I go to my local Link and in 20 minutes cannot find a MacApp folder or Mouser or anything with 1.2d5 in the software library. My host gets bored and says he’ll try later.

Do you have any further info or can you contact Greg Poole for me and find this browsing tool. It sounds like just what I need at my point in the learning curve.

While I have the line open, an answer to Mike Scanlin is

andi #0x8007
bpl  @1
ori  #0xFFF8
@1

Thanks and thanks for having such a great MacTutor.

[Mouser is now included in MacApp 2.0 which is available from APDA and on AppleLink, Developer Services:Macintosh Development Tool Discussions: MacApp Discussion:Mouser.-ed]

Benchmark Challenge

Walt Davis, Steve Bayer

If you ask experienced programmers which language, C or Pascal, produces a faster implementation of a given algorithm on a given machine, we’d bet at least 9 out of 10 would choose C. Experienced programmers know C is closer to the native machine language, provides register variables, and is more flexible than Pascal. After all, wasn’t Unix written in C? Besides, Pascal is perceived as a higher-level language than C used mostly for teaching. Aren’t higher-level languages generally slower?

Imagine our surprise when we ran some simple comparison tests using Symantec’s THINK C 4.0 and THINK Pascal 2.0 compilers for the Mac. It all started over a discussion about the comparative performance of Case (Switch in C) and the If-Then_Else language constructs. Since we expected Case (or Switch) to be a specialized form of the If-Then-Else, we expected Case to be quicker and for the most part our results showed this to be true for both C and Pascal compilers. The code we used for our tests is summarized below:

{1}

Pascal

{If-Then-Else Test Procedure }
procedure TestIfThenElse;
var
 i, startT, stopT: longint;
 b: integer;
begin
 GetDateTime(startT);
 for i:= 1 to 1000000 do
 begin
 if b = 1 then
 begin
 end
 else if b = 2 then
 begin
 end
  
 else if b = 15 then
 begin
 end;
 end;
 GetDateTime(stopT);
 ShowElapsedTime(startT, stopT);
end;

{ Case Test Procedure }
procedure TestCase;
var
 b: integer;
 i, startT, stopT: longint;
begin
 GetDateTime(startT);
 for i := 1 to 1000000 do
 begin
 case b of
 1:
 begin
 end;
 2:
 begin
 end;
  
 15:
 begin
 end;
 otherwise
 end;
 end;
 GetDateTime(stopT);
 ShowElapsedTime(startT, stopT);
end;

/* 2 */

C

/* If-Then-Else Test Function */
TestIfThenElse() {
int b;
long i, startT, stopT;

GetDateTime(&startT)
for (i = 0; i < 1000000; i++) {
 if (b==1) {} else
 if (b==2) {} else
  
 if (b==15) {};
}
GetDateTime(&stopT);
ShowElapsedTime(startT, stopT);
}

/* Switch Test Procedure */
TestSwitch() {
int b;
long i, startT, stopT;

GetDateTime(&startT);
for (i = 0; i < 1000000; i++) {
 switch (b) {
 case (1):
 break;
 case (2):
 break;
  
 case (15):
 break;
 }
}
GetDateTime(&stopT);
ShowElapsedTime(startT, stopT);
}

The If-Then and Case/Switch constructs in the test procedures and functions compare the variable b with integer values from 1 through 15. We measured the time it took to complete one million loops for values of b ranging from 1 to 20. There were no Mac Toolbox calls within the loops so no conversion from C to Pascal was required, and we compiled all code with the math coprocessor option disabled. We ran identical tests on the Mac Plus, Mac SE, and Mac II models under Finder, not MultiFinder. Table 1 shows our results in tabular form and Figure 1 shows a chart of the results for the Mac Plus Tests.

Table 1. Time (seconds) To Execute If-Then-Else versus Case/Switch Procedures

Figure 1. Test Results For If-Then-Else versus Switch/Case on a Mac Plus

Our tests show a similar relationship between the If-Then-Else and Case constructs in Pascal and the If-Then-Else and Switch constructs in C. The surprising results of our tests is that, depending on the machine, it can take anywhere from 60% to over 100% longer to execute a particular language construct in C than it does in Pascal. These results really just point out the obvious; that the relative speed of a high-level language depends on the assembly language produced by the compiler and not the high-level language itself.

In closing, we would like to challenge MacTutor and its readers to repeat these tests using the Symantec compilers on similar hardware platforms to verify our results. Do these results hold for other compilers, e.g. MPW? How do other languages like Fortran and Modula-2 compare? Do these results hold for other language constructs besides the ones tested here?

SANE Bypass Help Needed

Martin E. Huber

I am a scientific/technical researcher and use the Macintosh for lengthy numerical simulations of physical systems. I would like to get every bit of speed I can out of the floating-point co-processor (FPU) and am not sure my current compiler uses it to its full potential. The accuracy provided by the 68881/68882 chips is more than sufficient for my needs the SANE standards are over-kill.

I have heard somewhere (I don’t remember where) that there are a few different ways programs on the Mac execute floating point operations. First, the FPU can be ignored altogether, in which case SANE uses the CPU for all operations. Second, if a FPU is present, SANE routines are used, but the routines use the FPU. Finally, the floating point operations can bypass SANE altogether and be passed directly to the FPU. Is this description accurate?

If so, I would like to find a compiler which bypasses SANE for ALL arithmetic functions (including add/subtract, multiply/divide), not just for the transcendental functions. Does such a beast exist? (I’ve heard that some compilers which make “direct” FPU calls still end up running through SANE.) Can you tell me which compiler provides the fastest running number-crunching code on a Mac with a FPU (in each of the languages Fortran, Pascal, Basic, and C, if possible), or at least where I might find such information? I haven’t seen any compilation of benchmark results lately. Thanks for any assistance you can provide.

Metrowerks Modula-2

Greg Galanos

I would like to respond to Allen Stenger’s letter, which appeared in the July issue of MacTutor, by clarifying a certain number of technical points brought up with respect to the Metrowerks Modula-2 Professional Standalone Edition compiler. Before starting I would like to thank Allen for his perceptive comments.

The peculiar-looking code that Allen refers to, implemented through a jump table, is uniquely the runtime support necessary to implement functions not supported by the 68000 processor. All normal procedures are called in the usual method used on the Motorola processor family. (I will come back to this issue during the discussion on dynamic linking). Metrowerks Modula-2 PSE generates native 68000 (or 68020/030) code, the above being one of only two instances where jump tables are used. The second instance is in the treatment of CASE statements and this is due to change in a subsequent releases this year.

Allen is correct in stating that the debugger does not like anchored variables. The main reason is that when we upgraded the PSE compiler to correctly handle AVs to provide source-code compatibility with the MPW compiler, we forgot to upgrade the debugger to handle their display. However this will be fixed in the next release, due around the same time as this issue will appear.

A point of clarification on the rumored TML Modula-2 compiler, which was written by Bob Campbell and licensed to TML Systems for publishing. Unfortunately for reasons unknown, but certainly not because of the quality of the Campbell compiler, TML decided to withdraw the compiler from the marketplace and thus lost the distribution rights to the product.

Metrowerks decided that the Campbell compiler was an extremely well written MPW compiler and entered into a joint development and publishing agreement with Mr. Campbell last November. Since then, and until market introduction in April 1990, the developers have been working on bringing both the PSE and MPW compilers up to source-code compatibility (while the anchored variable display in the debugger went unnoticed).

On compiler speed, Allen mentioned that the PSE compiler is half as fast as the Sempersoft compiler. We have not been able to find the mentioned compiler on the market but this is an unfair comparison. The PSE compiler may take more time during the symbol file importation but this is due to the fact that we are giving the user a graphical progress report of the compilation pass and this certainly slows down imports because of the screen updating. This is not the case for an MPW tool.

We did however check compile times between the Modula-2 MPW Edition, MPW Pascal and MPW C and the following table displays the hand-checked results of compiling the TubeTest example program distributed with MPW by MacDTS.

MPW Edition MPW Pascal MPW C

6 6 11

(in seconds on a Mac-IIci, MPW 3.1, compiler versions 3.1)

These results lead us to believe that the Metrowerks compilers hold their own on compile speed when comparing apples with apples (no pun intended).

Dynamic Linking Explained

Now for the lengthiest part of this letter, clarifying bulky code. If anyone would care to examine an .obm file containing the object code produced by the PSE compiler, I’m sure they will notice that the code produced is short and sweet. The method used to produce a fast prototyping system in our case is called dynamic link-loading. This does not reduce compile time, but radically cuts link time through the use of dynamic links.

We use a program stack while your program is executing within the Metrowerks environment. The object files generated by the compiler are completely relocatable and need not be patched. They are merely ready to be loaded. Besides the main module, which is called to be executed at the highest level of the program stack, all modules that are directly or indirectly imported by the main program are loaded and linked with one important exception which is in the case of memory-resident modules.

A large percentage of the imported modules are already part of the resident Metrowerks shell. For instance FileIO and QuickDraw or any number of toolbox and OS managers are being used by the shell to implement the multi-window text editor, or the compiler parser/scanner. In the case where one of these modules is directly or indirectly imported by the main program the linker/loader sets up a dynamic link to the memory-resident module instead of reloading it from disk.

This permits high speed dynamic linking which provides fast compile, debug and execute cycles within the environment. When the main program completes execution, it is removed from memory along with the other imported modules that are not memory-resident. The actual implementation of the program stack is simply the following:

PROCEDURE Call (module: ARRAY OF CHAR;
           leaveLoaded: BOOLEAN; VAR   status: Status);

PROCEDURE ExecuteObmFile(name: ARRAY OF CHAR;
                         enterDebug: BOOLEAN);
VAR
  status :    Status;
BEGIN
...
  Call(name, FALSE, status);
 ...
END ExecuteObmFile;

The advantage of dynamic linking is fast turnaround time as well as the fact that your own finished application can also implement this scheme. The System.Call mechanism can be used by any program compiled with the PSE compiler. The advantage of a program stack call is that the stack is not limited to 32k segments. It may be as large as the memory available as long as the data and code size of an individual module either imported or importing is not larger than 32k each.

The tradeoff on dynamic linking is that because the nature of the link is dynamic we cannot, at this time, remove unused code (sometimes referred to as dead code) from the linked application without removing the System.Call facility. It is precisely this tradeoff that makes the produced application, and not the generated object code, larger than for instance an MPW produced application. We are currently investigating whether we will write an incremental linker or wait until Apple comes up with one.

However, this does not mean that Metrowerks Modula-2 PSE is not suitable for applications development, the proof of the pudding being that the entire Metrowerks Modula-2 Professional Standalone Edition bootstraps itself and is linked by PSE under the above mentioned dynamic linking scheme.

For those of you who do want the fast-prototyping capabilities of PSE but also want the linking capabilities of MPW, we suggest prototyping on PSE and delivering the final product on the Metrowerks MPW Edition compiler. These can be purchased separately or as a bundle for less than $300. Source-code compatibility between the two compilers gives anyone a reasonably priced solution to having the best of both worlds.