Re: faster random number engine
On 08/30/2012 06:37 PM, Benjamin De Kosnik wrote: Nice! Thanks. Here's a small patchlet to set the abi version to .18. With this, check-abi will pass. tested x86/linux Benjamin, is this still uncommitted? I'm seeing abi_check failing... Thanks, Paolo.
Re: faster random number engine
On 09/05/2012 11:53 AM, Paolo Carlini wrote: On 08/30/2012 06:37 PM, Benjamin De Kosnik wrote: Nice! Thanks. Here's a small patchlet to set the abi version to .18. With this, check-abi will pass. tested x86/linux Benjamin, is this still uncommitted? I'm seeing abi_check failing... Ok, now I see that the patch is in and a default configured build is fine abi-wise. Sorry about the false alarm. If you are curious, the reason why I sent the message is that adding --enable-libstdcxx-time=rt (which should be more or less the default in the C++11 era) used not to lead to abi_check failures and it does now. Should look more into it... Paolo.
Re: faster random number engine
Can this replace the current mersenne twister implementation in std:: once the endianness issue, etc, have been worked out? -miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen
Re: faster random number engine
On Fri, Aug 31, 2012 at 3:59 AM, Miles Bader mi...@gnu.org wrote: Can this replace the current mersenne twister implementation in std:: once the endianness issue, etc, have been worked out? No, it produces different numbers.
Re: faster random number engine
On Wed, 29 Aug 2012 14:34:40 -0400 Ulrich Drepper drep...@gmail.com wrote: On Wed, Aug 29, 2012 at 11:43 AM, Paolo Carlini paolo.carl...@oracle.com wro The substance isn't of course. But normally we don't have __gnu_cxx things in the same std header. Can't we have a new ext/random and put it in there? If we can separate the new code to it, I think people would not even object to the target dependency, etc. In ext/ we are quite free to do extension / experimental work. OK, I moved the definition to ext. Will check in the result. Nice! Thanks. Here's a small patchlet to set the abi version to .18. With this, check-abi will pass. tested x86/linux -benjamin2012-08-30 Benjamin Kosnik b...@redhat.com * testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.18. diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc b/libstdc++-v3/testsuite/util/testsuite_abi.cc index 4721ccd..a5066cc 100644 --- a/libstdc++-v3/testsuite/util/testsuite_abi.cc +++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc @@ -195,6 +195,7 @@ check_version(symbol test, bool added) known_versions.push_back(GLIBCXX_3.4.15); known_versions.push_back(GLIBCXX_3.4.16); known_versions.push_back(GLIBCXX_3.4.17); + known_versions.push_back(GLIBCXX_3.4.18); known_versions.push_back(GLIBCXX_LDBL_3.4); known_versions.push_back(GLIBCXX_LDBL_3.4.7); known_versions.push_back(GLIBCXX_LDBL_3.4.10); @@ -222,7 +223,7 @@ check_version(symbol test, bool added) test.version_status = symbol::incompatible; // Check that added symbols are added in the latest pre-release version. - bool latestp = (test.version_name == GLIBCXX_3.4.17 + bool latestp = (test.version_name == GLIBCXX_3.4.18 || test.version_name == CXXABI_1.3.6 || test.version_name == CXXABI_TM_1); if (added !latestp)
Re: faster random number engine
On 8/29/12 4:19 PM, Ulrich Drepper wrote: Therandom header so far contains the random number engines documented in the header. None of these are well suited for modern CPUs. There is a variant of the Mersenne twister engines which is explicitly designed to perform well on CPUs with SIMD instructions. The result is an engine with equal properties to the original Mersenne twisters but several times faster. Great. The attached patch implements this new engine. It's in the __gnu_cxx namespace. I added definitions for all the variants defined by the authors. The test suite checks the returned values based on results obtained from the original code. The SIMD optimization is so far done for x86. In all other cases a generic implementation is used. The generic implementation works correctly for little endian machines. For big endian machines someone will come up with fixes. Until then the new default.cc test is expected to fail. I hope this is an uncontroversial change. The substance isn't of course. But normally we don't have __gnu_cxx things in the same std header. Can't we have a new ext/random and put it in there? If we can separate the new code to it, I think people would not even object to the target dependency, etc. In ext/ we are quite free to do extension / experimental work. Paolo.
Re: faster random number engine
On Wed, Aug 29, 2012 at 11:43 AM, Paolo Carlini paolo.carl...@oracle.com wro The substance isn't of course. But normally we don't have __gnu_cxx things in the same std header. Can't we have a new ext/random and put it in there? If we can separate the new code to it, I think people would not even object to the target dependency, etc. In ext/ we are quite free to do extension / experimental work. OK, I moved the definition to ext. Will check in the result.
