Why Develop for the PC?

mobile friendly copies of articles from the McHenry Software Website
MSI
Site Admin
Posts: 2296
Joined: Thu Jun 18, 2009 12:37 pm

Why Develop for the PC?

Post by MSI »

  • a Linkedin post reminded me of the early days of PCs development and all the limitations and frustrations and so i dug deep and found this post from our website back in the 1990s. We repeat the article here:

    Why Develop for the PC?
    Originally prepared and presented by Brian G. McHenry at the Road Accident Research Unit (RARU) (Now known as CASR), Adelaide, Australia in May 1995 as part of a Accident Reconstruction Seminar

    McHenry Consultants, Inc.( MCI) is a consulting engineering company formed in 1980 by Raymond R. McHenry and Brian G. McHenry which specializes in the investigation and reconstruction of highway accidents. Research performed at MCI has also included the development, refinement and utilization of computer programs. In early 1994, tests were performed on Pentium/60 processors which revealed that the processing power of PC machines had equaled and/or exceeded the requirements of a computer processor to handle the accident reconstruction programs developed and maintained by (MCI). The rationale for the decision to port all processing to the PC computer environment is as follows:

    Many of the original public domain versions of the CRASH, SMAC and HVOSM programs have been made available for use on PC's by entrepreneurs. However, we had delayed introduction of a PC version due to poor performance both for compilation and execution of the programs on tests performed internally. As early as 1982 we had ported the SMAC and CRASH computer programs to the 1st PC available (the 8086) in the hopes that the PC would become the tool of choice for accident investigators. In the late 70's and early 80's, all code maintained by MCI was kept on IBM and NAS (National Advanced Systems) mainframe computers. Access was limited to dumb terminals connected via 300 baud modem lines.

    The early versions of the PC (8086) and either IBM/Microsoft FORTRAN compiler and/or the Microsoft FORTRAN compiler were crude at best and provided very poor performance and reliability. (please see FootNote1 below for further information). With either version of the FORTRAN compiler the performance times were measurable in hours rather than minutes. Only the most mundane tasks could be performed with the early PC's. They were considered merely 'toys' to tinker with not quite scientific tools.

    As the distribution of PC's increased and the technology behind them advanced, their performance increased, their prices dropped and so did the performance and price of mini computers. So in the mid to late 80's, while continuing to test PC's, the production versions of software at MCI as well as many other small to midsize corporations were ported from time-share mainframe computers to company owned mini­computers. The technology had evolved to the point where the mini-computers were performing at levels equivalent to the year old mainframes. Around 1987 MCI first purchased an HP 9000 mini computer and then later in the early 1990's an IBM RISC/6000 550 mini computer. Both machines offered for their time phenomenal performance per dollar invested.

    During this time of development in the mini-computer market, there was a revolution taking place with respect to the power and performance of the PC's. The AT, the 286, the 386 and then the 486/66 emerged in a very short period of time. The 640K memory limitations of the early PC's were eliminated, disk storage went form 10 to 20 to 100 megabytes and virtually any computer program could be executed on a PC. However, tests performed in 1992-93 by MCI demonstrated that the compilation and execution of each of the programs was still 6 to 8 times slower on a 486/66 than on the currently used IBM RISC/6000 550 mini-computer.

    While the speed degradation of the PC does not at first appear that great, you should realize that for math-intensive programs such as many of the simulation programs used by MCI, processing can take as much as from 5 to 10 minutes on a IBM RISC/6000 which would then result in a 30 to 80 minute execution time on a PC. The compilation times also suffered due to much slower disk I/O performance and it was believed at MCI that the performance level of the 486/66 was still not adequate for a decision to move production to the PC's.

    Then in early 1994 the cost for a Pentium PC machine dropped to a level worthy of consideration. When the Pentium first came out the estimated cost of the processor alone was > $2000 so a fully loaded system rivaled the cost of a mini-computer. That all changed in early 1994. So MCI obtained a Pentium/60 and while testing code we found that our programs compiled and executed at 10x-12x the speed of the 486/66 and 2X faster than the current IBM RISC/6000 550 mini-computer platform. This also had the added bonus that the Pentium/60 PC was one-tenth the cost of the IBM RISC/6000!.

    A few notes:
    • First, the IBM RISC/6000 that we use and benched against is the 1991 model 550. Most likely current versions of the IBM RISC/6000 will probably out perform the Pentium/60. However the related costs make the use of the Pentium preferable. Also to note, on the RISC/6000, because it is a RISC Unix machine, several instances of code may be executed without a substantial penalty in execution times. This is in contrast to the performance of the PC with the current operating system available. Unless a job is run in foreground (i.e. the only job run) then there is a substantial loss in performance.

      Secondly, Anyone who has kept up with the PC magazines will be surprised by the performance gain from the 486/66 to the Pentium/60. Without attempting to offer a detailed explanation, the main gain in performance apparently is due to the use of a 32-bit DOS-Extended compiler in conjunction with the improvements provided by the Pentium Floating Point Processor. The tests that are run in the PC magazines are run in 16-bit Windows 3.1 or 3.11 and are severely limited by the performance of Disk and Video input/output. Most of the tests load code, run a macro, do some graphics, exit,... load code, run a macro, do some graphics, exit...and so on... The speed of the processor is limited by the speed of the disk and video I/O. The tests performed by MCI were with 32-bit FORTRAN code which has limited I/O and extensively uses the Floating point processor.

      As the development and integration of the various programs became more involved it became apparent that the scope of program development was outside the original scope ofMcHenry Consultants, Inc.(MCI) MCI is a consulting engineering company specializing in the investigation and reconstruction of highway accidents which has included the development and utilization of computer programs. However, McHenry Consultants is not a computer software distributor. Therefore to facilitate the setup and distribution of computer programs related to accident reconstructions a new corporation, McHenry Software, Inc.(MSI), was formed in 1994 with the explicit intent to create, distribute and support accident reconstruction computer software.

      Therefore in early 1994 the task of porting all the code to the PC computer was undertaken by MSI. The core programs were ported to run with the Microsoft Powerstation ver 1.0a Compiler. The MS Powerstation is a Microsoft Windows based compiler environment which uses the Phar-Lap MS-DOS Extender to create 32-bit MS-DOS-Extended programs which are optimized to improve execution speed of the FORTRAN programs while being limited only by the hardware you run them on (the only limits on the FORTRAN program size are the amount of physical memory your machine has (RAM) combined with the amount of the virtual memory your machine has (free disk space ) for more information please see FootNote2 below).

      Initially, in Jan 95, the then current versions of Windows, 3.1 and 3.11 were chosen as our target operating systems for the project environment. This afforded the interface the GUI (Graphical User Interface) point and click, look and feel. No longer should the technical user be required to remember mundane MS-DOS command sequences which can at times rival fellow cryptic system Unix. Additional performance issues required the use of a 32-bit code for our main programs to execute under to achieve optimal performance. Windows 3.1 and 3.11 are 16-bit operating systems which run 16-bit code ( version 3.11 does have some 32-bit components and it can run some 32-bit code by thunking the code down from 32-bit to 16-bit with a substantial loss in performance ). The execution of 32-bit MS-DOS extended code can be accomplished from the Windows environment by the use of the MS-DOS Shell command from within Windows. This therefore accomplishes a seamless integration of the power and performance of 32-bit DOS-Extended programs with the convenience and familiarity of the current 16-bit Windows GUI environment.

      Test performed in November 1995 compiling and executing the code with the Microsoft Fortran Powerstation 4.0 compiler appear very promising. There are two ways that code can be ported from 32-DOS Extended to 32-bit Win 95 or Win NT operating environments. First, Microsoft has created Powerstation 4.0 which creates native code for either of the two environments. As a beta program participant I must say I was very pleased to find that their Release version compiled and executed programs nearly 80% faster than 32-bit DOS Extended code. The results of my initial Bench test are as follows:
      • Operating System, Compiler Used, Execution Time
        • NT, Powerstation 4.0, 54.5 sec
        • NT, Powerstation 1.0a, 99.8 sec
        • Win 95, Powerstation 4.0, 55.6 sec
        • Win 95, Powerstation 1.0a, 95.2 sec
        • WFWG/Dos 6.2, Powerstation 1.0a, 98.6 sec
      The program run was a m-hvosm simulation of a vehicle tripping and rolling. The execution of Powerstation 1.0 programs in NT and Win 95 was accomplished applying the FPSFix program to the executables. The FPSfix program was posted on the Microsoft Fortran WWW page in November 1995 and allows DOS Extended Programs to work in Win95 or NT. Prior to the posting of the fix programs compiled with Powerstation 1.0 would not run in Win 95 or NT.


    Update Jan1997:
    • Microsoft dropped the ball and passed it to Digital! Apparently Microsoft, in their quest to overtake the internet and WWW, has dropped Fortran Powerstation from the Developer Studio 97 and replaced it with J(ava)++. The Developer Studio initially contained C++, Fortran Powerstation, Source Safe and Developer Library. The latest version of the Developer studio has dropped Fortran. Suprise! Suprise! It actually comes as no suprise given the total silence by Microsoft (except for ads) related to Fortran Powerstation. The product had many problems (memory leaks, keyboard functions that didn't work and limited interaction, and other problems normally related to a first release of a product. After 15 months of silence on bug fixes, updates or anything related to Fortran Powerstation 4.0, Microsoft has apparently now relayed in communications that the Powerstation has been dropped from developer studio and that future releases of Powerstation are not planned. They have apparently given the ball to Digital which recently released the Digital Visual Studio). McHenry Software has purchased the Lahey Fortran 90 and Digital Visual Studio (please see News! for more information) and will soon offer modules in either or both compiled languages. Look to our pages in the future for more information on comparisons and benchmarks.
    SUMMARY
    • In summary, the overall direction to faster, cheaper and phenomenally more powerful desktop machines has made for the inevitable conversion of most mainframe applications to the PC. In particular it has made the machine of choice for daily processing by McHenry Consultants, Inc. the Pentium based PC. With the emergence of the Pentium/90, Pentium/100, Pentium/120 and Pentium/133 with EDO memory (Extended Data Out Ram when used with the PCI Bus permits the EDO Ram to perform more operations in fewer clock cycles than traditional RAM, adding approximately an additional speed gain of 10% or more ), Pentium/200, Pentirum-Pro/200, Pentium II/266, the day of the desktop 'mainframe' has arrived!



    FootNotes:
    • Note 1:
      • We relay an early experience of bug repair for the early PC's, ~ 1982-83, with IBM/Microsoft FORTRAN Compiler. The bug 'repair' consisted of a list of 20 'circumventions' circulated by IBM/Microsoft as their 'fix' to the early versions of the FORTRAN Compiler. One of the 'circumventions' was to eliminate all RETURN statements in subroutines?!! Subroutines are separate routines that perform functions and then 'return' to the main program ( or other subroutines). The 'return' is accomplished by the entry of a RETURN statement. It seems that the program stack was not re-initialized correctly if the RETURN statement was present, however it did re-initialize correctly if the RETURN statement was absent ( probably a story in itself, the discovery that the mistake of forgetting your RETURN statement fixed the 'bug'). The incorrect re-initialization of the stack caused the program to 'crash' after a few calls to the subroutine due to memory address errors. And after 14 months of attempting to deal with the error the best that IBM/Microsoft could do to correct the error (among many others) was to send out a list of 'circumventions'.
        • As for trivia this might also explain the emergence of Microsoft as a software giant. Seems they somehow 'independently' began selling a Microsoft FORTRAN compiler at around that same time that somehow happened to have the bug fixed! In sharp contrast to the IBM/Microsoft version of the FORTRAN compiler which could not be fixed. Apparently IBM wrote a contract with Microsoft that Microsoft would create the initial software offering and then could go out on their own to create a competing version. As I recall this produced the general understanding in the PC community that you should go to the source (Microsoft) to get compilers and other software rather than buy the 'same' Microsoft software from IBM. This trivia documents some of the savvy but possibly unsavory techniques used by Microsoft which ultimately allowed them to emerge as a mega-giant software corporation.

      Note 2:
      • The use of virtual memory detracts from the overall performance of the final code due to the use of disk input/output as the program swaps between virtual and actual memory buffers.