exiphm@eutrc3.urc.tue.nl (h.munk) (08/18/89)
These are the replies I recieved on my question on implementing PRIMAL in an Object Oriented Language. I have included a copy of the original article as reference material. Some of you out there asked for a personal response, which I hope you received a few weeks ago. If not, drop my some bytes. Regards, Harm Munk. ---------------------------------------------------------------- Dear Everybody, I have a question concerning the appropriateness of OOLs for the implementation of a package for real-time continuous process diagnostics. The package, called PRIMAL (= Package for Real-time Interactive, Modeling, Analyses and Learning) is a toolbox for performing diagnostic tests on continuous processes, such as oil refinery process units, chemical plant process units, etc. PRIMAL enables an experimenter to design an experiment (choosing signals to sample, sampling rate, shape and other characteristics of test signals), acquire data, filter and analyze data, perform model estimation, model validation, and, in the near future (Real Soon Now, as Pournelle would tell), controller design and validation. The pleasant thing about PRIMAL is its interactiveness. The experimenter can design and re-design experiments, analyze and use data in real-time: if you see that your experiment is getting you where you want, you can re-design test signals, put in more signals to sample, change filter characteristics, use different model estimation methods, etc. PRIMAL is setup in such a way that it is possible to try out different data analysis tools running on the same data at the same time, in real-time. PRIMALs implementation is something like this: on top of everything is a module called the monitor, which interacts with the user, and which governs the running of other modules. the other modules are invoked by the monitor on user request, and communicate with the user through the monitor. All data is stored in data sets, a kind of meta-files. Each data set has an associated type (vector, matrix, text, model and a few others). The current system is implemented in a FORTRAN-77 subset, and runs on VAX/VMS. The source is some 150K lines of heavily commented source code. My question: is it worth the trouble to re-implement PRIMAL in an object oriented language. As you may have deduced from the foregoing, PRIMAL is heavily compute bound, but computes on very specific things. On the other hand, it is supposed to perform in real- time, and I don't know if that's possible with current OOLs. I am a virtual newcomer to OOLs, so I would like to receive any comments on this. Please EMAIL, and I will post a summary around august 15 (so please email before august 8). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - + + Harm Munk + My boss doesn't understand what - - Institute ITP-TUE/TNO - I'm doing as I don't understand + + Horsten 2 + him. - - 5612 AX EINDHOVEN - + + The Netherlands + - - Phone +31(40)474741 or - + + +31(40)474517 + - - - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ---------------------------------------- From: Andrew Hudson Organization: GTE Laboratories, Waltham, MA I would say that it is still too early to marry OOL's to real time processes. Many OOL's (Smalltalk, LISP-based OOL's, Postscript) have heap based garbage collections. This means that your tasks are subject to random garbage collections that stop everything for an arbitrary time while memory is coelesced. Not Only this but unless you are using some specially designed OOL (maybe C++, Objective C, or Forth+Objects) you will have no where nears the real time performance that you require. But should you undertake the taks you could be a pioneering forerunner! - Andrew Hudson GTE Labs ---------------------------------------- From: Ralph Johnson Subject: PRIMAL and OOP C++ is find for real-time programming and is as efficient as C. It does not have as many nice features as some of the other object-orientd languages, but it is certainly a lot better than FORTRAN. Thus, if you don't find a better language, I would suggest C++. I use C++ and Smalltalk. Smalltalk is much more fun, but is not suitable for real-time programming because of the garbage collection. ---------------------------------------- From: R. Vuurboom Organization: Philips Telecommunication and Data Systems, The Netherlands In article <795@eutrc3.urc.tue.nl> you write: > >My question: > >is it worth the trouble to re-implement PRIMAL in an object >oriented language. As you may have deduced from the foregoing, My feeling is that if your systems running fine and you don't need a design overhaul the answer is no. If on the hand you're having trouble with maintaining the fortran implemenation _and_ you're itching to redesign you might want to think about it. The only real choice (in terms of widespread availability and future proofedness) is C++ (even though Eiffel may be an even better language here). >PRIMAL is heavily compute bound, but computes on very specific >things. On the other hand, it is supposed to perform in real- >time, and I don't know if that's possible with current OOLs. I don't think this would be a problem C++ compiles to relatively efficient code. I get the feeling that you might be spending a lot of your time in the run-time libraries anyway and the difference in implementation between C/C++ and Fortran shouldn't be that great. I dont know about Eiffel here. -- Roelof Vuurboom ---------------------------------------- From: att.att.com!cbosgd!alice!shopiro It is hardly ever worthwhile to reimplement any working piece of code. If you are in a situation where you have to write new code (perhaps part of it based on some already existing piece of code), then you should think about what language to write it in. From the description you give, it seems you are in a good position to benefit from the advantages of C++. I don't think you should be worried about performance because you can optimize your inner loops in C++ just as you can with C. The performance of C++ looks like the performance of C, not like that of Lisp or Smalltalk. --- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229 ---------------------------------------- From: hansen@pegasus.att.com I see no conflict between your goals and OOP (Object Oriented Programming) techniques. I do see some conflicts between your goals and using a language which requires garbage collection, but that has nothing to do with OOP. OOP seems quite suited towards what you're designing. There are a number of languages which support OOP; some of them normally use garbage collection and others don't. The ones that do would probably not be appropriate to your project. (Note also that there are many non-OOP languages which normally use garbage collection, just as there are many which do not.) There is another question altogether about whether, since the package is already written in a non-OOL language, why rewrite it from scratch? You certainly won't be able to make much use of the existing code since OOP will undoubtedly cause you to rethink and redesign your code in another fashion. (You didn't ask, but I'll answer your implied question: Yes, I would consider C++ a good candidate for your project.) Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com ---------------------------------------- From: lsr@apple.com (Larry Rosenstein) In article <796@eutrc3.urc.tue.nl> exiphm@eutrc3.urc.tue.nl (h.munk) writes: > PRIMAL is heavily compute bound, but computes on very specific > things. On the other hand, it is supposed to perform in real- > time, and I don't know if that's possible with current OOLs. I think the common view of OOLs is that there is a performance penalty because of run-time dispatching. (By run-time dispatching I mean when you send a message to an object, there is some overhead above the normal procedure call.) If you use a langauge such as C++, then you get to specify whether to use run-time dispatching or not. If you don't use run-time dispatching, then there is no performance overhead compared to normal C. Even if you do use run-time dispatching, the C++ implementation imposes a very small overhead, which is constant regardless of your class structure. (In other words, it does not increase as you define a deeper class hierarchy.) You can use standard C contructs in the places that require the maximum performance (although you may not even need to do this with C++.) Apple's version of Object Pascal has a slightly larger run-time penalty, but our linker will optimize method dispatches to have no overhead if you do not require run-time binding. The result is the same as using C++, but is done for you automatically. (In C++ the programmer has to make the decision. The price of choosing compile-time binding is less flexibility on how that method can be overridden. Some programmers may prefer to make the decision, others may prefer to let the system optimize things where possible.) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1 ---------------------------------------- From: uunet.uu.net!microsoft!alonzo Organization: Microsoft Corp., Redmond WA In article <808@eutrc3.urc.tue.nl> you write: > >I posted this two weeks ago. > >Alas, I haven't received much response, yet. Maybe this has >got something to do with summer holidays and all that. > You question really makes me wonder why you want to reimplement your program. Do you have specific improvements to the program in mind? Is it currently too slow, or does it easily outperform its realtime constraints? What kind of maintenance problems have your run into? If the program is fine as it is, I cannot imagine it being worthwhile to reimplement it just for excercise. Your message sounds more like an advertisement than the detailed specification of a design that would lead one to prescribe an object- oriented language. In any case, serious reimplementation would hopefully involve complete redesign of the internals of your program. Hope this is helpful... ---------------------------------------- From: Tim Endres <oxtrap!time> Several comments: Object Oriented Languages have only one *inherent* inefficiency. Late binding. The dynamic or late binding of messages is what allows dynamic message passing up the inheritence tree at run time. Without this feature, much of the power of inheritence goes away. As you might suspect, late binding means "looking" for the right function to call at run time, clearly costing CPU cycles. Other than this, OOLs are generally more efficient than other languages, simply because of the development paradigm - reusability. Programs tend to be more efficiently written, and improvements made to critical code segments are "inherited" by all. Many OOLs allow the choice of early versus late binding, even within the same program. This would allow you to take advantage of late binding for non-real-time areas of the code, while retaining tight control over the execution of time critical code. I am not sure porting the system is a wise idea anyways. Why? Are you going to enhance it "significantly"? Do you need it on other platforms? Do you wish to re-write to improve the application? I do recommend OOLs for projects under the right circumstances. If you wish further discussion, please feel free to email. Tim. ---------------------------------------- From: jeff@pta.oz.au (Jeffrey Wong) Dear Harm, Regarding the above subject, 2 possible alternatives: 1: Do an evaluation of a product called DataViews. I am assuming here that you want to keep your existing investment in Fortran-77 intact. 2: Do an evaluation of a product called LWB (Laboratory Work Bench). This is a product sold by Masscomp (now Concurrent Computer Corporation). The assumption here is that you would rather have a integrated tool (hardware/software) to do your real-time data acquisition and modelling. Hope these suggestions are of some help. Regards, Jeffrey Wong. Pyramid Technology Australia. ---------------------------------------- From: raph@planet.bt.co.uk In comp.lang.c++ you write: >Dear Everybody, >I have a question concerning the appropriateness of OOLs for the >implementation of a package for real-time continuous process >diagnostics. >My question: >is it worth the trouble to re-implement PRIMAL in an object >oriented language. As you may have deduced from the foregoing, >PRIMAL is heavily compute bound, but computes on very specific >things. On the other hand, it is supposed to perform in real- >time, and I don't know if that's possible with current OOLs. >I am a virtual newcomer to OOLs, so I would like to receive any >comments on this. Please EMAIL, and I will post a summary around >august 15 (so please email before august 8). I have implemented a multi-tasking scheduler in C++. the main problem is that there are many components, tasks, devices, timers etc., that have to communicate with each other. This means that we finish up with a lot of 'friend' functions. The result is a bit messy, but I found the effort of converting from C to C++ worth-while. It force a change of mental attitude, a closer attention to what the objects of the system really were, and gave me better protection an isolation of components. Raphael Mankin raph@planet.bt.co.uk