Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: standard error codes Date: Tue, 10 Jan 2017 12:02:24 -0800 Organization: None to speak of Lines: 44 Message-ID: References: <96e16709-18eb-4399-86c4-a6f30a767df3@googlegroups.com> <212f08fd-b09e-4848-8485-f7480eaaae45@googlegroups.com> <86260b21-0fa2-42b4-93c6-08e9241d4c17@googlegroups.com> <64011b84-2f8d-44f2-902a-0eacfcdf630b@googlegroups.com> <11823fb6-613e-4283-95e8-dd930e152418@googlegroups.com> <546841f1-b478-44dc-abc0-22ca4f46e553@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="051d99dd7a883013689f38e075ee6474"; logging-data="22461"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UzN0ZtWf90lGMU0C0A6rv" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:RGByUrCFxj45mcBBqDINmyjouRY= sha1:cFVfNbXp8iRs2Oz63CTmmVMO3Ss= Xref: csiph.com comp.lang.c:101396 supercat@casperkitty.com writes: > On Tuesday, January 10, 2017 at 11:07:07 AM UTC-6, Keith Thompson wrote: >> An experiment I did the other day shows that, at least for some >> implementations, memcmp() returns the difference between the first >> corresponding bytes that differ. Would returning a zero/nonzero >> result be faster than returning the result of a subtraction? >> (I don't know the answer, and it could vary from one CPU to another.) > > On many architectures, a memory-compare function which is optimized for the > case where blocks will have a long common prefix (or match entirely) will be > able to compare multiple bytes at once. If code is only comparing one byte > at a time, returning the result of the comparison will be essentially "free", > but code that compares one byte at a time will on many platforms be much > slower than code which compares multiple bytes. I didn't say the code compares one byte at a time. I haven't looked at the source, so I don't know whether it does or not, but I suspect it's well optimized for aligned buffers. Whether it compares bytes or words, it has to return a result, and it's going to have to be able to do some extra work if there's a partial word at the end. (Comparing two aligned 1023-byte buffers, it might do 127 8-byte word comparisons and then deal with the final 7 bytes in more detail.) The question remains, is it significantly more efficient to return a zero/nonzero result than a negative/zero/positive result? A *meaningful* answer to that question would require actual measurements, on actual hardware, using an actual proposed implementation of memeq() and/or streq(). That's more work than I'm willing to do at the moment, so I personally will be satisified with an answer of "I don't know". But I suggest that *someone* would have to do that work as a prerequisite to seriously considering adding memeq() and/or streq() to the standard. If it would significantly improve performance, I'm all for it. But the fact that no such functions exist on my system suggests (but does not prove) that the performance improvement is not worthwhile. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"