ted@grebyn.com (Ted Holden) (11/23/89)
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.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (11/23/89)
In article <14042@grebyn.com> ted@grebyn.com (Ted Holden) writes: > [...] 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. I don't agree it's a mistake. On the contrary, it is better to do tasking in a language that has been designed for tasking than in one that hasn't. Many people seem to believe that programming language problems go magically away if we move them from the language proper to libraries, i.e. sweep under the carpet. (Similarly, it was often supposed some years ago that many problems disappear if things are moved from the ordinary programming realm to the silicon.) > [...] >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? This rather confesses that the tasking capabilities of normal UNIX versions are no good (and I think that does not concern only true real-time or embedded systems). It is already in a little contradiction with Holden's first opinion. > [...] Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
peter@ficc.uu.net (Peter da Silva) (11/26/89)
> > 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. Yeh. Since ADA shouldn't have to do more than a function call, a switch in stack frames, and a return in the new stack frame... why is it so slow? > >Sun 3/50 (UNIX) Function call ~ 0.01 ms > >Sun 3/50 (UNIX) Verdix Ada tasks ~ 0.3 ms > >Sun 3/50 (UNIX) UNIX/C processes ~10.0 ms I would have expected the ADA task switch to take no more than 0.05 ms based on the speed of a function call. There's no MMU to deal with, a not inconsiderable overhead. There's no switch between user and kernel mode. There's none of the overhead that UNIX has to deal with. What's it doing, dynamically rearranging priorities at context-switch time instead of when you make a call or handle an external event? Lester Buck: could yo do some estimates on the context switch time for your C-threads routines? And has anyone done any realtime benchmarks on the Amiga? -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
shap@delrey.sgi.com (Jonathan Shapiro) (11/28/89)
In article <14042@grebyn.com> ted@grebyn.com (Ted Holden) writes: >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. There is merit to having a standardized tasking interface available to the programmer. Whether it lives in a standard library or in the language is, from the standpoint of the engineer who wishes to write portable programs, of limited importance. This is not an argument for putting tasking in the language. It is essential that one be able to write nonportable programs or support a local-only tasking model. The choice also seems to relate to schools of language design minimality, and I for one prefer minimalist languages. It is rather to point out that for the vast majority of programmers, the issue is unimportant. Jonathan Shapiro Silicon Graphics, Inc.