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
Every operator need to call Findvar directly or indirectly.
As C++ default hash<std::string> implementation uses "murmurhash", which is the fastest hash function, it may still slower than directly lookup a variable using an offset. We can consider a way to make runtime Findvar implementation do not use unordered_map.
The text was updated successfully, but these errors were encountered:
Thanks for the issue!
Maybe the hash table lookup cost is marginal, comparing to the time it take for running GPU kernels? I think we need to have some profiling numbers to back this up.
@typhoonzero Any follow-ups on this issue? The hash lookup usually takes 200ns. The gap between Op.Run() is usually 500,000 ~ 1,000,000 ns. I doubt the loop up time is the issue.
One month ago, I had discussed this issue with @typhoonzero, we thought that it will not degrade the performance magnitude. Because 200ns means 200 * 10-12, it is really small.
But to give a solid conclusion, now I'm doing an experiment on this changing the unordered_map to index based vector, will report the result later.
Here's some reference I've searched:
https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed
Every operator need to call
Findvar
directly or indirectly.As C++ default
hash<std::string>
implementation uses "murmurhash", which is the fastest hash function, it may still slower than directly lookup a variable using an offset. We can consider a way to make runtimeFindvar
implementation do not useunordered_map
.The text was updated successfully, but these errors were encountered: