From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BE3281A1E59 for ; Thu, 1 Sep 2016 15:36:56 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p186so102724395oia.2 for ; Thu, 01 Sep 2016 15:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qL2AWr6wm2RO4NJrmQul0G9XkHW5rbYawr6RXDr5K8U=; b=gFFSx6BLOj+BeR+cB78Sj+Wttl3O2UmJjoJ7L9RHc6Z3xxf2k7KjVauGx1apyM/wBf sYJ6u1LN4/kiLlkJoV4AFOc5Jzth6GmI9AGSi9fLqhy3rfVXmUa+NwrxcGozyY/YOGwh KO1d+X2OsJquoN50XvHEkA50SmslhlDCCSUTqChdClW5H74cHrMSCiBDWOeZR5//Hoc+ oHKsNy7VETjucqzHo+LTwLqBI7TlWvea/DzBxQUVo7PuzJ2/Y8D43Dnj2aPfNNpTNNXt ylOJ3qHUbywbg/PIitL99h8NjN1vx3MSUxnuPpDa+7vlHHq+NUOrUidpwSy3Z8GECKTJ H2/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qL2AWr6wm2RO4NJrmQul0G9XkHW5rbYawr6RXDr5K8U=; b=QgcWDG7ujSDzLOg5iuu9O/5s9eY5Rhvo8xbfX+mw5XPMmyiWr9kHcYka8FCQG+WCJE 4U2CeAzfhEXnRxrPmq0cAjpZmvNI988lS3DoG2FZTfmGAI8T4R7QOFz9vyI+VFOsCmEm 6ZwYnMQptLCCEcFo8mWeC3R6Wz2N9YcFi8lSOcl5KykwG+zgtI4zirl+Gyk73XIjhBRA TMH+jI3fNlAcfDuxMdQEa7hGY4dkhLTe2wiZCeCtwpdpnSB5aq0dWwaT2bqIkmgQHCRa U2xw0V93gel13fSssKQVbP3yrmmQRLnyyM3SwmhwFX+llQfnLLAH8SAreHJm6G1TBD6s 1j4Q== X-Gm-Message-State: AE9vXwPQL3Zk1/Bk9yVCoaEcfMXgTbeDxBO/Ntinlp463/ohqkqWCAOY2uG/atmLPWdU8qolLEbynz95FdqpZw== X-Received: by 10.202.231.20 with SMTP id e20mr16004915oih.61.1472769415867; Thu, 01 Sep 2016 15:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.50.86 with HTTP; Thu, 1 Sep 2016 15:36:55 -0700 (PDT) In-Reply-To: References: <91B24DF7-4F53-4DEF-A600-755A69368B79@apple.com> From: valerij zaporogeci Date: Fri, 2 Sep 2016 01:36:55 +0300 Message-ID: To: edk2-devel Subject: Re: Crc32 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 22:36:57 -0000 Content-Type: text/plain; charset=UTF-8 Please read this, don't discard hastily, it might be intesting for the project. I have a suggestion about the implementation of Crc32 found in this place: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/RuntimeDxe/Crc32.c Figuring out why proper mathematical crc calculation differs from results returned by this function, I found it's because the function reverts bits in bytes. It's all clear, this is a need rooting from some hardware protocol requirements and specifics (ethernet?), where it was needed and here it is repeated as it became a de facto standard. But looking at the implementation, I found that it is possible to get THE SAME results with much less processing. Namely, instead of reverting every byte in the sequnece (moreover, please note, that the implementation in fact casts every byte to UINT32 and only then reverts it - yet 4 times more of a wasting job), so, instead of reverting every byte of the entire message (which might be of any size), we might statically revert bits ONLY in the Polynomial representation itself. And that's all! It's absolutely identical mathematically. It returns identical results on every input. But it is a significant performance improvement. The interface and semantics would not change, they remain the same for any caller. Internal ReverseBits() function is not needed any more and doesn't get called anywhere. The implementation remains the same table driven, but the table initializes now MUCH more faster (without reverting). If you have interest in this suggestion, I have prepared (and tested) the changed file in question, and might send it if there would be interest. Thank you. PS. It is NOT changing a polynomial. It's improvement of the internal implementation which takes into account (strange) treatment of bit ordering of this particular case.