Announcement

Collapse
No announcement yet.

std::unordered_map vs TMap Performance?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    std::unordered_map vs TMap Performance?

    I have some code that uses std::unordered_map. I'm considering rewriting it to use TMap.

    I am wondering if anyone has done any comparisons between the performance of TMap and std::unordered_map. From my understanding, the std::unordered_map is slow because it uses a nasty linked list for buckets. So, rather cache unfriendly with stuff everywhere in RAM.

    TMap uses a contiguous block of memory, so it should be more cache friendly. So, it should be fast, but how fast I wonder?

    Maybe I'll do my own benchmarks if no one else has any measurements. Google also has a crazy fast "swiss tables" hash map optimized for the CPU cache and SIMD.

    #2
    Question is why do you want to use stl at all?!
    Don't you want your project to support multiple platforms?
    | Finite State Machine | Auto-Save Plugin | USQLite Plugin | Object-Pool | Sound-Occlusion | Property Transfer Tool | Magic Nodes | Magic Nodes | Persistent Materials |

    Comment


      #3
      I'm sorry if I wasn't clear, I have a code base with stl in it. It was not written for Unreal.

      I'm considering rewriting some of it to use TMap.

      Mostly out of curiosity only, I'm wondering if anyone has ever bothered benchmarking TMap against std::unordered_map.

      Comment


        #4
        Originally posted by BrUnO XaVIeR View Post
        Question is why do you want to use stl at all?!
        Don't you want your project to support multiple platforms?
        This might be a tangent, but why would STL prevent cross-platform development? STL is literally the standard guaranteed to exist in all (compliant) C++ compilers.. I get that you can't expect the the same STL performance on all platforms, though..

        More on-topic, though: Are you sure that unordered_map performance is actually an issue at all for you?

        If you do measurements, please share them though, I would also be interested..

        Comment


          #5
          The bigger issue IMO is that STL isn't going to work with UE's reflection system or the Garbage Collector.

          So if you have something like:

          Code:
          stl::unordered_map<FString, AActor*> NameToActorMap;
          You aren't able to mark that field as a UPROPERTY and any references to the AActors contained within the map will never be tracked and may be deleted if no one else has a reference to that actor.
          Able Ability System - A high performance, robust ability system for UE4. Now Available!

          Comment


            #6
            Originally posted by TheHugeManatee View Post
            This might be a tangent, but why would STL prevent cross-platform development? STL is literally the standard guaranteed to exist in all (compliant) C++ compilers.. I get that you can't expect the the same STL performance on all platforms, though..
            That in theory; In practice that's not what happens.
            | Finite State Machine | Auto-Save Plugin | USQLite Plugin | Object-Pool | Sound-Occlusion | Property Transfer Tool | Magic Nodes | Magic Nodes | Persistent Materials |

            Comment


              #7
              Originally posted by BrUnO XaVIeR View Post

              That in theory; In practice that's not what happens.
              Could you please point me to some other references and discussions about modern STL in games? STL is slowly getting more love now, so I am starting to be interested in it too. Would love to see some actual comparisons or issues besides its containers.
              Last edited by Skylonxe; 05-09-2019, 04:44 PM.

              Comment


                #8
                Maybe things have changed, but the reason why pretty much every C++ engine implement their own containers is because people got bitten in the past by using STL. The interface might be the same, but there's no guarantee about the underlying implementation (specially when it comes to performance).

                Comment


                  #9
                  Originally posted by Manoel.Neto View Post
                  Maybe things have changed, but the reason why pretty much every C++ engine implement their own containers is because people got bitten in the past by using STL. The interface might be the same, but there's no guarantee about the underlying implementation (specially when it comes to performance).
                  I see, that makes sense. I just found EA STL which can be interesting for someone who 'really' wants to have STL like code. Here is the link for anybody interested: https://github.com/electronicarts/EASTL

                  Comment


                    #10
                    This guy talk a little bit about the issues, but he doesn't really go deep to the matter..

                    https://youtu.be/qYN6eduU06s



                    And a few tests here (but not involving any Unreal types)
                    http://in2gpu.com/2015/03/09/iterati...st-and-vector/
                    | Finite State Machine | Auto-Save Plugin | USQLite Plugin | Object-Pool | Sound-Occlusion | Property Transfer Tool | Magic Nodes | Magic Nodes | Persistent Materials |

                    Comment

                    Working...
                    X