home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / amateur / 398 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  4.4 KB

  1. Xref: sparky alt.amateur-comp:398 comp.lang.c:18821 comp.lang.c++:18343 comp.misc:4691
  2. Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc
  3. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!erc
  4. From: erc@netcom.com (Eric Smith)
  5. Subject: Re: What is Object Oriented Programming? Is C doomed?
  6. Message-ID: <1992Dec23.134325.27585@netcom.com>
  7. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  8. References: <1992Dec19.194156.17196@ucc.su.OZ.AU> <1992Dec19.224654.25483@netcom.com> <1992Dec23.092700.2450@ucc.su.OZ.AU>
  9. Date: Wed, 23 Dec 1992 13:43:25 GMT
  10. Lines: 90
  11.  
  12. In article <1992Dec23.092700.2450@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13. >>>>But if you need bidirectional random access, you have to allocate the
  14. >>>>entire maximum size in advance.
  15. >>>
  16. >>>    There are NO 'you have to .. ' cases surely, even if
  17. >>>I give some myself now and then :-) And allocating fixed maximums
  18. >>>is one of the things we want to avoid completely except in truly
  19. >>>extreme cases.
  20. >>
  21. >>As proof that you have to allocate the maximum size in advance, the time
  22. >>it takes to change the allocation and access one element is more than the
  23. >>time it takes to access one element without changing the allocation.  The
  24. >>originally stated requirement for it to be considered random access was
  25. >>that any element could be accessed as fast as any other.  Therefore it is
  26. >>not random access by that definition in that case.  QED.
  27. >
  28. >    You proof depends on the statment that the time taken
  29. >to access one element is less than the time taken to reallocate
  30. >and access one element. This need not be so. Whats to stop
  31. >me counting off exactly one second on all operations,
  32. >then your original requirement of equal access time would
  33. >be satisfied and your proof invalid.
  34.  
  35.  
  36. The purpose of counting off one second is to waste time to hide the
  37. fact that it isn't random access.
  38.  
  39.  
  40. >
  41. >    This sort of analysis is usually done using
  42. >dependencies on the sizes, for example the time
  43. >taken to scan a linked list is O(n) for n elements,
  44. >and no amout of delaying will fix this.
  45. >
  46. >    So what you should have said was that
  47. >if you want constant, i.e. O(1) access you have to
  48. >preallocate the array, because reallocation is O(n).
  49. >This proves nothing, however: you have to show
  50. >indexed access to contiguous storage is the only
  51. >O(1) access method.
  52.  
  53.  
  54. My proof did not mention indexed access nor contiguous storage.
  55.  
  56.  
  57. >
  58. >    Suppose I use a linked list with a preallocated cache.
  59. >It provides O(1) access and only wastes a fraction of the space
  60. >of a completely preallocated array (unless the whole array is used
  61. >up, in which case it wastes a bit more). It is somewhat slower,
  62. >of course, and that preallocated cache *is* an array of course :-)
  63.  
  64.  
  65. Each cache miss causes a delay, and therefore it is not random access.
  66.  
  67.  
  68. >
  69. >    In practice, more advanced techniques can yield only
  70. >slightly slower performance than the array that are close
  71. >enough to being constant time over the usable memory of your
  72. >computer, without the huge overhead incurred by preallocting
  73. >all memory to one array.
  74.  
  75.  
  76. I said nothing about preallocating all memory to one array.  My point
  77. was that if you want bidirectional random access you have to predict
  78. the maximum size in advance and allocate that much memory in advance.
  79.  
  80. To clarify what I mean by random access, consider a program whose
  81. access is literally random.  I.e., every access is driven by a
  82. random number, such that any item is as likely to be retrieved as
  83. any other.  Now consider moving the implementation from a fixed
  84. array to a linked list, and calculate the performance hit.  No
  85. amount of cache will help much unless it comes close to being on
  86. the same order of magnitude as the entire size of the storage,
  87. because, for example, if the cache is 10% of the storage size, 90%
  88. of all accesses will be cache misses.
  89.  
  90. There are lots of ways to implement random access storage, not just
  91. fixed arrays, but you do have to allocate the entire maximum size in
  92. advance if you want bidirectional random access.
  93.  
  94. Fortunately, applications that need bidirectional random access are rare.
  95. Random retrieval is much easier that random bidirectional access because
  96. there is no need to allocate the maximum size in advance.
  97.  
  98. But even for just random retrieval, it is hard to see how you could do
  99. it with a linked list.  Linked lists are for sequential access.  They
  100. are of course very handy, but that is because the majority of data
  101. retrieval applications only need sequential access, not random.
  102.