home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / msdos / programm / 10849 < prev    next >
Encoding:
Text File  |  1992-11-22  |  2.5 KB  |  49 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!cunews!watson
  3. From: watson@sce.carleton.ca (Stephen Watson)
  4. Subject: Re: Very puzzling struct problem!
  5. Message-ID: <watson.722463452@bellatrix.sce.carleton.ca>
  6. Sender: news@cunews.carleton.ca (News Administrator)
  7. Organization: Carleton University
  8. References: <1992Nov21.221745.23588@jarvis.csri.toronto.edu> <1992Nov22.040512.6906@u.washington.edu>
  9. Date: Sun, 22 Nov 1992 20:17:32 GMT
  10. Lines: 39
  11.  
  12. lectro@stein.u.washington.edu (Jonathan Maier) writes:
  13.  
  14. >In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu> ematias@csri.toronto.edu (Ummm... me!) writes:
  15. >>- having 16 integer variables in the struct would work.
  16. >>- having 32 integer variables in the struct would work.
  17. >>- having 48 integer variables in the struct would NOT work.
  18. >>- having 64 integer variables in the struct would work.
  19. >>- having 80 integer variables in the struct would NOT work.
  20. >>- having 96 integer variables in the struct would NOT work.
  21. >>- having greater than 96 ints in the struct would NOT work.
  22.  
  23. >It looks like the number of variables should be 2 raised to some power
  24. >(ie- 16(=2^4), 32(=2^5), 64(=2^6), etc.).  You'll probably notice that
  25. >some things are more "efficient" if they map directly into the binary
  26. >(base 2) scheme that the computer is based on.
  27.  
  28. Are you creating/destroying these things dynamically? (malloc/free,
  29. new/delete)
  30.  
  31. I've noticed that heap gets allocated in paragraphs (multiples of 16 bytes)
  32. since that's the minimum increment of a segment pointer.
  33.  
  34. Possibly there's some optimization in the allocation function which
  35. allows it to take short cuts when the request is for exactly (2^n)*16
  36. bytes (no that can't be right, it doesn't take into account the space
  37. for the next-block pointer, which is included in the allocated block).
  38.  
  39. In any case, my wild guess is that setting your data up so it aligns
  40. on exact 2^n paragraph boundaries is simplifying the segment-pointer
  41. arthmetic somehow.  Unless there's a real nuts-and-bolts EXPERT out
  42. there (maybe on Monday AM?), you'd have to look at the assembler code
  43. to find out what the difference was between the fast and slow cases.
  44. --
  45. ==Steve Watson: watson@sce.carleton.ca===Carleton University, Ottawa, Ontario==
  46. | The above is the output of a 7th-order Markovian analysis of all posts on   |
  47. | this group for the past month.  Not only is it not Carleton's opinion, it's |
  48. | not even *my* opinion: it's really just a mish-mash of all YOUR opinions!   |
  49.