I submit that sparse switch jump table's are not an "unusual" construct in the Linux kernel/drivers. GCC only creates a table large enough to cover the largest of the sparse values - it doesn't have to be 0...255. 0...60 with 10 values sparsely scattered would generate a 61 element jump table.
There's many K of locked memory in these sparse jump tables. About 2K worth in the VT102 code alone. ----- Original Message ----- From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Adrian Bunk" <[EMAIL PROTECTED]>; <linux-kernel@vger.kernel.org> Sent: Saturday, July 23, 2005 15:50 Subject: Re: kernel optimization > On Sad, 2005-07-23 at 02:30 -0400, [EMAIL PROTECTED] wrote: > > Larger does not always mean slower. If it did, nobody would implement a > > loop unrolling optimization. > > Generally speaking nowdays it does. Almost all loop unrolls are a loss > on PIV. > > > ex. Look at how GCC generates jump tables for switch() when there's about > > 10-12 (or more) case's sparsely scattered in the rage from 0 through 255. > > You are comparing with very expensive jump operations its an unusual > case. For the majority of situations the TLB/cache overhead of misses > vastly outweighs the odd clock cycle gained by verbose output. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
