search for: unordered_map

In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use <unordered_map> if it is available, or <tr1/unordered_map> if not, or <map> if all else fails. I (think I) can accomplish this with configure.ac as AC_INIT("DESCRIPTION") CXX=`"${R_HOME}/bin/R" CMD config CXX` CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS` AC_CO...

Hi, Consider below test case: 1 #include <unordered_map> 2 3 using key=const int; 4 struct Myhash { 5 Myhash() = default; 6 std::hash<int> hash_int_t; 7 inline size_t operator()(const key& x) const throw() { 8 return hash_int_t(x); 9 } 10 };...

...enabled. We'll have to update the tests so that they are aware of the no-exceptions build as well. I have a work-in-progress patch for this, I will put it up for review separately once I'm done with it. Note that it's not just the tests that need to be updated. For example, take unordered_map::at(key) definition: template <class _Key, class _Tp, class _Hash, class _Pred, class _Alloc> _Tp& unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::at(const key_type& __k) { iterator __i = find(__k); #ifndef _LIBCPP_NO_EXCEPTIONS if (__i == end()) throw...

...me. > Here's an update. After http://reviews.llvm.org/D8372 , I updated the profiling data. https://people.freebsd.org/~davide/llvm/lld-03162015.svg It seems now 85% of CPU time is spent inside FileArchive::buildTableOfContents(). In particular, 35% of the samples are spent inserting into unordered_map, so there's maybe something we can do differently there (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare

....llvm.org/D8372 , I updated the profiling data. >> >> https://people.freebsd.org/~davide/llvm/lld-03162015.svg >> It seems now 85% of CPU time is spent inside >> FileArchive::buildTableOfContents(). >> In particular, 35% of the samples are spent inserting into >> unordered_map, so there's maybe something we can do differently there >> (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). > > > Anyone tried a DenseMap instead of an unordered_map? If you need pointer > validity to the elements, a DenseMap with unique_ptrs rather t...

On 1/19/2013 8:36 PM, Chris Lattner wrote: > > See: > http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task Were the "small n" characteristics the main motivation? Memory-wise, STL classes allow user-defined allocators, so use of things like memory pools should be relatively straightforward. Just wondering... :) -Krzysztof -- Qualcomm

On Jan 19, 2013, at 6:00 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 7:55 PM, Sean Silva wrote: >> >> Although SmallString is actually pretty inefficient, since it keeps >> the string data separate from the "vector" header. I believe libc++'s >> std::string actually reuses the pointers in the "vector header"

Hi, Libc++ has been shipping the <ext/hash_set>, <ext/hash_map> and <ext/__hash> headers for a while and they are deprecated. Those headers contain data structures like __gnu_cxx::hash_map that have replacements like std::unordered_map. I would like to remove those headers. I've put up a patch for review but I won't commit it until we have a sort of plan because I know some people have expressed feelings about removing the headers in the past: https://reviews.llvm.org/D57688 <https://reviews.llvm.org/D57688>. FWIW,...

...org/D8372 , I updated the profiling data. > > > > https://people.freebsd.org/~davide/llvm/lld-03162015.svg > > It seems now 85% of CPU time is spent inside > > FileArchive::buildTableOfContents(). > > In particular, 35% of the samples are spent inserting into > > unordered_map, so there's maybe something we can do differently there > > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). > > > > Why do we even need to build the table from name to member? > > Can't we just walk "archive->symbols()" and che...

...iterator> > > 2 #include <limits> > > 2 #include <memory> > > 4 #include <mutex> > > 1 #include <system_error> > > 1 #include <thread> > > 2 #include <tuple> > > 1 #include <unordered_map> > > 1 #include <unordered_set> > > 3 #include <utility> > > I think the biggest part is containers, and they are mostly in > ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > Yes, buffer_queue can definitely live without using system_error,...

...more than growing, for example, a vector. I talked about this with a few people and here are some possibilities we’ve come up with to improve this (some of which probably aren’t what we want): 1. Use a map that doesn’t require rehashing and reinsertion to grow. Chaining lets you do this, but std::unordered_map is probably so much slower than DenseMap we’d lose more than we gain. 2. Include the hash code in the map so that we don’t have to rehash. 32 bits more per entry (or whatever), and it might not help that much, since we still have to do the whole reinsertion routine. 3. Pre-calculate an estimate as...

...eque> > 2 #include <iterator> > 2 #include <limits> > 2 #include <memory> > 4 #include <mutex> > 1 #include <system_error> > 1 #include <thread> > 2 #include <tuple> > 1 #include <unordered_map> > 1 #include <unordered_set> > 3 #include <utility> > I think the biggest part is containers, and they are mostly > in ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > dependencies without buffer queue and fdr logging: > ...compiler-rt/lib/xray %...

...ge distance between document and centroid is lesser than that of KMeans mostly (around 0.55-0.7). Thus, in many cases, the clusters end up being more compact. I'm continuing to optimize this solution in time before I can go ahead with PSO. With respect to optimization, I'm currently using unordered_map where ever I'm requiring to map values. It certainly works faster than the std::map but there are various hashmap implementations that can work faster. Google dense hash map is one of those and they work way faster than unordered_map (to my knowledge). I thought of using them to speed value loo...

...iterator> > > 2 #include <limits> > > 2 #include <memory> > > 4 #include <mutex> > > 1 #include <system_error> > > 1 #include <thread> > > 2 #include <tuple> > > 1 #include <unordered_map> > > 1 #include <unordered_set> > > 3 #include <utility> > > I think the biggest part is containers, and they are mostly in > ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > Yes, buffer_queue can definitely live without using system_error,...

...growing, for example, a vector. I talked about this with a few people and here are some possibilities we’ve come up with to improve this (some of which probably aren’t what we want): > > 1. Use a map that doesn’t require rehashing and reinsertion to grow. Chaining lets you do this, but std::unordered_map is probably so much slower than DenseMap we’d lose more than we gain. > 2. Include the hash code in the map so that we don’t have to rehash. 32 bits more per entry (or whatever), and it might not help that much, since we still have to do the whole reinsertion routine. > 3. Pre-calculate an es...

On Sat, Dec 16, 2017 at 10:11:40PM +0000, Olly Betts wrote: > Unfortunately the sort key isn't currently exposed via the public API. > It's available internally and it seems like it ought to be accessible > but there's no accessor method for it - I can add one but that won't > help for existing releases. I've added MSetIterator::get_sort_key() to master in

Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id = M->getModuleIdentifier(); auto iter = CachedObjs.find(id); if (iter == CachedObjs.end()) { auto buf = llvm::MemoryBuf...

..., for example, a vector. I talked about this with a few people and here are some possibilities we’ve come up with to improve this (some of which probably aren’t what we want): >> >> 1. Use a map that doesn’t require rehashing and reinsertion to grow. Chaining lets you do this, but std::unordered_map is probably so much slower than DenseMap we’d lose more than we gain. >> 2. Include the hash code in the map so that we don’t have to rehash. 32 bits more per entry (or whatever), and it might not help that much, since we still have to do the whole reinsertion routine. >> 3. Pre-calcula...

...llocator at D@std@@@234@@http at beast@1 at AEAUsend_lambda@server_session@@PEBD3 at Z))​ ​ lld-link: error: undefined symbol: "public: class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> __cdecl jinja2::Template::RenderAsString(class std::unordered_map<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>, class jinja2::Value, struct std::hash<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>>, struct std::equal_to<class std::...

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler