This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients christian.heimes, rhettinger, serhiy.storchaka, vstinner
Date 2013-08-18.01:49:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376790598.58.0.760924111518.issue18771@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a simple benchmark to start with.

On my machine (2.4Ghz Core2 Duo with 2MB L3 cache) and compiled with GCC-4.8, the benchmark shows a 6% speedup for sets that spill over L2 cache and 11% for sets that spill over the L3 cache.

The theoretically expected result is 9.75%:

   26% collision rate (for tables that are 64% full)
 x 75% chance of adjacent entry in same cache line
 x 50% savings (two lookups for the price of one)
 -----
 9.75%
 =====

Most programs will have less benefit (they may smaller tables that fit in L1 cache or have tables that are less densely filled resulting in fewer collisions).  My quick timings show either no change or inconsequential improvement in the performance of those programs.
History
Date User Action Args
2013-08-18 01:49:58rhettingersetrecipients: + rhettinger, vstinner, christian.heimes, serhiy.storchaka
2013-08-18 01:49:58rhettingersetmessageid: <1376790598.58.0.760924111518.issue18771@psf.upfronthosting.co.za>
2013-08-18 01:49:58rhettingerlinkissue18771 messages
2013-08-18 01:49:58rhettingercreate