Dear all I am trying to run ginac with openmp and get seg faults... [all in a very naive fashion at the moment]. Is the code supposed to run ad hoc with openmp (compiled accordingly of course)/ are there any pitfalls/ ... ?? Any help is appreciated Thanks Best Tania
On Sat, 2 Dec 2017 00:33:26 +0000, Tania Robens <robens@pa.msu.edu> said:
TR> Dear all I am trying to run ginac with openmp and get seg TR> faults... [all in a very naive fashion at the moment]. Is the TR> code supposed to run ad hoc with openmp (compiled accordingly of TR> course)/ are there any pitfalls/ ... ?? I am not an expert in this, but it seems to me that GiNaC is designed in way which is not compatible with parallel computing. Some internals are dynamically generated in the assumption, that there is only the single thread.... -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
Dear Vladimir, all thanks. Are there any efforts to change this ?? I think it might be useful (in general) for future users/ developments/ etc Thanks Best Tania On Sat, 2 Dec 2017, Vladimir V. Kisil wrote:
On Sat, 2 Dec 2017 00:33:26 +0000, Tania Robens <robens@pa.msu.edu> said:
TR> Dear all I am trying to run ginac with openmp and get seg TR> faults... [all in a very naive fashion at the moment]. Is the TR> code supposed to run ad hoc with openmp (compiled accordingly of TR> course)/ are there any pitfalls/ ... ??
I am not an expert in this, but it seems to me that GiNaC is designed in way which is not compatible with parallel computing. Some internals are dynamically generated in the assumption, that there is only the single thread.... -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ _______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
------------------------------------------------------------------------- Dr. habil. Tania Robens Michigan State University Department of Physics and Astronomy 567 Wilson Road East Lansing, MI 48824 USA
On Sun, 3 Dec 2017 01:54:14 +0100, robens <robens@pa.msu.edu> said:
TR> thanks. Are there any efforts to change this ?? I think it might TR> be useful (in general) for future users/ developments/ etc My understanding: for automated simplifications GiNaC produces a large amount of dynamically created objects and they are internally indexed by consecutive numbers. If parts of an expression are transformed in parallel threads, then there will be inconsistency between different objects with the same index. This cannot be changed by gradual improvements, a significant part of code (and probably some ideology) need to be replaced in one move---an ambitious task requiring a dedicated (team of) developer(s). See also the thread of discussion started at: https://www.ginac.de/pipermail/ginac-list/2010-August/001719.html May be, certain algorithms can be written thread-safe through some kind of wrappers for GiNaC expressions, but their computational cost possibly absorbs all gain from multi-treading. -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
On 12/03/2017 10:28 AM, Vladimir V. Kisil wrote:
On Sun, 3 Dec 2017 01:54:14 +0100, robens <robens@pa.msu.edu> said:
TR> thanks. Are there any efforts to change this ?? I think it might TR> be useful (in general) for future users/ developments/ etc
My understanding: for automated simplifications GiNaC produces a large amount of dynamically created objects and they are internally indexed by consecutive numbers. If parts of an expression are transformed in parallel threads, then there will be inconsistency between different objects with the same index.
Additionally, GiNaC and CLN both use reference counting for garbage collection of their objects. The naive approach to make that thread-safe is to add locks around reference counting operations -- and that involves a performance penalty (which probably grows the more processors you have). I did a small experiment to simply change reference counts into atomic variables, and got an instant 30% performance hit for single-threaded code on a 2-core machine, and maybe a 20% overall performance improvement for one particular '#program omp for' loop from my code (in the instances when it didn't crash; changing the reference counts to atomics is not enough to make the whole thing thread-safe, I only did it to measure potential performance impact). There's potentially a different way to solve garbage collection problem: just drop all of the reference counting code, and link with something like Boehm GC [1], which is known to work (and even well) in multi-threaded environment. If anyone wants to investigate the potential performance impact/benefit of this approach, I would really like to see the results. In the mean while, I think a more practical way to scale GiNaC code to multi-processor systems is process-based parallelism and message passing. Fortunately GiNaC's 'archive' class provides a fairly convenient and reasonably fast way to serialize/deserialize arbitrary 'ex' objects, so you could build a sort of map-reduce thing on top of that and your favorite message-passing library (e.g. MPI, ZeroMQ, that sort of thing) and use it instead of '#program omp for'. This is much less convenient than OpenMP, of course, and requires a good bit more of engineering effort. [1] http://www.hboehm.info/gc/
participants (4)
-
robens
-
Tania Robens
-
Vitaly Magerya
-
Vladimir V. Kisil