Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: D Yuniskis on 21 May 2010 03:26 Hi John, John Larkin wrote: >>>> E.g., how would I even *begin* to assign part numbers to each >>>> of the software modules I create? >>> I'm talking about electronic parts, not software modules. We use a >>> "telephone number", like 123-4567. The first three digits are the >>> class (103- is the class for 0603 ceramic caps for example) and the >>> last 4 digits are the specific part. 103-1300 is the 10 pF one. >>> >>> We have rules for *everything*. >>> >>> The best way to control software modules is to not have them: use one >>> monolithic source file for a given project. We do assign a part number >>> and a revision letter to a piece of software, just like any other >>> engineering drawing. >> I reuse modules often. It allows me to make "inexpensive" >> solutions (instead of having to reinvent the wheel each time). > > I have an editor with advanced "cut" and "paste" features. Sure. But why cut and paste stuff when it already works "as is"? It's documented, there is a test suite for it, etc. >> It would be quite hard for me to edit 5-50MB source files! > > YIKES! Nothing, not even an OS, should be that big! <grin> Products require an OS + application(s). I work on *big* projects! :> But, if you think about it, it is not difficult to have 10MB for a small-ish assembly language program. Assume a line of code generates 1.5 bytes (most generate at least *one* byte of code :> ). Most ASM opcodes are 3 or 4 chars. Put a tab on each side of it gives us 5 or 6. Put some arguments after it (register list, symbolic address of an operand, etc.) probably adds at least 10 chars. One or more tabs out to a "comment column" followed by 30 or 40 characters of commentary (?) I.e., it's easy to have 50 characters on that line for that 1.5 bytes of generated code. So, 100KB of code is ~3.5MB (note that we haven't included any other overhead -- like EXTERNs, etc. -- nore any paragraphs of pure commentary). I just looked at an old Z180 project that I did. Almost 9MB of sources. Looks like it compiled to about 200K. So, that would be 4.5MB/100KB code (roughly in line with my shirtsleeve estimate above). My TCP/IP stack is over 100 files and a couple of megabytes of source (C with a tiny mix of ASM). A quick peek at the NetBSD sources show ~20,000 files and > 100MB for just the kernel (i.e., the equivalent of "Linux" -- without any of the other OS utilities or applications). My multimedia OS is about a third of that -- but, it doesn't have to run on 30 different architectures, support umpteen gazillion different I/O boards, etc. No, it's just not practical to deal with any decent size product as "one file"... > :> >> And, incredibly inefficient having to compile all of that in one >> piece. (besides the drawback of polluting the namespace therein) > > My PowerBasic programs rarely take a full second to compile. Building my entire OS from scratch ("make clean all") takes several minutes on a 3G machine. Some of this would be sped up if everything was in one giant file (less thrashing around in the filesystem). But, since I rarely work on more than two files at a time, I can do a typical incremental build in just a few seconds: compile the two files that have changes, link and done. > What's a namespace? If you glue all of your modules together into one giant file, then you have to ensure that nothing from any different modules has the same name as something in *another* file E.g., if I have a (private/static) scrap routine called "copy()" that is used in "window.c" to perhaps make a copy of a "window". Now assume I want similar functionality for *menus*. So, in "menu.c" I create a (private) routine called "copy()". Nothing outside of menu.c ever references the "copy()" that is inside menu.c. Likewise, nothing outside of window.c ever references the copy that is inside window.c. I.e., each "copy" is private to the module in which it is defined. Now, if I glue all of window.c and all of menu.c together into one big file, there will be *two* "copy()" routines. Two identical names in the single file-scope namespace. (i.e., each name within the file has to be unique). (you can actually work around this -- but, why work around something when it just gives you a less desirable result? Namely, an oversized source file?) Sort of like having two variables each called "X" and expecting them to have different values and be accessed uniquely.
From: Tim Williams on 21 May 2010 10:27 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht5c6n$mf$1(a)speranza.aioe.org... > I just looked at an old Z180 project that I did. Almost 9MB of > sources. Looks like it compiled to about 200K. So, that would > be 4.5MB/100KB code (roughly in line with my shirtsleeve estimate > above). Hmm, I've got a 70k .asm file (x86, for MASM) which compiles to I think 9k code (plus a few large arrays). Only a ratio of 7? Gee, now I look lazy at commenting... ; ; Multiplies a fixed-point DWORD (16.16 format) by a fraction (0.16). ; Input: on stack (DWORD, WORD) ; Output: DX:AX = DWORD product. ; fixedByFrac PROC near USES bx cx si di fixed:dword, frac:word mov di,wpr fixed+2 mov ax,wpr fixed mov bx,frac xor si,si test bx,bx ; get fraction sign jns @F Ehh, looks easy enough... maybe I just read asm better? :-p Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: Didi on 21 May 2010 11:13 On May 21, 10:26 am, D Yuniskis <not.going.to...(a)seen.com> wrote: > ... > But, if you think about it, it is not difficult to have > 10MB for a small-ish assembly language program. Assume a line > of code generates 1.5 bytes (most generate at least *one* > byte of code :> ). Most ASM opcodes are 3 or 4 chars. > Put a tab on each side of it gives us 5 or 6. Put some > arguments after it (register list, symbolic address of an > operand, etc.) probably adds at least 10 chars. One or more > tabs out to a "comment column" followed by 30 or 40 characters > of commentary (?) I.e., it's easy to have 50 characters > on that line for that 1.5 bytes of generated code. Hi Don, my average is about 34 characters per line over the years, http://tgi-sci.com/dsv/scnt3.gif :-). I write comments on every line, headers etc., but there are null lines to compensate for that, I guess (a sort of typical largish source file is http://tgi-sci.com/vpaex/vpast1.sa . Part of a much larger picture, of course (1 of 46 files which make the vpa assembler(compiler?)). > ... > My TCP/IP stack is over 100 files and a couple of megabytes of > source (C with a tiny mix of ASM). Into how much object code does that compile? Seems comparable to my tcp/ip stack for dps, http://tgi-sci.com/misc/tcp.gif . What is listed there is just for tcp, ip, udp, ppp - dns and above stuff are elsewhere. And some helper objects which are already moved elsewhere (memory_pool etc., turned out handy and I moved them for more common usage). The object code this list produces is about 230k (for power, but it is written only for power, no backwards 68k compatibility, at least not without some work). Would be an interesting comparison between toolchains and languages, I guess. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
From: Phil Hobbs on 21 May 2010 11:54 On 5/19/2010 7:38 PM, John Larkin wrote: > On Wed, 19 May 2010 13:23:52 -0700, D Yuniskis > <not.going.to.be(a)seen.com> wrote: > >> Hi John, >> >> John Larkin wrote: >>> Some of my PBCC utilities (Windows console apps) with basic screen >>> menus but not official Windows gui stuff, compile to numbers like 32K. >>> I have a test program for a digital delay generator, full of menus and >>> RS232/ethernet access to the DUT, that's 44K. >>> >>> Our pretty extensive material control system is a 400 kbyte EXE, 18K >>> line source file. The size isn't so important as are the speed and >>> reliability. >> >> For a lean, poor man's "GUI", consider using a manu system >> atop curses. *Very* fast (even over a serial link!) and >> has all the "feel" of a GUI without the G. > > Here's our parts thing, home page. It's all single-letter keystroke > commands and prompts. It a blast to drive. > > ftp://jjlarkin.lmi.net/MAX.jpg > > You can look at all parts, do searches, do where-used, browse parts > lists, see datasheets/photos/links/engineering notes. Parts selected > in one context are carried over into others... you can prowl a parts > list, highlight a part, escape out, and the part is featured on the > home page. Then do where-used, or open the part data file, or enter > the total parts report at that point. > > John > > > Curses is well named--it _almost_ does what you want, but never quite. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
From: Phil Hobbs on 21 May 2010 11:58
On 5/20/2010 2:03 PM, D Yuniskis wrote: > Hi Joel, > > Joel Koltner wrote: >> "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message >> news:ht3pie$ncb$2(a)speranza.aioe.org... >>> You developed this in-house? Why not use something off-the-shelf? >>> (OTOH, most OTS solutions force you to do business "their way") >> >> I've wondered the same thing, Don (see, there, I got your name correct > > Actually, it's *Bob*... ;-) > >> :-) ) -- but I've now worked at two small companies that spent more >> than three years trying to get expensive commercial MRP systems fully >> deployed without success (...company #1 went belly-up, company #2 is >> still working on it), so I give John a lot of credit for solving the >> problem himself and just getting on with the core part of his business >> -- design engineering. > > I worked at one (small-ish) firm *when* MRP was deployed. > The most important aspect of the roll-out was getting everyone > onboard -- everyone in the company "went to school" to > understand the issues involved. > >> The only small company I've worked for that had their MRP system >> "under control" was using Greapt Plains (now Microsoft Dynamics). No >> one really liked it, but it did at least get the job done. > > The problem I see with *all* OTS "business solutions" is they > want to impose their business logic on *your* business. They > want you to process and use data the way *they* envisioned. > > In addition, they impose arbitrary constraints on the data, etc. > Is there some reason a "description" has to fit in N characters? > Or that a P/N has to fit a certain template? etc. > > I think this is a result of misplaced efficiency tradeoffs. > I.e., they want to be able to index/search data "quickly"... > saving a few micro/milliseconds on each operation. Yet, they > are oblivious to the seconds, minutes or even *hours* of > "real time" delays that these "efficiencies" cost -- when > a user can't locate a particular item (because the item's > ABBREVIATED DESCRIPTION was abbreviated inconsistently or > used one keyword instead of another, etc.). > > This, I think, is an outgrowth of the same sort of > ridiculous mindset that people initially bring to > *organizing* data. E.g., how many part numbering systems > have data embedded *in* the part number that tries to > describe the item? (isn't that the role of the *description* > tied to the P/N??) People impose structure on things > unnecessarily instead of letting the machine do that on > their behalf. > > E.g., when I started preparing documents, standards, etc. > here, I used a much more commonsense approach: I started > with *1* :> (instead of something artificial like > 1985-SPEC-SFW-001.1 -- the ".1" being a revision level, etc.) > Then, moved on to "2". > > Data should largely be free-form -- except where it *can't* :> > This applies to part numbers, object (file) names, etc. Once > you start imposing artificial structure, you start forcing > things to be "done your way" -- which, typically, exposes > some *flaw* in "your way", later (once you are *very* pregnant!) > > Put smarts in the system to be able to *understand* the data. It's sort of nice to be able to look at a part number and see whether it's a capacitor or a BNC connector, though. That doesn't have to have descriptions embedded in the part number, but it does need a bit of thought, e.g. numbers starting with '0' are subassemblies, '1', resistors, '2', capacitors, and so forth. Takes an extra couple of digits but makes life a lot easier. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net |