documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's comi ng.
It seems that you meant '*HPC* multicore programming'. Do you have anything for development of smart clients, or servers, systems programming, middleware etc?
Dmitriy V'jukov
On Sep 12, 3:09 pm, "cynko" <sie...@bugs.com> wrote:
documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's comi ng.
It seems that you meant '*HPC* multicore programming'. Do you have
anything for development of smart clients, or servers, systems
programming, middleware etc?
documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's comi ng.
It seems that you meant '*HPC* multicore programming'. Do you have anything for development of smart clients, or servers, systems programming, middleware etc?
Dmitriy V'jukov
cynko
from the website - I think this is broader than traditional HPC:
"Cilk++ is best suited for applications that meet the following criteria:
1.. Application performance is compute bound 2.. Performance can be improved by accelerating serial (i.e., single-threaded) portions of the application"
"Dmitriy V'jukov" wrote in message news: On Sep 12, 3:09 pm, "cynko" wrote:
documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's coming.
It seems that you meant '*HPC* multicore programming'. Do you have anything for development of smart clients, or servers, systems programming, middleware etc?
Dmitriy V'jukov
from the website - I think this is broader than traditional HPC:
"Cilk++ is best suited for applications that meet the following criteria:
1.. Application performance is compute bound
2.. Performance can be improved by accelerating serial (i.e.,
single-threaded) portions of the application"
"Dmitriy V'jukov" <dvyukov@gmail.com> wrote in message
news:2dbe1f7f-10dd-4669-a2e6-24ab5d85aa75@r66g2000hsg.googlegroups.com...
On Sep 12, 3:09 pm, "cynko" <sie...@bugs.com> wrote:
documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's
coming.
It seems that you meant '*HPC* multicore programming'. Do you have
anything for development of smart clients, or servers, systems
programming, middleware etc?
from the website - I think this is broader than traditional HPC:
"Cilk++ is best suited for applications that meet the following criteria:
1.. Application performance is compute bound 2.. Performance can be improved by accelerating serial (i.e., single-threaded) portions of the application"
"Dmitriy V'jukov" wrote in message news: On Sep 12, 3:09 pm, "cynko" wrote:
documentation, code samples, training materials for developers
Cilk++ ships in several months, but the above is a preview of what's coming.
It seems that you meant '*HPC* multicore programming'. Do you have anything for development of smart clients, or servers, systems programming, middleware etc?
"Chris M. Thomasson" wrote in message news:07KAk.13389$
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
Chris M. Thomasson
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:07KAk.13389$
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
"gremlin" <gremlin@rosetattoo.com> wrote in message
news:3ZKdnYgjZ86LMELVnZ2dnUVZ_vudnZ2d@comcast.com...
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:07KAk.13389$rV4.12375@newsfe03.iad...
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for
the atomic deques? There are several algorihtms out there, but I am
interested in which one Clik uses. Is it the ABP algorithm? Which one is it?
Thanks for your time and help.
"Chris M. Thomasson" wrote in message news:07KAk.13389$
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Chris M. Thomasson
"Chris M. Thomasson" wrote in message news:FsSDk.4177$
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:07KAk.13389$
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:FsSDk.4177$Bt7.3082@newsfe13.iad...
"gremlin" <gremlin@rosetattoo.com> wrote in message
news:3ZKdnYgjZ86LMELVnZ2dnUVZ_vudnZ2d@comcast.com...
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:07KAk.13389$rV4.12375@newsfe03.iad...
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for
the atomic deques? There are several algorihtms out there, but I am
interested in which one Clik uses. Is it the ABP algorithm? Which one is
it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
"Chris M. Thomasson" wrote in message news:FsSDk.4177$
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:07KAk.13389$
What work-stealing algorithm are you using?
http://en.wikipedia.org/wiki/Cilk#Work-stealing
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
gremlin
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
TBB is based on MIT's Cilk work: http://www.cilk.com/multicore-blog/bid/5607/Cilk-Wins-Most-Influential-PLDI-Paper-Award
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:JuSDk.4178$Bt7.1444@newsfe13.iad...
I am missing something here. Can you point me to the actual algorithm for
the atomic deques? There are several algorihtms out there, but I am
interested in which one Clik uses. Is it the ABP algorithm? Which one is
it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
TBB is based on MIT's Cilk work: http://www.cilk.com/multicore-blog/bid/5607/Cilk-Wins-Most-Influential-PLDI-Paper-Award
Chris M. Thomasson
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details... AFAICT, this work from SUN would scale better than Clik. Please correct me if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an impl to focus on... Say, DEC Alpha?
"gremlin" <gremlin@rosetattoo.com> wrote in message
news:Mfedna7lC4LpIn3VnZ2dnUVZ_oWdnZ2d@comcast.com...
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:JuSDk.4178$Bt7.1444@newsfe13.iad...
I am missing something here. Can you point me to the actual algorithm
for the atomic deques? There are several algorihtms out there, but I am
interested in which one Clik uses. Is it the ABP algorithm? Which one is
it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details...
AFAICT, this work from SUN would scale better than Clik. Please correct me
if I am way off base here. It seems like spawning a successor thread has
overheads... Humm. Pleas try to bear with me here; okay? Correct my
ignorance on Clik's work-stealing internal impl... Well, let me pick an impl
to focus on... Say, DEC Alpha?
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details... AFAICT, this work from SUN would scale better than Clik. Please correct me if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an impl to focus on... Say, DEC Alpha?
Chris M. Thomasson
"Chris M. Thomasson" wrote in message news:BG3Ek.354$
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details... AFAICT, this work from SUN would scale better than Clik. Please correct me if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an impl to focus on... Say, DEC Alpha?
BTW, here is my "fairly" detailed analysis on the inner-workings of SUN's atomic deque algorithm:
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:BG3Ek.354$YN3.47@newsfe08.iad...
"gremlin" <gremlin@rosetattoo.com> wrote in message
news:Mfedna7lC4LpIn3VnZ2dnUVZ_oWdnZ2d@comcast.com...
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:JuSDk.4178$Bt7.1444@newsfe13.iad...
I am missing something here. Can you point me to the actual algorithm
for the atomic deques? There are several algorihtms out there, but I am
interested in which one Clik uses. Is it the ABP algorithm? Which one
is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details...
AFAICT, this work from SUN would scale better than Clik. Please correct me
if I am way off base here. It seems like spawning a successor thread has
overheads... Humm. Pleas try to bear with me here; okay? Correct my
ignorance on Clik's work-stealing internal impl... Well, let me pick an
impl to focus on... Say, DEC Alpha?
BTW, here is my "fairly" detailed analysis on the inner-workings of SUN's
atomic deque algorithm:
"Chris M. Thomasson" wrote in message news:BG3Ek.354$
"gremlin" wrote in message news:
"Chris M. Thomasson" wrote in message news:JuSDk.4178$
I am missing something here. Can you point me to the actual algorithm for the atomic deques? There are several algorihtms out there, but I am interested in which one Clik uses. Is it the ABP algorithm? Which one is it? Thanks for your time and help.
Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details... AFAICT, this work from SUN would scale better than Clik. Please correct me if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an impl to focus on... Say, DEC Alpha?
BTW, here is my "fairly" detailed analysis on the inner-workings of SUN's atomic deque algorithm:
I am looking for raw pseudo-code for atomic deque internal impl details.. . AFAICT, this work from SUN would scale better than Clik. Please correct m e if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an i mpl to focus on... Say, DEC Alpha?
AFAIK, in early days Cilk's work-stealing deque used mutex-based pop(). But I remember there was some mentions of non-blocking algorithms in the Cilk's papers, something like "some people point us that it's possible to implement work-stealing deque in completely non- blocking manner". And I don't know whether non-blocking deque was finally incorporated into Cilk.
If mutex is spin-mutex (i.e. there is only 1 atomic RMW per lock/ unlock) and stealing is rare, then mutex-based deque is nearly the same as non-blocking deque with 1 RMW... provided that push() doesn't use mutex. And provided that atomic RMW has the same cost as StoreLoad memory fence (x86).
Dmitriy V'jukov
On Sep 29, 4:23 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>> Are you using something like the algorithm in TBB?
I am looking for raw pseudo-code for atomic deque internal impl details.. .
AFAICT, this work from SUN would scale better than Clik. Please correct m e
if I am way off base here. It seems like spawning a successor thread has
overheads... Humm. Pleas try to bear with me here; okay? Correct my
ignorance on Clik's work-stealing internal impl... Well, let me pick an i mpl
to focus on... Say, DEC Alpha?
AFAIK, in early days Cilk's work-stealing deque used mutex-based
pop(). But I remember there was some mentions of non-blocking
algorithms in the Cilk's papers, something like "some people point us
that it's possible to implement work-stealing deque in completely non-
blocking manner". And I don't know whether non-blocking deque was
finally incorporated into Cilk.
If mutex is spin-mutex (i.e. there is only 1 atomic RMW per lock/
unlock) and stealing is rare, then mutex-based deque is nearly the
same as non-blocking deque with 1 RMW... provided that push() doesn't
use mutex. And provided that atomic RMW has the same cost as StoreLoad
memory fence (x86).
I am looking for raw pseudo-code for atomic deque internal impl details.. . AFAICT, this work from SUN would scale better than Clik. Please correct m e if I am way off base here. It seems like spawning a successor thread has overheads... Humm. Pleas try to bear with me here; okay? Correct my ignorance on Clik's work-stealing internal impl... Well, let me pick an i mpl to focus on... Say, DEC Alpha?
AFAIK, in early days Cilk's work-stealing deque used mutex-based pop(). But I remember there was some mentions of non-blocking algorithms in the Cilk's papers, something like "some people point us that it's possible to implement work-stealing deque in completely non- blocking manner". And I don't know whether non-blocking deque was finally incorporated into Cilk.
If mutex is spin-mutex (i.e. there is only 1 atomic RMW per lock/ unlock) and stealing is rare, then mutex-based deque is nearly the same as non-blocking deque with 1 RMW... provided that push() doesn't use mutex. And provided that atomic RMW has the same cost as StoreLoad memory fence (x86).