Added to Tuesday agenda On 12 December 2015 at 22:18, HePeng <xnhp0...@icloud.com> wrote:
> Ping. > > So what is your decision on this. > > 在 2015年12月10日，下午1:06，HePeng <xnhp0...@icloud.com> 写道： > > > 在 2015年12月9日，下午6:49，Ola Liljedahl <ola.liljed...@linaro.org> 写道： > > On 9 December 2015 at 06:31, HePeng <xnhp0...@icloud.com> wrote: > >> >> 在 2015年12月8日，下午9:34，Ola Liljedahl <ola.liljed...@linaro.org> 写道： >> >> On 8 December 2015 at 12:42, Bill Fischofer <bill.fischo...@linaro.org> >> wrote: >> >>> This is an interesting topic. I'd like to discuss this a bit during >>> today's ODP public call. >>> >>> I think the issue is that while a ring is a very useful implementation >>> construct its semantics are very SW centric. >>> >> But isn't the use case here SW centric? >> >> >>> Perhaps there's opportunity here for a new Queue type that would permit >>> an implementation to implement the queue API as a ring for additional >>> performance? >>> >> I think it is a bad idea to overload the ODP queue with another type of >> usage and implied implementation. Better to define a new ODP object. >> >> What are the real requirements of the "ring" as used by the cuckoo hash >> design? Enqueue/dequeue operations. Fixed size is OK? Storing arbitrary >> objects (not just ODP events)? >> >> >> The real requirement is use the ring as a sort of container. >> Fixed Size is OK. And the ring should be used to >> store any ODP events, since it is used as a container, >> like vector in C++ STL. >> > What if I would like to store objects that are not ODP events in the > cuckoo hash table? E.g. arbitrary pointers (to memory that is managed in > some other way). > > Yes, that is currently ring’s implementation. > > > >> >> >> >> >>> The scheduler itself could use this since its use of queues is subject >>> to the same issues. >>> >>> On Mon, Dec 7, 2015 at 11:39 PM, HePeng <xnhp0...@icloud.com> wrote: >>> >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
