tag:blogger.com,1999:blog-684443317148892945.post363110363190203469..comments2024-02-29T23:54:39.092-08:00Comments on RDKit: A question: RDKit performance on Windowsgreg landrumhttp://www.blogger.com/profile/10263150365422242369noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-684443317148892945.post-20533173563304773242016-10-12T21:42:29.345-07:002016-10-12T21:42:29.345-07:00You mentioned bash in your comment. Are you using ...You mentioned bash in your comment. Are you using bash or other *X-originated procedures and practices in the run-time stack? Process creation is *extremely* slow on Windows (or at least used to be not so long ago), and you'd be amazed how many processes deep some of these trees are when compiling from Makefiles or from bash scripts, where each (parenthesized command) and `backtick-quoted command` launches a new shell. Calls to system() and the like also do it, as does use of Windows ports of *X fork()/exec(). Even if you can't think of any of the above that you used, straightforward ports of a working *X stack to Windows can have a lot of these that, as I said, that you'd be amazed to discover. <br /><br />There's a utility that can show the tree on Windows; I forget the name, though. Microsoft bought it from a third party who had developed it and freely distributed it. (I think it remains free at MS.) We saw impressive improvements in speed and robustness at Schrödinger when we eliminated the above practices on Windows. Big job though. We had a dedicated (in both senses of the word) and super-competent buildmeister who rebuilt our build system to avoid this. Our infrastructure code might have been fixed, too, but some of the runtime issues may remain.<br /><br />-P.samadamsthedoghttps://www.blogger.com/profile/01310722213367887375noreply@blogger.comtag:blogger.com,1999:blog-684443317148892945.post-82007785086860258812016-08-08T06:55:01.919-07:002016-08-08T06:55:01.919-07:00If the conda builds work on RedHat 5, it's lik...If the conda builds work on RedHat 5, it's likely GCC 4.1. With that comparison Visual Studio should actually be compiling in C++11 and gcc would still be doing more explicit copies. <br /><br />So my next stab in the dark guess at why GCC is faster is because GCC 3.4 though 5.1 uses copy-on-write std::string: http://info.prelert.com/blog/cpp-stdstring-implementations That implementation can pseudo-emulate the std::string move semantics well before C++11. <br /><br />Though honestly it may be time to choose one of the most egregious cases and throw it in a profiler. Often times optimizing for one platform yields performance improvements everywhere (but probably to a lesser degree). Happy to stare at Visual Studio profiling output if you post it.<br /><br />Brian Colehttps://www.blogger.com/profile/08750998567017685152noreply@blogger.comtag:blogger.com,1999:blog-684443317148892945.post-65835553181468326852016-08-07T21:00:30.761-07:002016-08-07T21:00:30.761-07:00The Windows builds are done with MS Visual Studio ...The Windows builds are done with MS Visual Studio 2015 community edition and it is a 64bit build.<br /><br />The linux build is using gcc 4.x (I believe 4.4 for the conda builds) and standard cmake release mode flags: "-O3 -NDEBUG".<br /><br />greg landrumhttps://www.blogger.com/profile/10263150365422242369noreply@blogger.comtag:blogger.com,1999:blog-684443317148892945.post-63010164311878540772016-08-05T17:04:00.031-07:002016-08-05T17:04:00.031-07:00Question to make sure we're not comparing appl...Question to make sure we're not comparing apples to oranges. Are they both 64-bit x64 builds? I think MSVC still uses x87 floating point when compiling in 32-bit mode. While it will use SSE vector instructions for x64 builds. <br /><br />Along those lines, what are the GCC flags being compared to? -ffast-math? Then /fp:fast should be used with MSVC. <br /><br />What versions of Visual Studio versus GCC as well? That will help to know what kind of features the compilers will have available to them, for example C++11 move constructors to elide copy construction with the heavy use of the STL in RDKit could make a big difference. Brian Colehttps://www.blogger.com/profile/08750998567017685152noreply@blogger.com