home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1769 < prev    next >
Encoding:
Text File  |  1992-12-12  |  4.0 KB  |  120 lines
  1. Path: sparky!uunet!enterpoop.mit.edu!eru.mt.luth.se!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <5368@miramon.lulea.trab.se>
  6. Date: 12 Dec 92 18:10:40 GMT
  7. References: <1992Dec07.222242.18703@microsoft.com>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 108
  10. X-Newsreader: TIN [version 1.1 + PL8]
  11.  
  12. Jim Adcock (jimad@microsoft.com) wrote:
  13. : dag@control.lth.se (Dag Bruck) writes:
  14. : |In <comp.std.c++> ralpht@meaddata.com (Ralph W. Trickey) writes:
  15. : |>|> >
  16. : |>|> >  I don't think that requiring total ordering would break any existing
  17. : |>|> >program, but it would break quite a few existing compilers.
  18. : |>
  19. : |>This language change that would slow down existing programs. Possibly
  20. : |>to the point where they no longer meet specifications. I consider this
  21. : |>breaking programs.
  22. : |
  23. : |Could someone do the net a great favour and check it?  There's a lot
  24. : |of speculation but nobody has measured how severe the slow-down would be.
  25.  
  26. : People who are experienced with PCs don't have to measure this problem
  27. : because they are well aware of the issues and the code sizes involved.
  28. : What you ask for is essentially the same thing as "Huge" model which
  29. : PC compilers support but *which PC programmers don't use* -- because its too
  30. : expensive.
  31.  
  32. : But, since *you* request the numbers, here's a simple example:
  33.  
  34. : Compaq Deskpro 386/20
  35. : C7 compiler all optimizations.
  36.  
  37. : Comparing an pointer inner loop, incrementing one pointer and comparing
  38. : with another pointer within a loop.
  39.  
  40. : The "total ordering" approach loop executes approx 3X slower than
  41. : the typical PC segment:offset approach.
  42.  
  43. Jim, I think your result is slightly misleading, since the "huge"
  44. model involves other overhead than pointer comparison (as someone
  45. already pointed out).  Here are more accurate measures:
  46.  
  47. Dell 486/33
  48. MSC 6.00A compiler all optimizations (/Ozax).
  49.  
  50. Same test as Jim, test program at end.
  51.  
  52. The first two numbers are for the normal "large" memory model.
  53. The last two numbers are for the "huge" model.
  54. /AL:    p1 < p2            28 sec.
  55. /AL:    (long)p1 < (long)p2    55 sec.
  56. /AH:    p1 < p2            96 sec.
  57. /AH:    (long)p1 < (long)p2    87 sec.
  58.  
  59. So, like Jim, I find a more than 3x worst-case speed reduction
  60. when switching from "large" to "huge".
  61.  
  62. However, the real slowdown is just 2x (55/28).  Note that the figure
  63. I gave in an earlier posting (33 %) was for unoptimized code.
  64.  
  65. Side note: It seems to pay off to cast to long in the "huge"
  66. model.  In this case the programmers knows more than the compiler
  67. is allowed to (that the pointer won't travel over more than 64 K).
  68.  
  69. I would think the size overhead Jim mentioned (28 bytes) is excessive too.
  70.  
  71. Other than the measurements, I agree with Jim.  The total
  72. ordering penalty should only be payed when used.  The ptrcmp()
  73. function proposed in another posting achieves just that.
  74.  
  75. Test program follows (press 'n' to skip).
  76.  
  77. #include <stdio.h>
  78. #include <stdlib.h>
  79.  
  80. #define LOOPS 100L * 1000L
  81.  
  82. int main(void)
  83. {
  84.    char* ap = (char*) malloc(65000U);
  85.    char* bp = (char*) malloc(65000U);
  86.    char* aend = ap + 1000;
  87.    long i;
  88.  
  89.    if ( ap < bp || bp < ap ) {
  90.       printf( "p1<p2 is probably totally ordered.\n" );
  91.    } else {
  92.       printf( "p1<p2 is not totally ordered.\n" );
  93.       if ( (long)(ap) < (long)(bp) || (long)(bp) < (long)(ap) ) {
  94.          printf( "\tbut (long)p1<(long)p2 is probably totally ordered.\n" );
  95.       }
  96.    }
  97.  
  98.    system( "echo. | time" );
  99.    for ( i = 0; i < LOOPS; ++i ) {
  100.       char* p = ap;
  101.       while ( p++ < aend )
  102.          { }
  103.    }
  104.    system( "echo. | time" );
  105.    for ( i = 0; i < LOOPS; ++i ) {
  106.       char* p = ap;
  107.       while ( (long)(p++) < (long)(aend) )
  108.          { }
  109.    }
  110.    system( "echo. | time" );
  111.  
  112.    return 0;
  113. }
  114.  
  115. -- 
  116. --------------------------------------------------------------------------
  117. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  118. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  119. --------------------------------------------------------------------------
  120.