You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I tried to use the ConcurentMap with key as 32bit int and the value as 64 bit int. I test it and there is error saying "misaligned address". I guess the design is just specific to 32 bit key/value, since I noticed the comment line in slab_hash_global.cuh.
I am curious that is there any easy workaround to change the code so that I can use the value type of 64 bit int.
The text was updated successfully, but these errors were encountered:
Yes, the current code for ConcurrentMap only works with 32-bit key and 32-bit values. The reason is that we ensure full concurrency of the data structure by using the available 64-bit atomic compare-and-swap operation. If such data layout is desire, it should be implemented through a less efficient software alternative of compare-and-swap operation (through locking and spinning). This is not going to be a quick code replacement, and it should be done with cautious to make sure everything works correctly.
The other alternative, which we have experimented, is to relax the full concurrency assumption so that updates and searches do not happen concurrently, then it is possible to support keys up to 64-bit and values up to any size. Also, it is customary to use keys and 64-bit pointers to deal with larger satellite data. Hopefully, I will add our experiments to this repo soon.
Hi, I tried to use the ConcurentMap with key as 32bit int and the value as 64 bit int. I test it and there is error saying "misaligned address". I guess the design is just specific to 32 bit key/value, since I noticed the comment line in slab_hash_global.cuh.
I am curious that is there any easy workaround to change the code so that I can use the value type of 64 bit int.
The text was updated successfully, but these errors were encountered: