From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752025AbcBEIBn (ORCPT ); Fri, 5 Feb 2016 03:01:43 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35689 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbcBEIBk (ORCPT ); Fri, 5 Feb 2016 03:01:40 -0500 Date: Fri, 5 Feb 2016 09:01:36 +0100 From: Ingo Molnar To: Tom Herbert Cc: Linus Torvalds , David Miller , Network Development , Thomas Gleixner , Ingo Molnar , Peter Anvin , the arch/x86 maintainers , kernel-team , Linux Kernel Mailing List , Peter Zijlstra Subject: Re: [PATCH v3 net-next] net: Implement fast csum_partial for x86_64 Message-ID: <20160205080136.GA31671@gmail.com> References: <1454527121-4007853-1-git-send-email-tom@herbertland.com> <20160204093021.GB1553@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Tom Herbert wrote: > [....] gcc turns these switch statements into jump tables (not function tables > which is what Ingo's example code was using). [...] So to the extent this still matters, on most x86 microarchitectures that count, jump tables and function call tables (i.e. virtual functions that C++ uses) are generally optimized by the same branch predictor hardware mechanism. Indirect jumps (jump tables) and indirect calls (function pointer tables) are very similar conceptually. That is why posted the indirect calls test code. ( The only branching variant that will perform badly even on the latest uarchs are indirect returns: to modify the return address on the stack. ) So my narrow performance point stands, if any sort of indirect jump is used. They should be avoided if possible, because it's pretty hard for the hardware to get it right. As Linus noticed, data lookup tables are the intelligent solution: if you manage to offload the logic into arithmetics and not affect the control flow then that's a big win. The inherent branching will be hidden by executing on massively parallel arithmetics units which effectively execute everything fed to them in a single cycle. In any case, when submitting such patches, please get into the habit of looking at and posting perf stat output - it will give us a good idea about the quality of an implementation. Thanks, Ingo