is ginac thread safe for this case?
will ginac be thread safe for this case? 1) threads access diferent expressions which are independant 2) each thread will increase the expression its working in.. for example thread1...expression1 += x+y thread2.... expression2 += 2*x.... and so on. 2) no function evaluation is done never. 3) however, all expressions share the same global symbols ( eg, expressions made of global symbols x and y ). 4) threads access the same common matrix of expressions, but two threads will never access the same cell. i'am testing at the moment, and is working but in the long run i am not sure if problems will arise. any information, welcome. thanks in advance. Cristobal <http://www.youtube.com/neoideo>
Hello, On Sat, Jun 12, 2010 at 07:01:47PM -0400, Cristobal Navarro wrote:
will ginac be thread safe for this case?
GiNaC is not thread safe. Therefore one can use GiNaC only from one thread.
1) threads access diferent expressions which are independant 2) each thread will increase the expression its working in.. for example thread1...expression1 += x+y thread2.... expression2 += 2*x.... and so on. 2) no function evaluation is done never. 3) however, all expressions share the same global symbols ( eg, expressions made of global symbols x and y ). 4) threads access the same common matrix of expressions, but two threads will never access the same cell.
None of these is going to work. Most likely your program will segfault or give some bizzare results. Best regards, Alexei
Hi, Am 13.06.2010 11:22, schrieb Alexei Sheplyakov:
will ginac be thread safe for this case?
GiNaC is not thread safe. Therefore one can use GiNaC only from one thread.
correct.
1) threads access diferent expressions which are independant 2) each thread will increase the expression its working in.. for example thread1...expression1 += x+y thread2.... expression2 += 2*x.... and so on. 2) no function evaluation is done never. 3) however, all expressions share the same global symbols ( eg, expressions made of global symbols x and y ). 4) threads access the same common matrix of expressions, but two threads will never access the same cell.
You avoided already a lot of possible problems with that list (also stay away from integrate(), archiving, output modifiers). But things like tensor objects, which you probably don't use, and gcd, which you might use implicitly, use static local variables that make these internal ginac functions non-reentrant (it probably works most of the time, though, but hey, it's russian roulette). This ginac code could actually be made thread-safe, I think. But at the moment it isn't. And then there is libcln you are also relying on and which is also not thread-safe. Whether you get problems with the numerics in your expressions depends very much on the specific numbers in your expression. Maybe you were lucky using just small integers (I am not an expert with libcln)? Regards, Jens
Hello, On Sun, Jun 13, 2010 at 11:50:35AM +0200, Jens Vollinga wrote:
You avoided already a lot of possible problems with that list (also stay away from integrate(), archiving, output modifiers).
The reference counting in GiNaC is not thread safe. Therefore one thread might delete an expression which is used by another thread. Hence you *really* can't use GiNaC from different threads.
But things like tensor objects, which you probably don't use, and gcd, which you might use implicitly, use static local variables that make these internal ginac functions non-reentrant (it probably works most of the time, though, but hey, it's russian roulette).
This ginac code could actually be made thread-safe, I think.
Only few symbolic algorithms can be parallelized, and performance gain (if any) is not that big. So why bother? Best regards, Alexei
Hi, Am 13.06.2010 12:35, schrieb Alexei Sheplyakov:
The reference counting in GiNaC is not thread safe. Therefore one thread might delete an expression which is used by another thread. Hence you *really* can't use GiNaC from different threads.
I completely agree with your last sentence! This is what I wrote in my last mail (but maybe you consider Russian roulette not as dangerous as I do ... ;-) ). I just wanted to explain more than just saying "It doesn't work.". I didn't mention refcounting, because I think in his setup it doesn't cause a problem, or does it?.
Only few symbolic algorithms can be parallelized, and performance gain
That might be true for "schoolbook" algorithms like gcd, factorization, etc, but not for more complex computational tasks involving cascades of manipulation steps performed on large number of expressions.
(if any) is not that big. So why bother?
Aforementioned tasks can in principle hope for huge performance gains depending on the number of cpu cores. Of course, one could statically link ginac/cln and run multiple instances of one's own program with ipc here and then to achieve some sort of parallelization. But I don't like that idea. Regards, Jens
On Sun, Jun 13, 2010 at 01:27:26PM +0200, Jens Vollinga wrote:
I completely agree with your last sentence! This is what I wrote in my last mail
I'm afraid you've missed the point. I wanted to explain that one of the essential mechanisms used by GiNaC (memory management) is not thread safe, therefore all setups (except using GiNaC from one thread) are unsafe.
(but maybe you consider Russian roulette not as dangerous as I do ... ;-) ).
I just think using GiNaC from several threads is more dangerous than Russian roulette :)
I just wanted to explain more than just saying "It doesn't work.".
Ok, if someone wants the gory details... 1. Automatic evaluation is not thread safe. Have a look at ex::construct_from_basic (which is basically the core of automatic evaluation). That code does 318 // If the original object is not referenced but heap-allocated, 319 // it means that eval() hit case b) above. The original object is 320 // no longer needed (it evaluated into something different), so we 321 // delete it (because nobody else will). 322 if ((other.get_refcount() == 0) && (other.flags & status_flags::dynallocated)) 323 delete &other; // yes, you can apply delete to a const pointer 324 The reference counting is not thread safe, so the object can be deleted while it's used by another thread. 2. GiNaC smart pointers are not thread safe. In theory it can be fixed by using atomic integers for reference counting, and locking in makewritable(). 3. GiNaC uses STL containers to store sums and products. STL containers are not thread safe at all. 4. Subs() uses writable access (let_op()), and has no locking at all.
I didn't mention refcounting, because I think in his setup it doesn't cause a problem, or does it?.
No matter what your setup is, you're going to use the automatic evaluation (otherwise you don't need GiNaC at all). And it's not thread safe (due to reference counting, data structures, etc). So the only safe setup is using GiNaC from one thread.
Only few symbolic algorithms can be parallelized, and performance gain
That might be true for "schoolbook" algorithms like gcd, factorization, etc, but not for more complex computational tasks involving cascades of manipulation steps performed on large number of expressions.
(if any) is not that big. So why bother?
Aforementioned tasks can in principle hope for huge performance gains depending on the number of cpu cores.
I'm afraid locks will ruin any performance gains. I mean, if you need to take a lock every time you need to add two and integers or allocate several bytes of RAM, you can't achive any reasonable performance. Best regards, Alexei
Thanks for every answer, ill have to find a solution for this. i am liking ginac so much that i would have been perfect if this was possible, but its ok !. The algorithm is computing intensive (for research). now i have two options i could search for another free symbolic library thread-safe (which for me is unknown, does such library exist?) or i could put and end to this and program myself a simple and thread-safe symbol-expression environment for my needs, which are very reduced (i only use polinomies, big in size but in the end they are polinomial expressions). i guess i dont have anymore questions thanks again everyone! On Sun, Jun 13, 2010 at 10:30 AM, Alexei Sheplyakov < alexei.sheplyakov@gmail.com> wrote:
On Sun, Jun 13, 2010 at 01:27:26PM +0200, Jens Vollinga wrote:
I completely agree with your last sentence! This is what I wrote in my last mail
I'm afraid you've missed the point. I wanted to explain that one of the essential mechanisms used by GiNaC (memory management) is not thread safe, therefore all setups (except using GiNaC from one thread) are unsafe.
(but maybe you consider Russian roulette not as dangerous as I do ... ;-) ).
I just think using GiNaC from several threads is more dangerous than Russian roulette :)
I just wanted to explain more than just saying "It doesn't work.".
Ok, if someone wants the gory details...
1. Automatic evaluation is not thread safe.
Have a look at ex::construct_from_basic (which is basically the core of automatic evaluation). That code does
318 // If the original object is not referenced but heap-allocated, 319 // it means that eval() hit case b) above. The original object is 320 // no longer needed (it evaluated into something different), so we 321 // delete it (because nobody else will). 322 if ((other.get_refcount() == 0) && (other.flags & status_flags::dynallocated)) 323 delete &other; // yes, you can apply delete to a const pointer 324
The reference counting is not thread safe, so the object can be deleted while it's used by another thread.
2. GiNaC smart pointers are not thread safe. In theory it can be fixed by using atomic integers for reference counting, and locking in makewritable().
3. GiNaC uses STL containers to store sums and products. STL containers are not thread safe at all.
4. Subs() uses writable access (let_op()), and has no locking at all.
I didn't mention refcounting, because I think in his setup it doesn't cause a problem, or does it?.
No matter what your setup is, you're going to use the automatic evaluation (otherwise you don't need GiNaC at all). And it's not thread safe (due to reference counting, data structures, etc). So the only safe setup is using GiNaC from one thread.
Only few symbolic algorithms can be parallelized, and performance gain
That might be true for "schoolbook" algorithms like gcd, factorization, etc, but not for more complex computational tasks involving cascades of manipulation steps performed on large number of expressions.
(if any) is not that big. So why bother?
Aforementioned tasks can in principle hope for huge performance gains depending on the number of cpu cores.
I'm afraid locks will ruin any performance gains. I mean, if you need to take a lock every time you need to add two and integers or allocate several bytes of RAM, you can't achive any reasonable performance.
Best regards, Alexei
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Hi! Am 13.06.2010 17:24, schrieb Cristobal Navarro:
now i have two options i could search for another free symbolic library thread-safe (which for me is unknown, does such library exist?) or
There is tform (http://www.nikhef.nl/~form/), for example.
i could put and end to this and program myself a simple and thread-safe symbol-expression environment for my needs, which are very reduced (i only use polinomies, big in size but in the end they are polinomial expressions).
Or statically link your program and run different instances simultaneously? Regards, Jens
thanks, i will look at this On Sun, Jun 13, 2010 at 11:30 AM, Jens Vollinga <jensv@nikhef.nl> wrote:
Hi!
Am 13.06.2010 17:24, schrieb Cristobal Navarro:
now i have two options
i could search for another free symbolic library thread-safe (which for me is unknown, does such library exist?) or
There is tform (http://www.nikhef.nl/~form/), for example.
i could put and end to this and program myself a simple and thread-safe
symbol-expression environment for my needs, which are very reduced (i only use polinomies, big in size but in the end they are polinomial expressions).
Or statically link your program and run different instances simultaneously?
Regards, Jens
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Hi, On Sun, Jun 13, 2010 at 05:30:56PM +0200, Jens Vollinga wrote:
There is tform (http://www.nikhef.nl/~form/), for example.
This is not a (C/C++) library, and it's not free. Best regards, Alexei
Hi, Am 13.06.2010 16:30, schrieb Alexei Sheplyakov:
I'm afraid you've missed the point. I wanted to explain that one of the essential mechanisms used by GiNaC (memory management) is not thread safe, therefore all setups (except using GiNaC from one thread) are unsafe.
this I don't believe yet. Maybe I am wrong, but the setup as he described it has no (and will not have any) sharing of subexpressions between threads.
I just think using GiNaC from several threads is more dangerous than Russian roulette :)
oh, please wait, reconsider! Your opinion might backfire someday ... ;-)
1. Automatic evaluation is not thread safe.
yes, but ...
Have a look at ex::construct_from_basic (which is basically the core of automatic evaluation). That code does
318 // If the original object is not referenced but heap-allocated, 319 // it means that eval() hit case b) above. The original object is 320 // no longer needed (it evaluated into something different), so we 321 // delete it (because nobody else will). 322 if ((other.get_refcount() == 0)&& (other.flags& status_flags::dynallocated)) 323 delete&other; // yes, you can apply delete to a const pointer 324
The reference counting is not thread safe, so the object can be deleted while it's used by another thread.
... all objects in his setup are 100% private to each thread. So I don't see a problem.
2. GiNaC smart pointers are not thread safe. In theory it can be fixed by using atomic integers for reference counting, and locking in makewritable().
3. GiNaC uses STL containers to store sums and products. STL containers are not thread safe at all.
4. Subs() uses writable access (let_op()), and has no locking at all.
Same box.
I didn't mention refcounting, because I think in his setup it doesn't cause a problem, or does it?.
No matter what your setup is, you're going to use the automatic evaluation (otherwise you don't need GiNaC at all). And it's not thread safe (due to reference counting, data structures, etc). So the only safe setup is using GiNaC from one thread.
I think the only problem (in his setup) is a possible call to the gcd code.
I'm afraid locks will ruin any performance gains. I mean, if you need to take a lock every time you need to add two and integers or allocate several bytes of RAM, you can't achive any reasonable performance.
You were right if you made ginac thread-safe in a naive way, i.e. many locks protecting refcounting, functions, etc. While I don't know about cln, yet, in ginac it can be done in a smarter way. Instead of making ginac absolutely thread-safe in any use-case, one can enable the user to specify data/expression segments to which certain expressions, symbols or whatever should belong. Then, ginac ensures that it is thread-safe between these different segments. Some extra functions to let the user share or transport data between the segments need to be implemented and voila. That is just a rough idea, but the threading overhead would be minimized to keep it attractive. Regards, Jens
Still, i will complete the testing phase, and i will share my results. and if it worked i will give you some statistics of the behaveiur of the program, (seccesful launchs, rate of segfaults, wrong answers) On Sun, Jun 13, 2010 at 11:26 AM, Jens Vollinga <jensv@nikhef.nl> wrote:
Hi,
Am 13.06.2010 16:30, schrieb Alexei Sheplyakov:
I'm afraid you've missed the point. I wanted to explain that one of
the essential mechanisms used by GiNaC (memory management) is not thread safe, therefore all setups (except using GiNaC from one thread) are unsafe.
this I don't believe yet. Maybe I am wrong, but the setup as he described it has no (and will not have any) sharing of subexpressions between threads.
I just think using GiNaC from several threads is more dangerous than
Russian roulette :)
oh, please wait, reconsider! Your opinion might backfire someday ... ;-)
1. Automatic evaluation is not thread safe.
yes, but ...
Have a look at ex::construct_from_basic (which is basically the core of automatic evaluation). That code does
318 // If the original object is not referenced but heap-allocated, 319 // it means that eval() hit case b) above. The original object is 320 // no longer needed (it evaluated into something different), so we 321 // delete it (because nobody else will). 322 if ((other.get_refcount() == 0)&& (other.flags& status_flags::dynallocated)) 323 delete&other; // yes, you can apply delete to a const pointer 324
The reference counting is not thread safe, so the object can be deleted while it's used by another thread.
... all objects in his setup are 100% private to each thread. So I don't see a problem.
2. GiNaC smart pointers are not thread safe. In theory it can be fixed
by using atomic integers for reference counting, and locking in makewritable().
3. GiNaC uses STL containers to store sums and products. STL containers are not thread safe at all.
4. Subs() uses writable access (let_op()), and has no locking at all.
Same box.
I didn't mention refcounting, because I think in his setup it doesn't
cause a problem, or does it?.
No matter what your setup is, you're going to use the automatic evaluation (otherwise you don't need GiNaC at all). And it's not thread safe (due to reference counting, data structures, etc). So the only safe setup is using GiNaC from one thread.
I think the only problem (in his setup) is a possible call to the gcd code.
I'm afraid locks will ruin any performance gains. I mean, if you need to
take a lock every time you need to add two and integers or allocate several bytes of RAM, you can't achive any reasonable performance.
You were right if you made ginac thread-safe in a naive way, i.e. many locks protecting refcounting, functions, etc.
While I don't know about cln, yet, in ginac it can be done in a smarter way. Instead of making ginac absolutely thread-safe in any use-case, one can enable the user to specify data/expression segments to which certain expressions, symbols or whatever should belong. Then, ginac ensures that it is thread-safe between these different segments. Some extra functions to let the user share or transport data between the segments need to be implemented and voila. That is just a rough idea, but the threading overhead would be minimized to keep it attractive.
Regards, Jens
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
On Sun, Jun 13, 2010 at 05:26:16PM +0200, Jens Vollinga wrote:
I'm afraid you've missed the point. I wanted to explain that one of the essential mechanisms used by GiNaC (memory management) is not thread safe, therefore all setups (except using GiNaC from one thread) are unsafe.
this I don't believe yet. Maybe I am wrong, but the setup as he described it has no (and will not have any) sharing of subexpressions between threads.
I'm afraid tracking shared subexpressions is somewhat nontrivial. Consider the following example: ex a = pow(x1 + x2 + x3, 2); ex b = pow(x1 - x2 - x3, 3); ex e[2]; e[0] = a*b; e[1] = (a*b).diff(x1); Expressions e[0] and e[1] share a and b (that's just a funny implementation detail). Suppose thread A operates on e[0] and thread B operates on e[1]: // thread A e[0] = e[0].expand(); // no references to a and b any more // thread B e[1] = e[1].diff(x2); // a*b'' + 2*a'*b' + a''*b, one more reference to a and b Thread A has no references to a and b after expand() completes its job, so it will try to decrement their refcount. On the other hand, thread B will try to increment refcounts of a and b. That's a disaster, since nothing protects refcount from concurrent modification. [It's easy to find out shared subexpressions in the above example, but in general it's not the case, unfortunately]
4) threads access the same common matrix of expressions, but two threads will never access the same cell.
This does NOT guarantee that you (or GiNaC on your behalf) won't operate on a same (sub)expression from different threads. You *really* need a thread safe (or atomic) reference counting to solve this problem.
I think the only problem (in his setup) is a possible call to the gcd code.
As far as I understand GCD code is not any worse in this regard (that said, it's not any better either). I might be wrong (I'm just a human being), so I'd be grateful if someone could point out any non-reentrant code in GCD routines.
I'm afraid locks will ruin any performance gains. I mean, if you need to take a lock every time you need to add two and integers or allocate several bytes of RAM, you can't achive any reasonable performance.
You were right if you made ginac thread-safe in a naive way, i.e. many locks protecting refcounting, functions, etc.
I have some experience with those `somewhat thread safe' libraries, therefore I strongly dislike this kind of ... cleverness (let's put it this way). Best regards, Alexei
Hi! Am 13.06.2010 20:05, schrieb Alexei Sheplyakov:
4) threads access the same common matrix of expressions, but two threads will never access the same cell.
This does NOT guarantee that you (or GiNaC on your behalf) won't operate on a same (sub)expression from different threads. You *really* need a thread safe (or atomic) reference counting to solve this problem.
ah, now I see why we keep arguing: I misread point 4 completely!!! I thought he meant to have a clear the separation of expressions between threads (matrix and cell as tech-speak synonyms for groups of expressions, but NO, he meant really matrices and cells ..., stupid me!).
As far as I understand GCD code is not any worse in this regard (that said, it's not any better either). I might be wrong (I'm just a human being), so I'd be grateful if someone could point out any non-reentrant code in GCD routines.
Well, someone says: you have static variables inside functions there. A thread-switch might occur during the construction, I guess. Regards, Jens
Hello, On Sun, Jun 13, 2010 at 08:37:20PM +0200, Jens Vollinga wrote:
As far as I understand GCD code is not any worse in this regard (that said, it's not any better either). I might be wrong (I'm just a human being), so I'd be grateful if someone could point out any non-reentrant code in GCD routines.
Well, someone says: you have static variables inside functions there.
Could you please be more specific? I can see several static const variables, for instance, static const int immediate_bits = 8*sizeof(void *) - __alignof__(void *); but most likely GCC will eliminate these at the compile time. Best regards, Alexei
Hi! Am 13.06.2010 21:07, schrieb Alexei Sheplyakov:
Could you please be more specific? I can see several static const variables, for instance,
like in primpart_content.cpp 44 void primpart_content(ex& pp, ex& c, ex e, const exvector& vars, 45 const long p) 46 { 47 static const ex ex1(1); 48 static const ex ex0(0); Regards, Jens
Hi! Jens Vollinga wrote:
Am 13.06.2010 21:07, schrieb Alexei Sheplyakov:
Could you please be more specific? I can see several static const variables, for instance,
like in primpart_content.cpp
44 void primpart_content(ex& pp, ex& c, ex e, const exvector& vars, 45 const long p) 46 { 47 static const ex ex1(1); 48 static const ex ex0(0);
Is there a reason why this code isn't using the flyweights from utils.cpp directly? And, could these flyweights be safe in a threaded environment? I would assume no thread ever deallocates them since their refcount stays above zero all the time. Wrong? Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! Am 13.06.2010 23:04, schrieb Richard B. Kreckel:
44 void primpart_content(ex& pp, ex& c, ex e, const exvector& vars, 45 const long p) 46 { 47 static const ex ex1(1); 48 static const ex ex0(0);
Is there a reason why this code isn't using the flyweights from utils.cpp directly? And, could these flyweights be safe in a threaded
Alexei should know.
environment? I would assume no thread ever deallocates them since their refcount stays above zero all the time. Wrong?
Yes, they should be safe for the reasons you gave. Regards, Jens
i would to clear a little! the expressions are independant from each thread, exp1 = x*y+.... exp2 = x+x+x+x... exp3 = y+y*y+3... .. .. expn = just_symbols.. no subexpressions never. when i wrote point 4), i meant that the matrix is where these expressions go, each thread puts its expression in a unique cell. its just as you first though Jens, Cristobal <http://www.youtube.com/neoideo> On Sun, Jun 13, 2010 at 2:37 PM, Jens Vollinga <jensv@nikhef.nl> wrote:
Hi!
Am 13.06.2010 20:05, schrieb Alexei Sheplyakov:
4) threads access the same common matrix of expressions, but two threads
will never access the same cell.
This does NOT guarantee that you (or GiNaC on your behalf) won't operate on a same (sub)expression from different threads. You *really* need a thread safe (or atomic) reference counting to solve this problem.
ah, now I see why we keep arguing: I misread point 4 completely!!! I thought he meant to have a clear the separation of expressions between threads (matrix and cell as tech-speak synonyms for groups of expressions, but NO, he meant really matrices and cells ..., stupid me!).
As far as I understand GCD code is not any worse in this regard (that
said, it's not any better either). I might be wrong (I'm just a human being), so I'd be grateful if someone could point out any non-reentrant code in GCD routines.
Well, someone says: you have static variables inside functions there. A thread-switch might occur during the construction, I guess.
Regards, Jens
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Hello, On Sun, Jun 13, 2010 at 03:44:13PM -0400, Cristobal Navarro wrote:
i would to clear a little!
the expressions are independant from each thread,
exp1 = x*y+....
exp2 = x+x+x+x...
exp3 = y+y*y+3... .. .. expn = just_symbols..
no subexpressions never.
You can't know that for sure. Expression sharing is completely transparent for the user, it might be a side effect of some computation (i.e. calculating the derivative of a product, comparing two expressions, etc). Best regards, Alexei
Hello ginac friends we known ginac is not thread safe, but it should be process safe, for exmaple for openMPI usage right? On Mon, Jun 14, 2010 at 1:12 AM, Alexei Sheplyakov <alexei.sheplyakov@gmail.com> wrote:
Hello,
On Sun, Jun 13, 2010 at 03:44:13PM -0400, Cristobal Navarro wrote:
i would to clear a little!
the expressions are independant from each thread,
exp1 = x*y+....
exp2 = x+x+x+x...
exp3 = y+y*y+3... .. .. expn = just_symbols..
no subexpressions never.
You can't know that for sure. Expression sharing is completely transparent for the user, it might be a side effect of some computation (i.e. calculating the derivative of a product, comparing two expressions, etc).
Best regards, Alexei
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Hello Cristobal, i am using OpenMPI with GiNaC and it works for me without issues. Best regards Martin -------- Original-Nachricht --------
Datum: Mon, 26 Jul 2010 12:07:01 -0400 Von: Cristobal Navarro <axischire@gmail.com> An: GiNaC discussion list <ginac-list@ginac.de> Betreff: Re: [GiNaC-list] is ginac thread safe for this case?
Hello ginac friends we known ginac is not thread safe, but it should be process safe, for exmaple for openMPI usage right?
Hello,
On Sun, Jun 13, 2010 at 03:44:13PM -0400, Cristobal Navarro wrote:
i would to clear a little!
the expressions are independant from each thread,
exp1 = x*y+....
exp2 = x+x+x+x...
exp3 = y+y*y+3... .. .. expn = just_symbols..
no subexpressions never.
You can't know that for sure. Expression sharing is completely
On Mon, Jun 14, 2010 at 1:12 AM, Alexei Sheplyakov <alexei.sheplyakov@gmail.com> wrote: transparent
for the user, it might be a side effect of some computation (i.e. calculating the derivative of a product, comparing two expressions, etc).
Best regards, Alexei
_______________________________________________ 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
-- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Thanks, this is very useful best regards Cristobal On Mon, Jul 26, 2010 at 12:13 PM, Martin Ettl <ettl.martin@gmx.de> wrote:
Hello Cristobal,
i am using OpenMPI with GiNaC and it works for me without issues.
Best regards
Martin
-------- Original-Nachricht --------
Datum: Mon, 26 Jul 2010 12:07:01 -0400 Von: Cristobal Navarro <axischire@gmail.com> An: GiNaC discussion list <ginac-list@ginac.de> Betreff: Re: [GiNaC-list] is ginac thread safe for this case?
Hello ginac friends we known ginac is not thread safe, but it should be process safe, for exmaple for openMPI usage right?
Hello,
On Sun, Jun 13, 2010 at 03:44:13PM -0400, Cristobal Navarro wrote:
i would to clear a little!
the expressions are independant from each thread,
exp1 = x*y+....
exp2 = x+x+x+x...
exp3 = y+y*y+3... .. .. expn = just_symbols..
no subexpressions never.
You can't know that for sure. Expression sharing is completely
On Mon, Jun 14, 2010 at 1:12 AM, Alexei Sheplyakov <alexei.sheplyakov@gmail.com> wrote: transparent
for the user, it might be a side effect of some computation (i.e. calculating the derivative of a product, comparing two expressions, etc).
Best regards, Alexei
_______________________________________________ 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
-- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl _______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
participants (5)
-
Alexei Sheplyakov
-
Cristobal Navarro
-
Jens Vollinga
-
Martin Ettl
-
Richard B. Kreckel