Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!fluke!mce From: mce@tc.fluke.COM (Brian McElhinney) Newsgroups: comp.sys.mac Subject: Re: The Mythical Man Month Message-ID: <6211@fluke.COM> Date: 5 Dec 88 20:56:54 GMT References: <6176@fluke.COM> <10330090@accuvax.nwu.edu> Sender: news@tc.fluke.COM Organization: SRS Recursive Software, Castrovalva, WA Lines: 57 In article <10330090@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: >Assembly language is _not_ inherently more complex. How can that be when in assembly language: You have to track register usage yourself. You have to check calling sequences yourself. You have to check parameter types yourself. You have to allocate and manage local stack space yourself. You have to do pointer arithmetic yourself. That's a lot of additional complexity. >I program in assembler as my language of choice for two reasons: (1) I tend >toward projects which either have to be very small, very fast, or very >intimate with the operating system, and (2) I can understand better what is >happening in a program I write in Assembler. The problem is not inherent >complexity, it's familiarity. The complexity is still there, even if you're familiar with it. Try working on a large project (half dozen of more people all working on the same code) and then think about complexity due to the tools used versus complexity due to the problem being solved. At some point you have to pick the "best" tools and make sure everyone knows how to use them. For your domain there may not be an appreciable difference. That does not mean that there is no difference. >To my mind, _every_ piece of code should be as efficient as possible; >anything else is simply wasting the users time. (Granted, a microsecond >wasted is not a loss. But these things add up). You assume the users time is more valuable than development time. In an ideal world that would be true, but in the real world you also have to worry about getting the job done. A program that does not exist is infinitely slow! >If compilers truly did generate code as efficiently as assemblers, why, tell >me why, nearly everyone agrees that "For time critical or tight loops >assembler should be used to optimize" Because compilers do not generate code as efficient as humans do. They can come very close though (they may never be able to, but I wouldn't bet on it). More advanced architectures practically require that you use only high-level languages (SPARC and MIPS, for example). >Tell me: What code is non-critical? That depends on your criteria. You mean time critical to the user, and the answer is hardly any at all. Check out the response time in MacApp; plenty fast and definitely high-level. If there is a problem with response time you can almost always fix it by designing a faster algorithm. An interesting example might be FullWrite. I have zero inside knowledge, but I'll go out on a limb and say that it's slowness is due it's design, not the implementation language. An assembly language version would not be appreciably faster. Brian McElhinney mce@tc.fluke.com