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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c7b637f8b783b7c X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,c7b637f8b783b7c X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,c7b637f8b783b7c X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,c7b637f8b783b7c X-Google-Attributes: gidf43e6,public X-Google-Thread: 107d55,c7b637f8b783b7c X-Google-Attributes: gid107d55,public X-Google-Thread: 103376,c7b637f8b783b7c X-Google-Attributes: gid103376,public From: Dave Sparks Subject: Re: The great Java showcase (re: 2nd historic mistake) Date: 1997/09/03 Message-ID: #1/1 X-Deja-AN: 269747944 References: <34023FC9.59E2B600@eiffel.com> <3404670B.C3A2C4A2@pagesmiths.com> <01bcb38a$8ddc1200$1c10d30a@ntwneil> <1jwoh6hm2mr.fsf@nortel.ca> <1jwoh6bmulc.fsf@nortel.ca> X-Attribution: DaveS X-Lines: 72 X-NNTP-Posting-Host: sisyphus.demon.co.uk [158.152.61.247] Organization: to be supplied Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.java.tech,comp.lang.c++ Date: 1997-09-03T00:00:00+00:00 List-Id: >>>>> "MC" == Mike Charlton writes: MC> Dave Sparks writes: >> >>>>> "MC" == Mike Charlton writes: >> MC> ... >> MC> I have worked with both large C++ projects and large projects using a MC> proprietary language with automatic memory management. Yes, with C++ MC> we spent a lot of time thinking about memory. However, using MC> automatic memory management, we spent a lot of time thinking about MC> performance. I'd say it's a bit of a toss up. No one solution will MC> work well for every problem. >> Are you saying that when you used C++ you spent so much time on >> memory management that you couldn't afford to think about performance? MC> I'm not sure if that was meant to be a rhetorical question, but in MC> case it wasn't -- the answer is "No". We just didn't need to spend MC> very much time tweaking performance. My point was that automatic MC> garbage collection makes life easier for you. But it doesn't come MC> for free. You *can* overcome performance difficulties, but I figure MC> it takes about as much effort as memory stuff using C++ (IMHO, anyway MC> -- YMMV). The question _was_ rhetorical - the point being that when you have one _huge_ problem, the other, smaller, problems disappear into the background and can get forgotten. We've been using a byte-coded interpreted language with mark-sweep garbage collection for over ten years, and the GC costs are typically about 1% of the total. Individual GCs take less than 0.1 seconds with a 2Mb heap on a SUN SparcStation 5, which is not a problem in our context. We used to have performance problems, but we solved them by re-engineering the application (delivering the 10::1 improvement we'd had to promise to get the funding). It's doubtful that this product would have been written in C or C++, but if it had been I don't think it would ever have met our current performance expectations. We also have C and C++ code where memory management is a very difficult problem, partly because some of the code involved is not under our control. This area also needs re-engineering, because the risk of memory leaks is unacceptably high. This re-engineering will not be easy. Java performance does seem to be poor at the moment, but I expect it to improve. Remember that at one time performance was cited as the reason for routinely using assembly code rather than a high-level language. This claim is uncommon today, and I expect to see a similar change in attitude over the choice of fully-compiled or compiled-and-interpreted languages. I do know of one case, from twenty years ago, where two versions of a COBOL compiler were written simultaneously by two separate teams. One version was written in assembly code, while the other used a purpose-designed compiled-and-interpreted language, which was developed as part of the project (and never used for any other purpose). Each team beleived that its method was the better one, and was determined to prove it. When the initial versions of the copilers were compared, the assembly-code version was faster. A month later, the compile-and=interpret team, using the instrumentation that the interpreter made possible, had improved their compiler's performance enough to beat the assembly-coded version (where performance improvements could not be accurately targeted). (The requirement was to replace an earlier COBOL compiler badly written by assembly-code programmers unwillingly using a high-level fully-compiled language.) -- Dave Sparks, Staffordshire, England