home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / benchmar / 1878 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  3.2 KB
  1. Xref: sparky comp.benchmarks:1878 comp.arch:11757 comp.misc:4636
  2. Newsgroups: comp.benchmarks,comp.arch,comp.misc
  3. Path: sparky!uunet!rde!ksmith!keith
  4. From: keith@ksmith.uucp (Keith Smith)
  5. Subject: Re: Who wants faster machines?
  6. Organization: Keith's Computer, Hope Mills, NC
  7. Date: Thu, 17 Dec 92 03:59:31 GMT
  8. Message-ID: <1992Dec17.035931.1180@ksmith.uucp>
  9. Followup-To: comp.misc
  10. References: <1f2qefINNfaq@uranium.sto.pdb.sni.de> <1992Dec4.103129.524@fasttech.com>
  11. Lines: 54
  12.  
  13. In article <1992Dec4.103129.524@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:
  14. >In <1f2qefINNfaq@uranium.sto.pdb.sni.de> mollers.pad@sni.de (Josef Moellers) writes:
  15. >
  16. >>I'd say that 60% of all added performance is easily
  17. >>souped up by improvements in the man-machine interaction.
  18. >
  19. >>THAT's what we need fast machines for!
  20. >
  21. >About 20% is useful improvement and about 80% counteracts software bloat.
  22. >
  23. >The architects and h/w guys keep making machines faster and faster and the
  24. >software keeps getting less and less efficient.
  25.  
  26. Sofware bloat, software bloat, naa, naa, 'naa, naa, ..., naa.
  27.  
  28. Jeez.
  29.  
  30. I look at some of the code I wrote for my Z80 in assembler.  Zillions of
  31. hours, for not much of a program.  Spaghetti code to the max. 
  32. Commented, and I STILL can't follow what I was doing.  With the current
  33. cost of cheap storage, and CPU cycles, I'll gladly take a little
  34. software bloat, for simple readability, and maintainability, along with
  35. avoiding alot of hand coding in assembler for speed & size.
  36.  
  37. I'll also disagree with the 20/80 ratio you have come up with, as it
  38. relates to performance.  What we are seeing today in the business world
  39. are *STABLE* *RELIABLE* database systems that run on commodity hardware,
  40. in a flexable enviroment.  This same functionality 15 years ago would
  41. have required an IBM 34/36 style equivilance, with comperable amounts of
  42. fixed storage. Indeed, I replaced same with a 33Mhz 32 bit "pee cee", as
  43. opposed to a 16Mhz 32 bit Midrange.  The performance was *FAR* in excess
  44. of doubled, and yet the storage requirements, and program sizes actually
  45. SHRUNK.
  46.  
  47. As the software that runs more complicated systems get's more
  48. complicated (multi-user, multi-task, journaling filesystems, graphical
  49. interfaces, real-time processing ...) the programs *HAVE* to increase in
  50. complexity at a similar expotential rate.  The number of interactions
  51. between different software modules will increase expotentially also, as
  52. you add on new modules to handle ever more complex tasks, as each task
  53. that gets effected will increase in size.
  54.  
  55. Writing spaghetti code that weaves thru 50 sections of code blind fast
  56. is great, and you can probably follow it.  Writing same thru 1000
  57. sections of code is simply idiotic to consider.  In turn the code in
  58. each section will swell, as it handles more function in order to
  59. insulate itself from a breakdown elsewhere, then splits, etc.  Is it
  60. bloat?  Yes.  Is it bad? No, simply a neccessary part of software
  61. evolution IMHO.  Does it affect performance?  Sure!  Now we can run the
  62. machines all day without reseting it 5 times ...
  63. -- 
  64. Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
  65. Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
  66. Somewhere in the Styx of North Carolina ...
  67.