netdev - Re: [PATCH] HTB O(1) class lookup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	01 Feb 2007 12:30:47 +0100
From:	Andi Kleen <ak@...e.de>
To:	Simon Lodal <simonl@...knet.dk>
Cc:	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	lartc@...lman.ds9a.nl
Subject: Re: [PATCH] HTB O(1) class lookup

Simon Lodal <simonl@...knet.dk> writes:
> 
> Memory is generally not an issue, but CPU is, and you can not beat the CPU 
> efficiency of plain array lookup (always faster, and constant time).

Actually that's not true when the array doesn't fit in cache.

The cost of going out to memory over caches is so large (factor 100 and more) 
that often algorithms with smaller cache footprint can easily beat
algorithms that execute much less instructions if it has less cache misses. 
That is because not all instructions have the same cost; anything
in core is very fast but going out to memory is very slow.

That said I think I agree with your analysis that a two level
array is probably the right data structure for this and likely
not less cache efficient than the hash table.

And the worst memory consumption case considered by Patrick should
be relatively unlikely.

-Andi
-
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