| Horizon68 <horizon@horizon.com>: Mar 27 11:57AM -0700 Hello.. My Parallel C++ Conjugate Gradient Linear System Solver Library that scales very well was updated to version 1.76 You can download it from: https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library Author: Amine Moulay Ramdane Description: This library contains a Parallel implementation of Conjugate Gradient Dense Linear System Solver library that is NUMA-aware and cache-aware that scales very well, and it contains also a Parallel implementation of Conjugate Gradient Sparse Linear System Solver library that is cache-aware that scales very well. Sparse linear system solvers are ubiquitous in high performance computing (HPC) and often are the most computational intensive parts in scientific computing codes. A few of the many applications relying on sparse linear solvers include fusion energy simulation, space weather simulation, climate modeling, and environmental modeling, and finite element method, and large-scale reservoir simulations to enhance oil recovery by the oil and gas industry. Conjugate Gradient is known to converge to the exact solution in n steps for a matrix of size n, and was historically first seen as a direct method because of this. However, after a while people figured out that it works really well if you just stop the iteration much earlier - often you will get a very good approximation after much fewer than n steps. In fact, we can analyze how fast Conjugate gradient converges. The end result is that Conjugate gradient is used as an iterative method for large linear systems today. Please download the zip file and read the readme file inside the zip to know how to use it. Language: GNU C++ and Visual C++ and C++Builder Operating Systems: Windows, Linux, Unix and Mac OS X on (x86) Thank you, Amine Moulay Ramdane. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 26 07:53PM -0400 On 3/26/19 18:21, Chris Vine wrote: > jameskuyper@alumni.caltech.edu wrote: >> He said ... > Have you consider that Bonita may be a woman? ... No, for some reason I never noticed that she was using a feminine name. > ... Women can code as well. Oh yes, I've worked with many female programmers. However, this newsgroup is disproportionately male, and that may have influenced my failure to notice. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 26 07:54PM -0400 On 3/26/19 18:35, Chris Vine wrote: >>> Have you consider that Bonita may be a woman? Women can code as well. >> But they not to be rude.. > Could you recast that, as I can't parse it? I think there's a "tend" missing between "they" and "not". |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 27 06:07AM On Tue, 2019-03-26, Bonita Montero wrote: >>> That depends on what you write. >> Can you cite an example and in doing so, quote correctly? > No, but I can not safely rule out cases I indicated. I have (as usual) not kept track of this thread, but I think the main idea with std::vector is to keep properly constructed objects in a safe and convenient way. I don't think you can expect it to give maximum performance in all corner cases. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 27 08:15AM +0200 > in conflict with expert opinion and without any supporting evidence, > that increasing the size by 1 for each emplaced object will have a > significant detrimental effect on the speed. Bonita is right in that there is a detrimental effect. I just measured it. The initialization of a 800 million element unsigned int vector takes ca 1.3 s with reserve() and emplace_back() and ca 0.9 s with new[] and assignment. This makes ca half of a nanosecond per element. If this detrimental effect is significant is another topic and depends on what this array is used for. If it is not used for anything it can be just deleted and 100% efficiency gained ;-). If it used for anything substantial then the initialization overhead will likely turn insignificant. |
| Juha Nieminen <nospam@thanks.invalid>: Mar 27 09:13AM >> int(), meaning zero. > So do not use resize(). Use push_back(), emplace_back() or range > insert(), possibly after a suitable reserve(). One thing I very often do is resolve the size of a file, create a std::vector<unsigned char> of that size, and then std::fread() the file into the vector. The zero-initialization of the vector is completely unnecessary and a complete waste of time. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Mar 27 09:17AM > The implied question (by parts of my answer that you erased) is why > not to first reserve() and later emplace_back()? Because functions like std::fread() do not emplace_back(). And yes, it's much more efficient to create a vector of the size of the data being read and then read all the data into it with one single std::fread() call, than to do anything more complicated. In this case, the zero-initialization of the vector is a completely useless waste of time. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 27 11:53AM +0200 On 27.03.2019 11:17, Juha Nieminen wrote: > std::fread() call, than to do anything more complicated. > In this case, the zero-initialization of the vector is a completely > useless waste of time. And this waste is completely insignificant in this case because file access takes orders of magnitudes more time. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 27 12:01PM +0200 On 27.03.2019 11:13, Juha Nieminen wrote: > file into the vector. > The zero-initialization of the vector is completely unnecessary and > a complete waste of time. Have you measured how much time you lose this way? 0.01%? If file reading is a performance bottleneck then one should use mmap instead. By using fread() you already say you don't care so much about performance. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 27 11:01AM +0100 >> useless waste of time. > And this waste is completely insignificant in this case because file > access takes orders of magnitudes more time. That depends on the block-size you read at once. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 27 12:05PM +0200 On 27.03.2019 12:01, Bonita Montero wrote: >> And this waste is completely insignificant in this case because file >> access takes orders of magnitudes more time. > That depends on the block-size you read at once. Right, if you read the file by blocks then you can reuse the same std::vector buffer and its initialization overhead becomes even more insignificant. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 27 11:07AM +0100 > Right, if you read the file by blocks then you can reuse the same > std::vector buffer and its initialization overhead becomes even more > insignificant. Then it might be so small that you have a lot of kernel-calls for small blocks which slow down the operation. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 27 12:17PM +0200 On 27.03.2019 12:07, Bonita Montero wrote: >> insignificant. > Then it might be so small that you have a lot of kernel-calls for > small blocks which slow down the operation. Sure, in file I/O there are lots of potential performance issues. But these are not related to std::vector initialization. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 27 12:23PM On Wed, 2019-03-27, Paavo Helde wrote: >> One thing I very often do is resolve the size of a file, create a >> std::vector<unsigned char> of that size, and then std::fread() the >> file into the vector. Presumably with an extra step for when the file grew or shrunk just after you determineed its size. > If file reading is a performance bottleneck then one should use mmap > instead. By using fread() you already say you don't care so much about > performance. And maybe he's already saying that by reading the whole file into a std::vector. YMMV, but most files I read can be read line by line, with only a line at a time in memory. Similarly for all compressed files, etc. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Martijn van Buul <pino@dohd.org>: Mar 27 12:54PM >> Please show me an implementation of any of the containers, or any of the >> "smart" pointers that does not rely on 'new'. > Are you being deliberately obtuse? Obviously Paavo wasn't thinking about implementers of the Standard Library because, like, 0.0000001% of the programmer population are Standard Library implementers. Tne remaining 99.9999999% will still need a working "old-style" new, otherwise their templates won't compile. Also, I would venture that the STL is far from feature-complete regarding data containers. If it wasn't, boost.container would've been out of business, for starters, and boost.intrusive wouldn't have to exist. The STL containers are a decent starting point, but pretending they suffice for all applications is short-sighted at best. -- Martijn van Buul - pino@dohd.org |
| "Öö Tiib" <ootiib@hot.ee>: Mar 27 06:33AM -0700 On Wednesday, 27 March 2019 14:54:45 UTC+2, Martijn van Buul wrote: > have to exist. > The STL containers are a decent starting point, but pretending they suffice > for all applications is short-sighted at best. Are most of those (supposedly superior to STL containers) designed using "old style" new instead of allocator::allocate() and allocator::construct() and "old style" delete instead of allocator::deallocate() and allocator::destroy() for resource management? Why? |
| Daniel <danielaparker@gmail.com>: Mar 27 07:33AM -0700 On Wednesday, March 27, 2019 at 9:33:20 AM UTC-4, Öö Tiib wrote: > "old style" new instead of allocator::allocate() and allocator::construct() > and "old style" delete instead of allocator::deallocate() and > allocator::destroy() for resource management? "Supposedly superior?" What is that supposed to mean? Typical alternative containers attempt to fill gaps that the standard library containers don't cover, such as flat maps, btrees and n-dimensional arrays. As far as I can tell, authors of alternative containers go to great lengths to stay as close as possible to standard library sequence container and associative container concepts, and of course use allocator::allocate() and allocator::destroy(), but at times they struggle. It's not completely trivial, for example, to support stateful allocators in heterogeneous containers with a multitude of internal data structures. Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Mar 27 08:27AM -0700 On Wednesday, 27 March 2019 16:33:22 UTC+2, Daniel wrote: > > and "old style" delete instead of allocator::deallocate() and > > allocator::destroy() for resource management? > "Supposedly superior?" What is that supposed to mean? I meant it in sense of having allegedly/probably/seemingly superior algorithm in sense of storage usage and/or performance for particular task type under hand. > but at times they struggle. It's not completely trivial, for example, to > support stateful allocators in heterogeneous containers with a multitude of > internal data structures. I did not try to imply that anything of it is trivial. I just asked two questions. I asked because I knew that the libraries in Boost either use other containers (as underlying containers) or use allocators instead using new or delete directly or don't deal with management at all (like Boost.Intrusive). |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment