Hello, I have declared a GiNaC::parser l_parser; in a class method which is called in a multithread. If I show valgrind report I see: ==1084== Possible data race during write of size 1 at 0x1f06e4 by thread #3 ==1084== at 0x1B30F6: std::string::_Rep::_M_set_length_and_sharable(unsigned long) (in /usr/ lib/libstdc++.6.0.4.dylib) ==1084== by 0x1B39FB: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (in /usr/lib/libstdc++.6.0.4.dylib) ==1084== by 0x1B3A43: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (in /usr/lib/libstdc++. 6.0.4.dylib) ==1084== by 0x1B3AE7: std::string::assign(char const*, unsigned long) (in /usr/lib/libstdc++.6.0.4.dylib) ==1084== by 0x115D139: GiNaC::lexer::lexer(std::istream*, std::ostream*, std::ostream*) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) ==1084== by 0x1157CC2: GiNaC::parser::parser(std::map<std::string, GiNaC::ex, std::less<std::string>, std::allocator<std::pair<std::string const, GiNaC::ex> > > const&, bool, std::map<std::pair<std::string, unsigned long>, GiNaC::ex (*) (std::vector<GiNaC::ex, std::allocator<GiNaC::ex> > const&), std::less<std::pair<std::string, unsigned long> >, std::allocator<std::pair<std::pair<std::string, unsigned long> const, GiNaC::ex (*)(std::vector<GiNaC::ex, std::allocator<GiNaC::ex> > const&)> > > const&) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) When will be ginac thread safe and is there such a thing? Thx Phil
Hello, On Mon, Aug 23, 2010 at 01:18:11PM +0200, Kraus Philipp wrote:
I have declared a GiNaC::parser l_parser; in a class method which is called in a multithread.
GiNaC is not thread safe, this is documented in the manual. [skipped]
When will be ginac thread safe and is there such a thing?
There are no plans to make GiNaC thread safe. Parallel versions of symbolic algorithms are not much faster (and sometimes even slower) than their sequential counterparts. So why bother? Best regards, Alexei
Am 23.08.2010 um 15:51 schrieb Alexei Sheplyakov:
When will be ginac thread safe and is there such a thing?
There are no plans to make GiNaC thread safe. Parallel versions of symbolic algorithms are not much faster (and sometimes even slower) than their sequential counterparts. So why bother?
Thanks, but I'm writing some algorithm that can be multithreaded. I use GiNaC for the symbolic arithmetic, but I can do this in parallel. The std structures are not thread-safe, so my algorithms run into race condition errors, because GiNaC uses them (like the parser). IMHO Ginac must not be parallelized, but only the structures should be thread-safe, so they can't create race condition errors. Eg: I create in multithreaded a lot of diff's and Ginac::mul, ::basic, ::ex, ::add create a lot of errors. I think I will try to create a mutex around them and create a wrapper class for the Ginac calls, but it's not my favorite solution Thanks Phil
in some cases, parallel symbolic algorithms obtain great performance increase, it all depends how you model the problem. im using ginac with openMPI to paralelize huge tree generators, i had to go the processes paralelism since multithread is not safe, but would be nice to be able to do that on the future On Mon, Aug 23, 2010 at 10:19 AM, Kraus Philipp <philipp.kraus@flashpixx.de>wrote:
Am 23.08.2010 um 15:51 schrieb Alexei Sheplyakov:
When will be ginac thread safe and is there such a thing?
There are no plans to make GiNaC thread safe. Parallel versions of symbolic algorithms are not much faster (and sometimes even slower) than their sequential counterparts. So why bother?
Thanks, but I'm writing some algorithm that can be multithreaded. I use GiNaC for the symbolic arithmetic, but I can do this in parallel. The std structures are not thread-safe, so my algorithms run into race condition errors, because GiNaC uses them (like the parser). IMHO Ginac must not be parallelized, but only the structures should be thread-safe, so they can't create race condition errors. Eg: I create in multithreaded a lot of diff's and Ginac::mul, ::basic, ::ex, ::add create a lot of errors. I think I will try to create a mutex around them and create a wrapper class for the Ginac calls, but it's not my favorite solution
Thanks
Phil
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Am 23.08.2010 um 16:39 schrieb Cristobal Navarro:
in some cases, parallel symbolic algorithms obtain great performance increase, it all depends how you model the problem. im using ginac with openMPI to paralelize huge tree generators, i had to go the processes paralelism since multithread is not safe, but would be nice to be able to do that on the future
I' working with MPI (on boost) and in this case it works on my test system. But I would like to portage my algorithm without MPI support (on a simple desktop system MPI support is not installed, but on these systems I can use multithreading). I have tried to compile ginac with -pthread on CXXFLAGS and the CLN library. I analyse the compiled code with valgrind, you can show the excerpt: ==51729== Possible data race during write of size 4 at 0x1ea4564 by thread #3 ==51729== at 0x3AB9: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C49F: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in / Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4B9: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in / Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4D3: GiNaC::ex::ex(GiNaC::ex const&) (in / Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4ED: GiNaC::ex::ex(GiNaC::ex const&) (in / Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C51F: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C539: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7E4F3: void std::_Construct<GiNaC::expair, GiNaC::expair>(GiNaC::expair*, GiNaC::expair const&) (in /Developer/ opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7F3E9: GiNaC::expair* std ::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, __false_type) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) ==51729== by 0xF7F43C: GiNaC::expair* std::uninitialized_copy<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7F45E: GiNaC::expair* std::__uninitialized_copy_a<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, GiNaC::expair>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, std::allocator<GiNaC::expair>) (in /Developer/opt/ Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7F518: std::vector<GiNaC::expair, std::allocator<GiNaC::expair> >::vector(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&) (in /Developer/opt/Ginac/1.5.8/ lib/libginac-1.5.0.dylib) in the same run: ==51729== Possible data race during read of size 4 at 0x1ea42f4 by thread #3 ==51729== at 0x3AB6: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C5AB: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5C5: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5ED: GiNaC::ex::ex() (in /Developer/opt/Ginac/ 1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C604: GiNaC::ex::ex() (in /Developer/opt/Ginac/ 1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xFCBC50: GiNaC::expairseq::expairseq() (in /Developer/ opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD804: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD88C: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FF9D0: GiNaC::exminus(GiNaC::ex const&) (in / Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FFDD0: GiNaC::operator-(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) ==51729== by 0x10BDB0C: GiNaC::mul::derivative(GiNaC::symbol const&) const (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF965E3: GiNaC::basic::diff(GiNaC::symbol const&, unsigned int) const (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) HTH the developers Phil
i understand the frustation :( i once opened a topic too, asking if a particular case would be thread safe, ginac is one of the best symbolic math libraries around, and it has proveed that it works great on large cluster problems, its just that the middle multithreading escenario is missing support, lets hope that in the future there could be plans for doing some work on the thread safety. On Mon, Aug 23, 2010 at 12:13 PM, Kraus Philipp <philipp.kraus@flashpixx.de>wrote:
Am 23.08.2010 um 16:39 schrieb Cristobal Navarro:
in some cases,
parallel symbolic algorithms obtain great performance increase, it all depends how you model the problem. im using ginac with openMPI to paralelize huge tree generators, i had to go the processes paralelism since multithread is not safe, but would be nice to be able to do that on the future
I' working with MPI (on boost) and in this case it works on my test system. But I would like to portage my algorithm without MPI support (on a simple desktop system MPI support is not installed, but on these systems I can use multithreading). I have tried to compile ginac with -pthread on CXXFLAGS and the CLN library. I analyse the compiled code with valgrind, you can show the excerpt:
==51729== Possible data race during write of size 4 at 0x1ea4564 by thread #3 ==51729== at 0x3AB9: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C49F: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4B9: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4D3: GiNaC::ex::ex(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4ED: GiNaC::ex::ex(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C51F: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C539: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7E4F3: void std::_Construct<GiNaC::expair, GiNaC::expair>(GiNaC::expair*, GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F3E9: GiNaC::expair* std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, __false_type) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F43C: GiNaC::expair* std::uninitialized_copy<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F45E: GiNaC::expair* std::__uninitialized_copy_a<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, GiNaC::expair>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, std::allocator<GiNaC::expair>) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F518: std::vector<GiNaC::expair, std::allocator<GiNaC::expair> >::vector(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
in the same run:
==51729== Possible data race during read of size 4 at 0x1ea42f4 by thread #3 ==51729== at 0x3AB6: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C5AB: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5C5: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5ED: GiNaC::ex::ex() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C604: GiNaC::ex::ex() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xFCBC50: GiNaC::expairseq::expairseq() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD804: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD88C: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FF9D0: GiNaC::exminus(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FFDD0: GiNaC::operator-(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BDB0C: GiNaC::mul::derivative(GiNaC::symbol const&) const (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF965E3: GiNaC::basic::diff(GiNaC::symbol const&, unsigned int) const (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
HTH the developers
Phil
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
from my understanding, the issue is with the memory system of ginac [anyone feel free to correct me on this]. It seems that ginac uses reference counting is some form for ex types. In addition it seems that they store the lookup in STL containers [map]. So when you try to manipulate expressions from multiple threads, they are all trying to access that lookup table. I imagine that it would be a rather formidable task to alter the underlying memory system in ginac. On Mon, Aug 23, 2010 at 12:23 PM, Cristobal Navarro <axischire@gmail.com> wrote:
i understand the frustation :( i once opened a topic too, asking if a particular case would be thread safe, ginac is one of the best symbolic math libraries around, and it has proveed that it works great on large cluster problems, its just that the middle multithreading escenario is missing support, lets hope that in the future there could be plans for doing some work on the thread safety.
On Mon, Aug 23, 2010 at 12:13 PM, Kraus Philipp <philipp.kraus@flashpixx.de> wrote:
Am 23.08.2010 um 16:39 schrieb Cristobal Navarro:
in some cases, parallel symbolic algorithms obtain great performance increase, it all depends how you model the problem. im using ginac with openMPI to paralelize huge tree generators, i had to go the processes paralelism since multithread is not safe, but would be nice to be able to do that on the future
I' working with MPI (on boost) and in this case it works on my test system. But I would like to portage my algorithm without MPI support (on a simple desktop system MPI support is not installed, but on these systems I can use multithreading). I have tried to compile ginac with -pthread on CXXFLAGS and the CLN library. I analyse the compiled code with valgrind, you can show the excerpt:
==51729== Possible data race during write of size 4 at 0x1ea4564 by thread #3 ==51729== at 0x3AB9: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C49F: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4B9: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::ptr<GiNaC::basic> const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4D3: GiNaC::ex::ex(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C4ED: GiNaC::ex::ex(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C51F: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C539: GiNaC::expair::expair(GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7E4F3: void std::_Construct<GiNaC::expair, GiNaC::expair>(GiNaC::expair*, GiNaC::expair const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F3E9: GiNaC::expair* std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, __false_type) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F43C: GiNaC::expair* std::uninitialized_copy<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F45E: GiNaC::expair* std::__uninitialized_copy_a<__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, GiNaC::expair>(__gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, __gnu_cxx::__normal_iterator<GiNaC::expair const*, std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > >, GiNaC::expair*, std::allocator<GiNaC::expair>) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
==51729== by 0xF7F518: std::vector<GiNaC::expair, std::allocator<GiNaC::expair> >::vector(std::vector<GiNaC::expair, std::allocator<GiNaC::expair> > const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
in the same run:
==51729== Possible data race during read of size 4 at 0x1ea42f4 by thread #3 ==51729== at 0x3AB6: GiNaC::refcounted::add_reference() (in main) ==51729== by 0xF7C5AB: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5C5: GiNaC::ptr<GiNaC::basic>::ptr(GiNaC::basic&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C5ED: GiNaC::ex::ex() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF7C604: GiNaC::ex::ex() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xFCBC50: GiNaC::expairseq::expairseq() (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD804: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BD88C: GiNaC::mul::mul(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FF9D0: GiNaC::exminus(GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10FFDD0: GiNaC::operator-(GiNaC::ex const&, GiNaC::ex const&) (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0x10BDB0C: GiNaC::mul::derivative(GiNaC::symbol const&) const (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib) ==51729== by 0xF965E3: GiNaC::basic::diff(GiNaC::symbol const&, unsigned int) const (in /Developer/opt/Ginac/1.5.8/lib/libginac-1.5.0.dylib)
HTH the developers
Phil
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Am 23.08.2010 um 18:23 schrieb Cristobal Navarro:
i once opened a topic too, asking if a particular case would be thread safe, ginac is one of the best symbolic math libraries around, and it has proveed that it works great on large cluster problems, its just that the middle multithreading escenario is missing support, lets hope that in the future there could be plans for doing some work on the thread safety.
Yes, ginac is in my project perfect. I woudln't like to swtich to another lib. I hope that the developers can change the code to thread- safe code Thanks a lot to all developers
what features of GiNaC are you using? It implements a lot of Mathematical 'things'. I used it originally as simply a representation for symbolic expressions and evaluation. I found that I could not modify an expression ( they only return const &'s), and that evaluation was too slow for my application. On Mon, Aug 23, 2010 at 12:45 PM, Kraus Philipp <philipp.kraus@flashpixx.de> wrote:
Am 23.08.2010 um 18:23 schrieb Cristobal Navarro:
i once opened a topic too, asking if a particular case would be thread safe, ginac is one of the best symbolic math libraries around, and it has proveed that it works great on large cluster problems, its just that the middle multithreading escenario is missing support, lets hope that in the future there could be plans for doing some work on the thread safety.
Yes, ginac is in my project perfect. I woudln't like to swtich to another lib. I hope that the developers can change the code to thread-safe code
Thanks a lot to all developers _______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Am 23.08.2010 um 18:49 schrieb Tony Worm:
what features of GiNaC are you using? It implements a lot of Mathematical 'things'. I used it originally as simply a representation for symbolic expressions and evaluation. I found that I could not modify an expression ( they only return const &'s), and that evaluation was too slow for my application.
I'm using at this time (and in future I think so) only the numerical / symbolic structurs. I need only arithmetics with symbolic expression for parsing string data into an expression, create some derivates and calulating the value. But my algorithms have a lot of data, so I must run the calculating for many values and at this point I would like to do this in parallel (on MPI for cluster system and multithreading for desktop).
On Mon, Aug 23, 2010 at 12:45 PM, Kraus Philipp <philipp.kraus@flashpixx.de> wrote:
Am 23.08.2010 um 18:23 schrieb Cristobal Navarro:
i once opened a topic too, asking if a particular case would be thread safe, ginac is one of the best symbolic math libraries around, and it has proveed that it works great on large cluster problems, its just that the middle multithreading escenario is missing support, lets hope that in the future there could be plans for doing some work on the thread safety.
Yes, ginac is in my project perfect. I woudln't like to swtich to another lib. I hope that the developers can change the code to thread-safe code
Thanks a lot to all developers _______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
participants (4)
-
Alexei Sheplyakov
-
Cristobal Navarro
-
Kraus Philipp
-
Tony Worm