The actual memory footprint of static_map is larger than my estimation #650

Gibyeng · 2024-12-04T07:18:36Z

Gibyeng
Dec 4, 2024

Hi, I find the memory footprint of cuco::static_map is significantly larger than its theoretical size (capacity* (sizeof(KEY) + sizeof(VALUE))). For instance, I set up a static_map and its theoretical memory footprint is 4.65G. However, it actually consumes 6.20G GPU memory. Why is that?

Answered by PointKernel

Dec 4, 2024

The alignment of your key and payload types can be one factor, while another is that cuco hash tables ensure the requested capacity serves as a lower bound. They select the smallest prime number greater than the requested capacity as the actual capacity. see

cuCollections/include/cuco/extent.cuh

Lines 95 to 99 in 93d6172

      * @note The actual capacity of a container (map/set) should be exclusively determined by the return  
    * value of this utility since the output depends on the requested low-bound size, the probing  
    * scheme, and the storage. This utility is used internally during container constructions while for  
    * container ref constructions, it would be users'…

View full answer

Gibyeng · 2024-12-04T07:51:23Z

Gibyeng
Dec 4, 2024
Author

After a few tests, I find the real reason is memory alignment issue.

1 reply

PointKernel Dec 4, 2024
Maintainer

The alignment of your key and payload types can be one factor, while another is that cuco hash tables ensure the requested capacity serves as a lower bound. They select the smallest prime number greater than the requested capacity as the actual capacity. see

cuCollections/include/cuco/extent.cuh

Lines 95 to 99 in 93d6172

    
            * @note The actual capacity of a container (map/set) should be exclusively determined by the return 
        
            * value of this utility since the output depends on the requested low-bound size, the probing 
        
            * scheme, and the storage. This utility is used internally during container constructions while for 
        
            * container ref constructions, it would be users' responsibility to use this function to determine 
        
            * the input size of the ref.

Answer selected by Gibyeng

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The actual memory footprint of static_map is larger than my estimation #650

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 1 reply

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!

	* @note The actual capacity of a container (map/set) should be exclusively determined by the return
	* value of this utility since the output depends on the requested low-bound size, the probing
	* scheme, and the storage. This utility is used internally during container constructions while for
	* container ref constructions, it would be users'…

The actual memory footprint of static_map is larger than my estimation #650

Gibyeng Dec 4, 2024

Replies: 1 comment · 1 reply

Gibyeng Dec 4, 2024 Author

PointKernel Dec 4, 2024 Maintainer

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!

Gibyeng
Dec 4, 2024

Replies: 1 comment 1 reply

Gibyeng
Dec 4, 2024
Author

PointKernel Dec 4, 2024
Maintainer