News About TACS and MODELS

(Extracted from Can/Am EMTP News Apr/1997)

Laurent Dube*s MODELS was shown to be extremely slow compared with TACS for some simulations. Recall that an order of magnitude difference in speed was documented in the preceding issue for the SVC simulation of Gabor Furst. But this does not mean that the old (non-compiled) TACS itself is efficient, note. How can one know? After more than two decades of speculation, your Editor decided it finally was time for an evaluation --- a comparison of the speed of free-format supplemental variables of TACS with the speed of the MATH command of TPPLOT. This would seem to be an apples-to-apples comparison in that both computations are programmed by the user in data (as opposed to the code of compiled TACS).
The MATH command is lower-level, of course; it is more like computer assembly language. This is the whole idea : to use something simpler to estimate the inefficiency of Dube*s implementation of high-level, free-format supplemental variables. This has been done using disk files named MAT*.* as described in later paragraphs.
First consider ATP simulation of MATHATP.DAT, which is a modification of the second subcase of DC-18. The code to be represented is, if written in single precision:

TEST1 = 10 * ( 1.0 + TIMEX ) ** 2 + 50
TEST2 = 100 * COS ( 2.0 * 3.14159 * TEST1 / 100 )
TEST3 = 10 + 5.5 * TIMEX * SQRT ( ABS ( TEST2 ) )
TEST5 = 2 * 3.14159 * TEST1 / 100
TEST6 = 2 * SIN ( TEST5 )
TWOXX = .0002 * ( TEST2 ** 2 + 2500 * TEST6 ** 2 )
First, 10K steps between 0 and 2 sec were taken with minimal printout, with IPLOT set to -1 to suppress plot data, and DISK to minimize screen output. Second, the simulation was repeated with the preceding replaced by the single assignment TEST1 = 10. Both tests outputted the single variable TEST1. Taking the 5 fastest of 6 successive simulations of both cases leads to the following table. This was using Salford EMTP simulation in a DOS window of Win95 on your Editor*s 133-Mhz Pentium:

Real : 1.978 1.923 2.033 1.923 1.978
Dummy: .879 .934 .879 .879 .879
The difference of the averages is 1.077 sec --- an estimate of the time TACS requires to perform the math. Note the near-empty problem is needed to remove the overhead of ATP itself (there is a dummy electric network, and TACS still is being entered each time step, even though little is done there).

Next consider MATHPLOT.FTN -- a special program that was written to perform the exact same computation as those six supplemental variables. But this small, new program is not driven by TACS data, but rather by MATH-like data in MATHPLOT.DAT --- a file that was created using human intelligence (no program to do such compilation yet has been written). Execution of this requires an average of .2368 seconds (1% of the time taken for 100 executions within a loop). It is to be conluded that TACS supplemental variables are slow by a factor of about 4.59 ( 1.077 / .2368 ) compared with MATH-like processing. The interpretation is simple: TACS looks bad. Why no one seems to have bothered to consider this detail before is surprising. It is only when compared with MODELS that TACS looks good! In proper perspective, TACS looks bad, and MODELS looks worse yet (for basic mathematics). Using round numbers, TACS is slow by a factor of 5, and MODELS might be slow by a factor of 50 --- compared with the simple, easily-programmed MATH-like logic. ATP should be able to do much better than it now does using programming that began with Laurent Dube.

Compilation provides the ultimate standard. Disk file MATHCOMP.FTN contains the previously-shown code after conversion to double precision. Execution of this requires an average of .03187 seconds (1% of the time taken for 100 executions within a loop). The ratio to MATH-like processing is 7.430 ( .2368 / .03187 ) and the ratio to ordinary TACS is 33.8 ( 1.077 / .03187 ) . The conclusion seems obvious: compiled TACS never looked better --- not only as an alternative to MODELS, but also as an alternative to ordinary (non-compiled) TACS .

But is MATHPLOT itself efficient? No, the MATH command was merely a hurried addition to demonstrate a concept. Studying details of speed, your Editor created an improved version MATHPLT1.FTN early in the morning of March 15th. Data is unchanged, but elapsed time has been reduced significantly --- from .2368 to .1297 sec. This reduces the ratio between compiled TACS and the MATH-like processing from 7.430 to 4.070 ( .1297 / .03187 ), which seems more believable. On the other hand, it widens the ratio of elapsed times separating ordinary old TACS and MATH-like processing. This grows from 4.59 to 8.304 (1.077 / .1297). That*s right, for the arithmetic shown previously, one can speed execution by a factor of about eight simply by replacing Dube*s 2-decade-old logic by simpler MATH-like logic. Do readers want to bet how much longer the Dube logic will last in ATP ? ! This looks like a second great improvement to TACS --- a nice alternative to compiled TACS (see a separate story for further discussion of this) for those unwilling to compile.

MATHPLT2 was an improvement made late in the evening of March 17th, following consultation with BPA*s Walter Powell, who interpreted the assembly language created by the Salford compiler in response to /EXPLIST (a compilation qualifier). The reprogramming had reduced the elapsed time from .1297 to .08626 sec. This reduces the ratio between compiled TACS and the MATH-like processing from 4.070 to 2.707 and it widens the ratio of elapsed times separating ordinary old TACS and MATH-like processing to 12.49

MATHPLT3 was an improvement made during the afternoon of March 18th. The original concept of MATH was to use a few low-level instructions. But why be so cheap (parsimonious)? Why not spend an extra hour or two to program higher-level math involving a second operand? There is some similarity to the competition between RISC and CISC (Reduced Instruction Set Computer and Complex Instruction Set Computer) processors. Reprogramming with fewer but higher-level instructions reduces the elapsed time to .06538 sec. The ratio between compiled TACS and the MATH-like processing drops to 2.051 and the ratio of elapsed times separating ordinary old TACS and MATH-like processing rises to 16.47 Of course, the product of these two is the 33.8 quoted previously.