Přijde mi, že dotaz má nějaké problémy s formulací:
1) Proč je v názvu dvakrát „zápis“ když jde o kontrolu čtením?
2) Jak by mělo fungovat „Rád bych zvýšil šanci, že vyhledávané číslo bude v cache L1/L2.“ když jsi nám nesdělil nic o tom, jaké mají vstupní čísla statistické rozdělení? A proč chceš mít v cache vyhledávané číslo, když tě nezajímá to číslo, ale informace, jestli je v seznamu?
3) Teď jsem si všiml, že 64 B * 2 miliardy/s = 128GB/s. To ta čísla generuješ lokálně, nebo jak je získáváš? Vždyť to musí být strašný problém do toho počítače vůbec dostat, ne? Vždyť to je víc než propustnost PCIe na většině procesorů a něco jako quad channel DDR4!
Pokud by statistické rozdělení bylo třeba takové, že tam čísla jednou jsou a pak se mnohokrát opakují, tak by mohl pomoct splay strom, resp. nějaká jeho cache-aware varianta. (ale opakování je potřeba mnohokrát, protože to musí vyvážit vysplayování prvku, což je log(n) *zápisů* což bude příšerně drahé; hm asi na to zapomeň, tohle nebude fungovat; i obyčejná hashtable si přece bude držet posledně použité buckety v cache)
Z té délky 512b bych to tipoval na kryptografii a pak to asi bude plně náhodné a máš smůlu.
Tvrdíš, že máš cca. 7 milionů čísel. U Bloom filtru se většinou udává něco jako 1 bajt na položku. Takže pokud máš alespoň 8 MB cache, mohl by se ti tam filtr vejít celý.
Ale tady se bojím, že prosté odeslání datagramu UDP bude výpočetně náročnější než prohledání pole
No to samozřejmě, musíš jich agregovat víc do jednoho datagramu.
Btw. použij hugepages, protože jinak budeš mít v cache kolize.