From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:2971 comp.lang.c:23963 comp.lang.c++:5619 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!pyrdc!grebyn!ted From: ted@grebyn.com (Ted Holden) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Ada vs C/UNIX / switching speeds Message-ID: <14042@grebyn.com> Date: 22 Nov 89 21:37:12 GMT Followup-To: comp.lang.ada Organization: Grebyn Timesharing, Vienna, VA List-Id: Sometimes, these arguments get off track so badly that the non-initiated might lose their bearings following them. Remember, it is Ada and not C or C++ which makes the mistake of having tasking be part of a programming language rather than part of an OS or a library. From: Bill Wolfe, Clemson > The following article relates to the recent discussion > of Ada vs. UNIX/C and lightweight processes. Notice the > disastrous performance produced by UNIX/C relative to Ada. >Date: Fri, 17 Nov 89 11:03:44 CST >From: steve@titan.tsd.arlut.utexas.edu (Steve Glicker) >Subject: Simple process and task switching speeds >Recently there have been references to lightweight processes, UNIX/C >processes, and Ada tasking in terms of speed (Bill Wolfe on Date: 15 >Nov 89 16:06:41 GMT and Walter Rowe on Date: 16 Nov 89 18:20:01 GMT). >Over the last few months, I have been collecting numbers on >task/process switching speeds. Several tests have been run were two >tasks or processes invoke each other several hundred thousand times, >execution time is then divided by switches... >The information I have collected is in the following table. This is >quite informal -- these are rough estimates. Does anyone have >estimates on the speed of lightweight processes, etc.? Data on >embedded systems is welcome. I would also appreciate any references >to work published on this topic. > Platform Test Switching Speed >============== ================ ================= >microVAX (VMS) VMS processes ~ 0.6 ms >microVAX (VMS) DEC Ada tasks ~ 0.6 ms >Sun 3/50 (UNIX) Function call ~ 0.01 ms >Sun 3/50 (UNIX) Simula processes ~ 0.2 ms >Sun 3/50 (UNIX) Verdix Ada tasks ~ 0.3 ms >Sun 3/50 (UNIX) UNIX/C processes ~10.0 ms >I understand that the microVAXs ran at ~0.9 VAX 780 MIPS and the Sun >3/50 at ~1.5 VAX 780 MIPS. In the cases of Ada and Simula a scheduler >supplied with the language was used. Did I ever say anything about implementing a real-time or embedded system in vanilla UNIX? Did any of the C or UNIX gurus on the net? I mean, I like UNIX, but I'm not stupid; that's about the only thing I can think of which would actually be as pathalogical or more pathalogical than writing a real-time or embedded system in Ada. Vanilla UNIX is taking the world by virtue of portability (no other OS has it), not real-time features. It is intended most primarily as a software development platform. Real-time/embedded systems should ideally be written in C or C++ on a UNIX system and then run either on a real-time kernel like VRTX or on a modified UNIX system such as is sold by Masscomp or Charles River. Serious database applications are best run under UNIX on UNIX systems which have been specially modified and/or designed therefor, e.g. Sequent or Tolerant. I am not totally up on UNIX V/4; it might be that V/4 will have some of these same kinds of capabilities. I know, I can hear it: "what about standards?" Bjarne Stroustrup said it best recently: >Anyway, most C++ standardization problems arise because C++ has several >independent implementations. This is a problem of succcess; most languages >never get a second implementation: their application areas and user >base simply never grows to make a second (or a tenths) implementation >viable. Same holds for UNIX. In the case of a big-time loser like Ada, on the other hand, one version is all that most of mankind needs to see. Bjarne was too polite to say that; a barbarian such as myself, obviously, has no such inhibitions. All of which still leaves the UNIX/C/C++ idea far more usable than Ada. A vast majority of software will still be easily portable from the MassComp, through vanilla UNIX, to the Sequent. By the way, I still can't get over the manner in which one of the Ada advocates on the net ended his refutation of my most recent anti-Ada diatribe: From: Marc Lewis: U. of Nebraska at Omaha >My only problem with Ada at this point is the cost ($ and hardware >resources) of a compiler for my XT clone. Both IntegrAda and Janus >require more memory than DOS 4.01 leaves available. This is BAD DESIGN. >There is no excuse for a 551K executable in a PC (pass 2 of Integrada). >Janus Ada requires >580K available to run, and rumor has it that the >Integrada compiler is a repackaged Janus compiler. Which is almost better than anything I could think of to say on the topic. With advocates like this, the Ada group probably doesn't even need me around; I can get back to talk.origins where my talents are appreciated. Ted Holden HTE ................................................. Watch comp.binaries.ibm.pc for most recent version of the HTE polyphonic VMUSIC program.