Hi, > Do we want to keep the full device name in the profiles map? With > vendor and arch determined, we know pretty much everything we need > to know. If we need to match the name 1:1, there may be too many > devices which we miss even though the 'faster' profile should work? > > > Hmm, in the case where there is no clear match, ie GTX460 instead of > GTX470, it will fallback on the vendor-arch profile, so good performance > should be obtained. On my laptop, my Geforce GT540m grabs the Fermi > profile obtained through a GTX470, which gives good performance. On AMD, > the problem doesn't really exist, since the DEVICE_NAME returned by the > SDK is the codename. It is just much smarter. Ideally, we would want to > do the same thing for NVidia and also stop at the codename rather than > at the full device name, but it is tedious as it requires us to do a > manual 1-to-1 mapping with the NVidia Product List...
Okay, if the vendor-arch profile is a fast profile rather than a 'compatibility' profile, this should indeed be fine. > Oh, and btw: I don't think the profiles map is valgrind-clean... > > > Haha, I know. Well, this is a static std::map, so the pointers in there > will live until the end of the program, so using directly new or > shared_ptr should be equivalent since the destructor will not be called > until the end of the program, right? No, this is not correct. If you create an element on the stack, the unwinding of the stack destroys the element correctly. However, if you create an element on the heap via 'new', you also need to ensure that you call 'delete' on it, otherwise valgrind will reports lots of memory being lost. OSes with virtual memory the memory is still free'd up after the termination, but in principle such memory could be lost 'forever'. Best regards, Karli ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
