cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

metrix
Journeyman III

Enhance performance of Ruby hash key lookup with HSA

Jump to solution

Ruby is known for having "slow" performance and I thought it would be interesting to see what HSA could do for Ruby hash lookups -- specifically in this function here: ruby/st.c at trunk · ruby/ruby · GitHub  as It's dealing with an array instead of pointers like the find_entry function further down. So my questions are:

1. Is this function as it stands something that could be optimized with HSA?

2. Which HSA technology do I need to research if this is a good spot to optimize - HSAIL? CLOC?

3. Any other ideas/suggestions?

Brandon

Tags (2)
0 Likes
1 Solution

Accepted Solutions
jedwards
Staff
Staff

Re: Enhance performance of Ruby hash key lookup with HSA

Jump to solution

Attempting to optimize this function with HSA, or any parallelization programming model would require significant changes to the structure of the hash table, and isn't a useful endeavor. Parallelization could be done on the comparison operation in the PTR_NOT_EQUAL macro, i.e. the calculation "(ptr) != 0 && ((ptr)->hash != (hash_val)", but because the table isn't a contiguous block of memory each entry must be traversed to find the next, making parallelization of the search impossible. Any parallelization optimization would require a redesign of the table data structure and how entries are stored.

View solution in original post

0 Likes
1 Reply
jedwards
Staff
Staff

Re: Enhance performance of Ruby hash key lookup with HSA

Jump to solution

Attempting to optimize this function with HSA, or any parallelization programming model would require significant changes to the structure of the hash table, and isn't a useful endeavor. Parallelization could be done on the comparison operation in the PTR_NOT_EQUAL macro, i.e. the calculation "(ptr) != 0 && ((ptr)->hash != (hash_val)", but because the table isn't a contiguous block of memory each entry must be traversed to find the next, making parallelization of the search impossible. Any parallelization optimization would require a redesign of the table data structure and how entries are stored.

View solution in original post

0 Likes