Hi Maxim, 
        I implement a new version of cuckoo hash based on the ODP buffer/pool. 

        As I’ve mentioned earlier, the use of ring in cuckoo hash is like to 
the use of 
a container, e.g. a queue in C++ STL.  In current ODP implementation, I found 
that 
the ODP queue is implemented more likely a facility for transmitting objects, 
not 
a container to store objects. Look at the ODP queue enqueue interface:

        int odp_queue_enq(odp_queue_t queue, odp_event_t ev);

the *odp_event_t* is related to the events, but I only want to use odp_queue to 
storing and retrieving objects, any objects. 


        So I use ODP buffer/pool interfaces instead of ODP queue 
for the new cuckoo hash implementation. 

        However, compared to the previous implementation based on ring, this 
version 
suffers a serious performance degradation. The evaluation is carried out on a 
Intel 
servers. I test lookup time for 1000 lookups on a table storing 1 million 
items. 
The ODP buffer/pool version suffers at least a 2x performance degradation. 

This is the buffer/pool version, for 1M insert, and 1000 lookup time:

Average insert time = 2.383836, lookup time = 0.000353,

This is the ring version. 

Average insert time = 1.629115, lookup time = 0.000098

        This performance degradation stems from the heavy implementation of
 ODP buffer/pool. In the ring based one, all the key is stored in a big array, 
and 
the ring only stores the array indexes of each key. Keys are retrieved using 
array indexes. 
In the new one, I use ODP buffer to store the key content. Keys are retrieved 
by 
dereferencing a *odp_buffer_t*  handle. 

        With this high performance degradation, I suggest moving ring into the 
odp/api 
as a container implementation, and use the previous implementation of cuckoo 
hash. 





        
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to