home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8543 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.1 KB  |  42 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!sun4nl!alchemy!ruunfs!hooft
  3. From: hooft@fys.ruu.nl (Rob Hooft)
  4. Subject: Re: Jumptable Performance (Was: Re: shared libs - can everyone be happy with this?)
  5. Message-ID: <1992Aug18.154149.26416@fys.ruu.nl>
  6. Organization: Physics Department, University of Utrecht,  The Netherlands
  7. References: <1992Aug17.144719.1961@crd.ge.com> <1992Aug17.151311.29507@ods.com> <NOP.92Aug17135014@theory.Mankato.MSUS.EDU> <1992Aug18.080437.3944@fys.ruu.nl> <1992Aug18.140858.3484@crd.ge.com>
  8. Date: Tue, 18 Aug 1992 15:41:49 GMT
  9. Lines: 31
  10.  
  11. In <1992Aug18.140858.3484@crd.ge.com> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
  12.  
  13. >In article <1992Aug18.080437.3944@fys.ruu.nl>, hooft@fys.ruu.nl (Rob Hooft) writes:
  14. >| In <NOP.92Aug17135014@theory.Mankato.MSUS.EDU> nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
  15. >| 
  16. >| >I'm not sure that all this trouble is worth it.  Does anyone have any
  17. >| >hard data on the performance loss of jump tables?
  18. >| 
  19.  
  20. >| I didn't believe this, so I repeated it many times. Is there any one
  21. >| who has an explanation for the fact that the '-jump'ed executable is
  22. >| 3% faster? Could this be caused by a difference in the crt0.o?
  23.  
  24. >  Have you timed this with the time command (I posted one about 2 weeks
  25. >ago to tsx and banjo, hope it's up by now on tsx at least)? I have a
  26. >thought that the jump may be effecting the ratio of user/sys time (no, I
  27. >don't know how) and that would show it. I believe the flops uses the
  28. >user CPU to calculate performance, not the total.
  29.  
  30. >  That would also show the realtime, which I would expect to go up.
  31.  
  32. Yes, that is what I expect too, but I didn't expect the usertime to go
  33. down at all, certainly not by over 0.5 seconds. We're talking a
  34. program here that runs for 25 hard CPU-seconds! I'll be timing again
  35. this evening, and might even retry the BYTE-bench this time. Twice,
  36. that is. I guess I'll be using jump-libs for the rest of my linux-life....
  37.  
  38. -- 
  39. Rob Hooft, Bijvoet Center for Biomolecular Research, 
  40. Chemistry department University of Utrecht, the Netherlands
  41. hooft@hutruu54.bitnet hooft@chem.ruu.nl hooft@fys.ruu.nl hooft@cc.ruu.nl
  42.