From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9c86eb13dd395066 X-Google-Attributes: gid103376,public From: Jim Balter Subject: Re: CRC in Ada? Date: 1997/03/12 Message-ID: <3326B63E.1EC1@netcom.com>#1/1 X-Deja-AN: 224932303 References: <1997Mar2.220652@nova.wright.edu> Organization: JQB Enterprises X-NETCOM-Date: Wed Mar 12 5:59:12 AM PST 1997 Newsgroups: comp.lang.ada Date: 1997-03-12T05:59:12-08:00 List-Id: Ole-Hjalmar Kristensen FOU.TD/DELAB wrote: > Actually, I don't think he claimed to have done the measurements > himself. No, he didn't, nor did I say that he did. I said that he had misread something I said to him as a claim by me that he had done these measurements. He then claimed that (which was his own misreading of something I said) showed that I couldn't follow a newsgroup thread. > But just some comments about doing invalid measurements and being > unable to interpret the results :-) > > I did the measurements mainly to show that the amount of work being > done by system calls was exactly the same in both cases, and that is > why the setvbuf call was made to ensure that the buffer size was the > same in both cases. I didn't particulary care about the code in the > inner loop being optimized away, because as you have said yourself, > as soon as you start doing something interesting with the char, the > difference is pretty unimportant. I only expressed a mild surprise > that not more of the getchar macro had been optimzed away as well. With getchar, the stdin ptr and cnt must be updated to accurately reflect the amount of data scanned, and many compilers will generate code that does the compare to EOF whether the char came from filbuf or from *ptr++, even though the latter isn't necessary. In the read() loop, the buffer need not be touched at all if the data isn't actually used. > Btw., I've re-run the program with a simple checksum computation in the > innner loop, and the ratio is now 4 to 1. Still a bit more difference > than I would have thought, but pipelining effects may have something > to do with it, as Dewar pointed out. The compiled code may well not be moving stdin._ptr and stdin._cnt into registers. You would have to carefully evaluate the actual compiled code for both the getchar and read() cases to determine the precise overhead for getchar. It may even get down to zero (within the loop; there would still be constant overhead) with certain compilers and processors. Of course, it won't get down below zero, unless the read() loop is really badly coded. But it is easy to write read() loops that mishandle some cases, such as a search for a two-character sequence that straddles a buffer boundary, so loose talk about "mistakes" should be avoided. My own measurements gave a getchar cost of 100 nanoseconds per byte on a Pentium 166, rather a small fraction of the total cost, but I didn't run a lot of cases or examine the generated code to be sure I wasn't seeing some artifact, so my experience leads me not to jump to conclusions about such numbers. And of course all these measurements are *CPU* time, not elapsed time, and totally exclude physical I/O time. --