Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #2761

An Architect way of thinking on parallel programming

From Ramine <ramine@1.1>
Newsgroups comp.programming.threads
Subject An Architect way of thinking on parallel programming
Date 2014-12-07 17:26 -0800
Organization A noiseless patient Spider
Message-ID <m62k4k$r83$2@dont-email.me> (permalink)

Show all headers | View raw


Hello,


This time since i have mastered to a certain level the
reader-writer algorithms, i will this time think as
an architect on parallel programming to show you something important, 
here it is:

As you have seen me talking on my previous post, i have
said that with the client-server mechanism that i have given you
before , we can eliminate the lock synchronization mechanism from
the writer side, and we can make the writer side very very cheap in term 
of running time compared to the reader section, so there is a very 
important question that we can ask then, does transactional
memory, hardware or sofotware, will buy you much when designing a 
client-server parallel in-memory database or an client server parallel 
AVL tree or a client server parallel Red black tree ? i think
it will not buy you much in term of runnning time, because
with the client-server technic that i have given you above
and that eliminates the lock synchronization from the writer side
of the reader-writer algorithm , this will make the writer
side very cheap in term of running time compared to
the reader section that will be expensive in this scenario,
because as i have said before is this: What i like about my scalable 
distributed sequential lock, is that if for example you want to 
implement a really fast and parallel in-memory database or a Parallel 
Redblack tree and a parallel AVL tree, the reader section will be much 
expensive than the writer section, cause in the writer side you first 
write the data outside the writer section and inside the writer
section you just copy your pointer to the datastructure,
but in the reader section you have to read the data
from the memory from inside the reader section , that makes
the reader section more expensive , so from the Amdahl's
law this will make the parallel in-memory database
that uses my scalable distributed sequential lock to
scale very well(on NUMA etc.) or it will make the the parallel Redblack 
tree or parallel AVL tree that use my scalable distributed sequential 
lock to scale very well (on NUMA etc.).


Hope you have understood my way of thinking like as an architect on 
parallel programming...



Thank you,
Amine Moulay Ramdane.







Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread


Thread

An Architect way of thinking on parallel programming Ramine <ramine@1.1> - 2014-12-07 17:26 -0800

csiph-web