- A beautiful music now - 1 Update
- cmsg cancel <me9i81$fqo$2@dont-email.me> - 8 Updates
- Finally read more... - 1 Update
- Please reread... - 1 Update
- Finally i have understood... - 1 Update
- We must think more... - 1 Update
- We Are safe... - 1 Update
- Scalability prediction - 2 Updates
- Ejemplo de Acceso - 1 Update
| Ramine <ramine@1.1>: Mar 17 05:58PM -0700 Hello, Finally since i have explained to you important subjects in my previous posts... I want now to share with you this beautiful music of Strunz and Farah... https://www.youtube.com/watch?v=_LT5zt16zsw&list=PLUmK305_M0Y34uLM3BZJNUz9PGWsM4aFx Thank you, Amine Moulay Ramdane. |
| bleachbot <bleachbot@httrack.com>: Mar 17 04:46PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 06:24PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 07:23PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 08:03PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 10:02PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 10:03PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 10:42PM +0100 |
| bleachbot <bleachbot@httrack.com>: Mar 17 10:52PM +0100 |
| Ramine <ramine@1.1>: Mar 17 05:48PM -0700 Hello, As you have seen me talking in my previous post, i have explained to you a very important thing, but we have to be smarter than that to be able to see clearly the overall picture, as you have noticed researchers are inventing transactional memory, but transactional memory and my SeqlockX are optimistic mechanisms, this means that you can not always use transactional memory in a high level way, for example with AVL trees and Red-black trees and Skiplists, transactional memory can not be used in a high level way because the writers can modify the pointers and this can raise exceptions inside the readers and inside writers, and you can not do it from high level around the insert() and search() and delete() because you have to respect the logic of the sequential algorithms, that's the same with my SeqlockX, you have to use them in this situation in a finer grained manner from inside the insert() and delete() and search() of the algorithms... this is the problem with optimistic mechanisms of transactional memory and my SeqlockX and SMR and RCU have the same problem... but with the scalable reader-writer locks you can reason in a high level manner and put the Rlock() RUnlock() and WLock() and WUnlock() in a straight forward manner around the insert() and search() and delete() of the AVL tree or Red-Black tree or the Skiplist, that's the advantage with scalable read-writer locks. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 05:10PM -0700 Hello... Finally i think i have understood something very important... Because i have just read more PhD papers about concurrent datastructures, and i have finally understood something very important, what you have seen me doing in my previous post is trying to use my scalable SeqlockX in a high level manner, but that's not the way it works and that's not the way it works with SMR or RCU or with Transactional memory, with transactional memory you can not just put brackets of the transactions around the transactions of the insert() and delete() and search() methods of the AVL tree or Red-Black tree or Skiplists to make them concurrent, that's not the way it works, you have to reason from inside the datastructures algorithms and use the transactions in a finer grained manner, so this means that my scalable SeqlockX algorithm is really a powerful algorithm, but how can you use scalable SeqlockX to design a scalable AVL tree or scalable Red-Black tree or a scalable Skiplists on read-mostly workloads ? that's the same way as RCU is used or SMR is used or Transactional memory is used, you can not wrap the reader section and writer section with a RLock() and RUnlock() and Wlock() Wunlock(), instead you have to do it a finer grained manner from inside the algorithms around the memory parts like pointers or arrays or structs , that's the way it works with my scalable SeqlockX and that's the way it works with SMR and RCU and transactional memory. So finally my scalable SeqlockX is really a powerful mechanism that is smart and useful, so finally i can also say that my scalable SeqlockX can replace RCU and replace SMR. You can download my scalable SeqlockX from: https://sites.google.com/site/aminer68/scalable-seqlockx Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 05:09PM -0700 Hello, Finally i think i have undertood somethinbg very important... Because i have just read more PhD papers about concurrent datastructures, and i have finally understood something very important, what you have seen me doing in my previous post is trying to use my scalable SeqlockX in a high level manner, but that's not the way it works and that's not the way it works with SMR or RCU or with Transactional memory, with transactional memory you can not just put brackets of the transactions around the transactions of the insert() and delete() and search() methods of the AVL tree or Red-Black tree or Skiplists to make them concurrent, that's not the way it works, you have to reason from inside the datastructures algorithms and use the transactions in a finer grained manner, so this means that my scalable SeqlockX algorithm is really a powerful algorithm, but how can you use scalable SeqlockX to design a scalable AVL tree or scalable Red-Black tree or a scalable Skiplists on read-mostly workloads ? that's the same way as RCU is used or SMR is used or Transactional memory is used, you can not wrap the reader section and writer section with a RLock() and RUnlock() and Wlock() Wunlock(), instead you have to do it a finer grained manner from inside the algorithms around the memory parts like pointers or arrays or structs , that's the way it works with my scalable SeqlockX and that's the way it works with SMR and RCU and transactional memory. So finally my scalable SeqlockX is really a powerful mechanism that is smart and useful, so finally i can also say that my scalable SeqlockX can replace RCU and replace SMR. You can download my scalable SeqlockX from: https://sites.google.com/site/aminer68/scalable-seqlockx Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 03:10PM -0700 Hello, We must think more... I have just done a scalability prediction for this StringList datastructure using my SeqlockX on read-mostly scenarios and i have found that it doesn't scale at all, because StringList is an array using binary search, and for an array of 1000000 elements , in the average case time complexity, let say it for each insert() it will move 500000 elements, on an x64 architecture this will generate 62500 cache-misses, because on every 8 pointers we will have a cache-miss, and those cache misses are expensive, on the search() side you will have a log(n) time complexity so this will be much much less expensive than the insert() and the delete() sides, so from the Amdhal's law this will not scale because the serial part is much much expensive than the parallel part. So this StringList will not scale on read-mostly scenarios. So the only alternative is to use the Distributed reader-writer mutex with an AVL tree or Red-black tree or a Skiplist this will give you 50X scalability on multicore for smaller data corresponding to each key, and this will give you much more than 50X scalability on multicores for bigger data corresponding to each key, or you can use RCU. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 02:29PM -0700 Hello, I think we are safe, i have talked about my SeqlockX that is a variant of Seqlock that eliminates livelock on the readers side when there is many writers, and you have seen me thinking and thinking , what i have tried to do is resumed on the following question: how to implement something that looks like an concurrent AVL tree or concurrent Red Black tree or concurrent Skiplist that scales on read-mostly scenarios without the need of RCU ? as you have seen me talking before i have said that Seqlock can not be used with datastructures that use pointers, because SeqLOCK is using an optimistic synchronization mechanism on the reader side, and since the writer side can modify the pointers, so the reader side can have serious problems , so we have to forgot using Seqlock with datastructures such as AVL trees or Red-Black trees or Skiplists, so how then can we elevate this contraint and problem ? i am using Delphi and FreePascal, and on Delphi and Freepascal there is a datastructure called "StringList", it is an array based datastructure that uses a binary search to maintain a sorted array etc. and this datastructure can be used with my SeqlockX and it will give the same characteristics and performance as an AVL tree or Red Black tree or Skiplist on "read-mostly" scenarios, so this idea of using this sort of datastructure has resolved the problem, so no need to use RCU , my SeqlockX will do perfectly the job and you will get fantastic results and it will perfectly scale this datastructure such us StringList on read-mostly scenarios on multicores ! Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 11:52AM -0700 Hello, I have done a scalability prediction for a concurrent AVL tree that uses the following Distributed reader-writer mutex: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Since the GetCurrentProcessorNumber() function that is used by the distributed reader-writer mutex is parallelized on multicores, and since the LockedExchangeAdd() of my LW_RWlockX that is used by the distributed reader-writer mutex is taking few CPU cycles, so i have done a scalability prediction for a concurrent AVL tree that uses keys as strings using this distributed reader-writer mutex and it has given 50X speedup on multicores, you will get 50x if the data corresponding to each key is small, but if the data corresponding to each key is bigger you will get much more speedup than 50X on multicores. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Mar 17 01:30PM -0700 Hello, This scalability prediction was done for read-mostly workloads. Thank you, Amine Moulay Ramdane. On 3/17/2015 11:52 AM, Ramine wrote: |
| ramon.rosado@devoteam.com: Mar 17 06:13AM -0700 Esta es la explicaion !!!! |
| 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