- cmsg cancel <noqhv6$cec$2@dont-email.me> - 6 Updates
- I will add more about Transactional memory... - 1 Update
- He is my final words about Transactional memory... - 1 Update
- But there is still another big problem with Transactional memory.. - 1 Update
- Read again... - 1 Update
- I must be precise - 1 Update
- About Transactional memory - 1 Update
| bleachbot <bleachbot@httrack.com>: Aug 14 09:48PM +0200 |
| bleachbot <bleachbot@httrack.com>: Aug 14 10:21PM +0200 |
| bleachbot <bleachbot@httrack.com>: Aug 14 10:22PM +0200 |
| bleachbot <bleachbot@httrack.com>: Aug 14 10:41PM +0200 |
| bleachbot <bleachbot@httrack.com>: Aug 14 11:17PM +0200 |
| bleachbot <bleachbot@httrack.com>: Aug 14 11:50PM +0200 |
| Ramine <ramine@1.1>: Aug 14 05:51PM -0400 Hello, I will add more about Transactional memory... From my previous logical inference i have said that: To get more safety on Transactional memory, transactions must wrap the parallel part and the serial part, and this will get you less performance than locks, now the important question is since transactions conflicts are probabilistic and i have also said on my previous logical inference that if the serial part get more bigger so you will have more chance to get conflicts and this will get you poor performance, so from my logical inference, how can we guaranty a latency and throughput that is decent with Transactional memory ? i think that since with Transactional memory we can not do calculations that guaranty a more decent performance, so Transactional memory is not good especially for realtime critical systems even though transactional memory avoids race conditions and deadlocks and is then good on composability. So from my logical inference, that means that Transactional memory is not the silver bullet, and locks are more suited for performance than Transactional memory. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Aug 14 05:18PM -0400 Hello, He is my final words about Transactional memory... As you have seen me reasonning more precisely about Transactional memory , i hope you have get my ideas about it, so here is more clearly my final words about Transactional memory: 1- Transactional memory have good characteristic on the safety side, since it avoid race conditions and deadlocks, so then it is best suited for composability. 2- But Transactional memory is poorer on performance than Locks, beacause if the serial part is more bigger you will get more chance to get conflicts, but since transactions must wrap the serial part and the parallel part to get more safety and avoids race conditions, so the Transactional memory is not best suited on the performance characteristic, i think that Locks are faster and this has surfaced clearly from my logical inference of this post and my previous posts. 3- So from [2] above, Transactional memory is not best suited for realtime critical systems when you want to guaranty a decent performance that locks can guaranty, so locks are the best on the performance characteristic. Hope you have followed my reasonning and my logical inference and you have understood them well. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Aug 14 04:42PM -0400 Hello, You have seen me in my previous post reasonning about Trasactional memory.. But there is still another big problem with Transactional memory.. The problem is with realtime critical systems, to be able to use Transactional memory in realtime crtitical systems, you have to be able to calculate precisely the latency and the throghuput, but since in transactional memory you can get conflicts that can get you in the worst case performances that are not good, so transactional memory is not best suited for realtime critical systems that wants to optimise more the performance and guaranty a scaling that is decent, so here comes again the way of locks that can get you a more decent performance with a more predictable performance that scales more, so locks are best suited for realtime critical systems when the characteristic of performance is taken alone. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Aug 14 04:23PM -0400 Hello..... I must be precise in my reasonning about Transactional memory.. To avoid race conditions the transactions must wrap the parallel part and the serial part. And if the serial part of the transactions is more smaller you can get a conflict and this will get you a poor performance. But if the serial part is small , so the chance to get a conflict is small, so Transactional memory works best and scales best with smaller serial parts. So Transactional memory since it avoids race conditions and deadlocks is the right tool for applications that scales well and that have smaller serial parts. Locks are best suited for more bigger serial parts. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Aug 14 04:21PM -0400 Hello, I must be precise in my reasonning about Transactional memory.. To avoid race conditions the transactions must wrap the parallel part and the serial part. And if the serial part of the transactions is more smaller you can get a conflict and this will get you a poor performance. But if the serial part is small , so the chance to get a conflict is small, so Trasactional memory work best and scale best with smaller serial parts. So Transactional memory since it avoids race conditions and deadlocks is the right tool for applications that scales well and that have smaller serial parts. Locks are best suited for more bigger serial parts. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Aug 14 03:49PM -0400 Hello, I have read that Transactional memory avoids race conditions and deadlock etc. But i have thought about Transactional memory and i think there is a big problem with it, because if you want to avoid race conditions, the transaction must wrap a bigger part including the parallel part and the serial part, but this way has its big problem and is not good, because if there is a conflict on the serial part, the transactions will roolback and will be run serially and this will get you a poor performance that look like the serial performance, but to avoid this big problem with transactional memory you have to make the transaction small and avoids to include a maximum of the parallel part, but this way is a big problem and is not good, because you can risk to include race conditions that will ressemble the problem that you get with the way of using locks. So transactional memory in my humble opinion is not the right tool. Thank you, Amine Moulay Ramdane. |
| 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.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment