[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B6E58@saturn3.aculab.com>
Date: Mon, 6 Feb 2012 11:26:37 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Larry Finger" <Larry.Finger@...inger.net>,
"Jan Ceuleers" <jan.ceuleers@...puter.org>
Cc: "Devendra.Naga" <devendra.aaru@...il.com>,
<chaoming_li@...lsil.com.cn>, <linville@...driver.com>,
<paul.gortmaker@...driver.com>, <joe@...ches.com>,
<linux-wireless@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] wireless: move ifs' in _rtl92c_store_pwrIndex_diffrate_offset into elseif statements
> Yes, it is correct. It might be clearer if it were written as
> a switch statement, but that would be a lot more intrusive.
> Besides, have you ever looked at the way gcc compiles a switch?
How gcc compiles a switch statement depends (amongst other
things) on whether the labels form a 'dense set' or not.
If they are dense it will usually generate a jump table.
If they are not dense it will compare against the 'middle'
entry first and generate a tree of conditionals.
An 'else if' chain is a linear search.
If the performance of the code matters in can be worth
an explicit test for the common case outside the switch.
Alternatively an 'if else' chain with every conditional
marked 'unlikely' should generate exactly one mispredicted
branch (if you can force static branch prediction).
There are further constraints that apply to some cpus.
Mostly it isn't worth worrying about - although a lot of
code can be significantly sped up by avoiding/containing
register spills and mis-predicted branches.
The code is question seemed to be checking bits, not
an ordinal - so changing to a case might be problematic.
(Could more than one bit bet set????)
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists