It sounds to me like such a thing would need to employ archetecture specific techniques such as compiler intrinsics and inline-assembly to be in any way competitive in terms of performance with what probably exists in closed source development shops. Also, these things are best offloaded to the GPU if possible, and that code isn't written in C++. simd intrinsic is actually enough but last time I proposed something on
I've been using Boost.Thread to implement an asynchronous task execution service, and when I run Valgrind I come across a fair number of reported memory leaks. Most of them are obviously my fault (there are some worker threads not being properly destroyed), but there are a few that I'm not clear from the stack trace whether or not they are under my control. Are there any known memory leaks in Boost.Thread? The only thing that I've identified as a definite leak is in boost::this_thread::disable_interruption - it leaks 8 bytes from a TLS variable whenever it is constructed and destroyed by a non-Boost thread (at least on Linux.) This is obviously irrelevant for practical purposes, but I'm not sure if it's a good idea for something intended to implement a proposed C++ standard library to have known memory leaks. Thanks, Gregory Peele, Jr. Applied Research Associates, Inc. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel Falcou Sent: Thursday, March 26, 2009 12:00 PM To: boost@lists.boost.org Subject: Re: [boost] [gsoc] Interest check for 3d geometry proposal Simonson, Lucanus J a écrit : those lines, it was dismissed as useless .... Gpu are limited by the speed of the bus and you'll end up spending too much time sending data back and forth. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost