KVC@ENGVAX.SCG.HAC.COM.UUCP (04/21/87)
> If we can't find any better way we are > going to be forced to link all of our object code (currently about 13 > Megabytes of object code constituting 66 separate executables) into one > gigantic executable (gag!). PLEASE DO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I've got no qualms with running a large executable image. That's what virtual memory and cheap physical memory is for. Why force the system to do something it does inefficiently (create processes -- especially with SPAWN! At least you could use CREPRC!) when you can let VMS handle the job in the manner for which it was designed? Forgive me if my tone's a little harsh, but I've spent years putting up with a software system, Project/2 from PSDI, with just this problem. These people (PSDI) run scores of separate little images in subprocesses. It's really exciting to watch the system thrash around as it creates/deletes/context-switches all these processes. It even looks like P2 tries to cache it's processes (I'm not certain of this, though) and it's still a dog. PSDI once explained that they use multiple images because it makes development easier -- they don't have to wait around to relink everything on a build. Seems like a pretty lame excuse to me, I suspect they've heard of sharable images. This explanation is a few years old, maybe they have a more legitimate excuse. Using VMS facilities (e.g. sharable images) and reasonable development tools, the MATHLIB project I'm associated with has never had a problem maintaining a large software system with several large executables. Most MATHLIB executables require in excess of 2 to 3 Mb when they start up. Performance is excellent. VMS makes it a snap to produce a large system while taking a modular approach to the design. Maybe you need to step back and reassess your application. One 13 Mb image may indeed be excessive, but is it any more so that 66 separate little ones? If it's a big system, expect some big images to come out of it. Be reasonable, use separate images where appropriate, but don't hesitate to make things big when/if it makes sense! The performance gains you realize may be considerable! /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co.
tedcrane@batcomputer.tn.cornell.edu (Ted Crane) (04/22/87)
In article <8704220233.AA01827@ucbvax.Berkeley.EDU> KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso) writes: >> If we can't find any better way we are >> going to be forced to link all of our object code (currently about 13 >> Megabytes of object code constituting 66 separate executables) into one >> gigantic executable (gag!). > >Using VMS facilities (e.g. sharable images) and reasonable development tools, >the MATHLIB project I'm associated with has never had a problem maintaining a >large software system with several large executables. I'd recommend going the multiple sharable image route (or the load-the-image- at-runtime route) also. If you can isolate chunks of your program (for example, a set of matrix manipulation utilities which might reference each other, but do not generally call back to the main program), then by all means, build them into a sharable image. The main program can link with this image. Positive results: Relinks are quicker. You're either linking the (smaller) sharable image or the main image which is now referencing the resolved symbols in the sharable images. You save physical memory and disk space. If more than one program uses the sharable images, only one copy if the sharable part is kept on disk (unless you choose otherwise). If, by some lucky chance, you run more than one copy of (or two separate programs) a program that references the sharable image at the same time, then physical memory can be shared between the two processes. Increased modularity. Divide the work and conquer. Developers are responsible for a smaller, more manageable piece of code. Fewer "global" variables, etc. Problems: Someone has to learn how to create sharable image. Easy enough, look in the linker manual. Another alternative is to make use ofthe LIB$FIND_IMAGE_SYMBOL routine. This way, you don't even have to link the utility programs into the main image. You call that routine and VMS maps the requested image into your process' address space AT RUNTIME! You also get the address of a routine which you can call to take advantage of the utility's functionality. Anyway, I agree with Kevin that 66 separate programs is not a fun way to go. Probably bad for system response, too. -- - ted crane, alias (tc) tedcrane@tcgould.tn.cornell.edu BITNET: tedcrane@CRNLTHRY tedcrane@squid.tn.cornell.edu DECnet: GOPHER::THC
jkw@a.UUCP (04/23/87)
Try using SYS$CREPRC to create either sub-processes or detached processes from within an image -- it will be considerably faster than SPAWN.
ted@blia.UUCP (Ted Marshall) (04/23/87)
In article <780@batcomputer.tn.cornell.edu>, tedcrane@batcomputer.tn.cornell.edu (Ted Crane) writes: > Problems: > Someone has to learn how to create sharable image. Easy enough, > look in the linker manual. Maybe not so easy of a lot of people. The linker manual leaves out a lot of details for the non-VMS-system-hack. At the Fall 1986 DECUS Symposium, I presented a paper titled "Ins and Out of VMS Shareable Images" that I think makes the job a little easier. It is printed in the Proceedings of the symposium (page 535). (If someone really needs to see this and can't get ahold of a copy of the Proceedings, send me a message (e-mail addresses below) with your paper-mail address and I will mail you a photo-copy. Please, only if you really need it.) P.S. I recommend that you get the printed paper instead of the audio tape of my presentation. In addition to incorporating several points brought up in the question & answer section, I really do write better than I publicly speak. -- =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me axxxg
jkw@a.UUCP (04/23/87)
> Try using SYS$CREPRC to create either sub-processes or detached processes > from within an image -- it will be considerably faster than SPAWN. Almost forgot...Try installing the image(s) you want to run -- this should also help decrease activation time.