From: Amitha P. <ami...@us...> - 2007-12-11 18:49:40
|
Folks, I find myself doing more threading with vxl code. I think it makes sense to bring in pieces of boost into vxl to support this. (For example, multi-threading in vgui to make the GUI not hang on long computations.) So, I'd like to propose that pieces of boost be brought into v3p. (Not all of boost, because it is huge, and most of it will not be useful for vxl.) In particular, I suggest - Boost.Thread - Boost.SmartPtr - Boost.Bind - Boost.Function The v3p version of Boost will be modified to build via CMake, instead of Boost's jam, so the user will not see any major impact. Of course, it should always be possible to use an external version of boost instead of the v3p version. Thoughts? Amitha. |
From: Matt L. <mat...@gm...> - 2007-12-11 19:13:55
|
Amitha, I am all for this! Lately I've been wondering about the best way to get cross platform threading support into VXL. Just yesterday I was looking around to see what kind of cross platform thread library might be used in VXL. If you think Boost is the best way to do this, then I support that decision. vgui will be the first to benefit from this as you point out, but I've also been itching to take advantage of my multicore CPU for computations that are "embarrassingly parallel". I know this opens up a whole new can of worms relating to the thread safety of VXL, but we can't ignore this forever. Let me know if I can help with this in any way. --Matt On Dec 11, 2007 1:49 PM, Amitha Perera <ami...@us...> wrote: > Folks, > > I find myself doing more threading with vxl code. I think it makes > sense to bring in pieces of boost into vxl to support this. (For > example, multi-threading in vgui to make the GUI not hang on long > computations.) > > So, I'd like to propose that pieces of boost be brought into v3p. (Not > all of boost, because it is huge, and most of it will not be useful for > vxl.) In particular, I suggest > - Boost.Thread > - Boost.SmartPtr > - Boost.Bind > - Boost.Function > > The v3p version of Boost will be modified to build via CMake, instead of > Boost's jam, so the user will not see any major impact. > > Of course, it should always be possible to use an external version of > boost instead of the v3p version. > > Thoughts? > > Amitha. > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <ami...@us...> - 2007-12-11 19:27:03
|
I'm not sure that Boost.Threads are the best way to do threading in C++. I'm certainly open to other multi-platform ways of doing it. (An option is to roll our own, but sometimes it's good to build on others' work...) Even if we use boost threads, it may be worthwhile to wrap it into our own threading library, because our needs will diverge. [Specific example below.] Wrapping also has the advantage of swapping out boost threads for something else if the need arises. That said, we should probably be using more of boost in general, and so it makes some sense to just use their threading too. BTW, for the embarrassingly parallel code, it may make sense to leverage something like OpenMP. Later versions of GCC and MSVC all support OpenMP. Post more thoughts. Maybe after a couple of days, the interested parties can form a small working group to hash out the details. [Possible example of the need to wrap: in much of the threading code that I've written, I assume that writing a 32-bit int is atomic. This is true on the Intel architecure, AFAIK, but won't be true in general. If we were to write our own threading library, we could provide, e.g. atomic<int> that guarantees atomic functions, implemented as efficiently as possible on that platform.] Amitha. |
From: Matt L. <mat...@gm...> - 2007-12-11 20:07:05
|
For the record, I did come across this other cross platform thread library: http://openthreads.sourceforge.net/ I don't know much about it (or about Boost for that matter). It might be worth looking into. OpenMP also sounds like a good idea, but I'm worried that it is a little too close to the cutting edge for VXL. After a quick check it looks like OpenMP was supported starting with GCC 4.2 and MSVC 2005 (I'm not sure about other compilers). It would be nice to find a way to slowly bring support for this into VXL as well. Any ideas about this? --Matt On Dec 11, 2007 2:26 PM, Amitha Perera <ami...@us...> wrote: > I'm not sure that Boost.Threads are the best way to do threading in C++. > I'm certainly open to other multi-platform ways of doing it. (An > option is to roll our own, but sometimes it's good to build on others' > work...) > > Even if we use boost threads, it may be worthwhile to wrap it into our > own threading library, because our needs will diverge. [Specific > example below.] Wrapping also has the advantage of swapping out boost > threads for something else if the need arises. > > That said, we should probably be using more of boost in general, and so > it makes some sense to just use their threading too. > > BTW, for the embarrassingly parallel code, it may make sense to leverage > something like OpenMP. Later versions of GCC and MSVC all support OpenMP. > > Post more thoughts. Maybe after a couple of days, the interested > parties can form a small working group to hash out the details. > > > [Possible example of the need to wrap: in much of the threading code > that I've written, I assume that writing a 32-bit int is atomic. This > is true on the Intel architecure, AFAIK, but won't be true in general. > If we were to write our own threading library, we could provide, e.g. > atomic<int> that guarantees atomic functions, implemented as efficiently > as possible on that platform.] > > > Amitha. > |
From: Ian S. <ian...@st...> - 2007-12-12 11:14:59
|
Hi all For the past year, I have been evaluating various approaches to threading with a view to picking one consistent approach for all of Imorphics' internal code. In particular I have been worried about the likely exponential growth in the number of cores available, and how we efficiently and scalably use them. We already have compute servers with 8 cores per machine, and we are right at the edge of efficiently splitting our embarrassingly parallel problems. IO bandwidth constraints mean that we will have to get multiple cores working on the same data fairly soon. Now for the bad news: I believe that all the threading code in Boost is at too low a level for VXL's purposes. I do not want to be using threads and locks, in particular because lock-based threading is not composable*. Using locks means that I have to take an overview of all locks when I do any lock-based programming. This is particularly hard with a library like VXL where we try to impose as few constraints on the users as possible. * Composability is the property of programs A and program B which have no explicit interactions, such that when I join them to make program C, the effect should be that of A + B. We have all been relying on the straightforward composability of our code possibly without realising it. Locking and contention for similar resources can easily but quietly introduce hidden interdependencies between A & B such that C will deadlock or suffer from race conditions even though A & B are individually correct. There are ways around this (e.g. introduce a global lock-hierarchy) but they impose significant constraints on users - constraints that may not be compatible with other libraries. Imorphics and Manchester University heavily use the Strategy pattern (the run-time polymorphism of high-level algorithms). We deliberately write code that calls functions some derivations of which might not be written for a few years, and for which any interdependence is restricted to that explicitly enforced by the signature of the base-class API. Introducing locks could blow those carefully maintained contracts. More recently I have been looking at Intel's thread building block library http://threadingbuildingblocks.org/ and I am much more impressed by that. For C++ programmers it appears more powerful than OpenMP. In particular it can handle multiply nested threading directives - so maintaining composability. There are some interesting ideas using Futures and Active Objects in one of boost vault libraries http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming/Active%20Objects however it isn't clear to me how much traction these libraries have. A similar proposal for C++0x http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html appears close to being cut in the face of looming deadlines. Now, threading for GUI responsiveness and threading for the efficient use of multi-core machines may require different approaches, and it might be possible to use both as appropriate. However, I think we should avoid any approach that requires VXL to handle locks, mutexes, semaphones, etc. unless it can be shown that they and the resources they protect will remain independent of any other reasonable part of the same application. Assuming we go ahead, do you have a proposal for how to integrate boost threads? Are we going to VXL-ify it? In particular are we going to remove the namespace support, etc. Alternatively we could treat is as an early version of the similar c++0x extension, so it could migrate into vcl. Ian. BTW - I haven't been following VGUI at all, so please forgive the question. It used to be that VGUI wasn't recommended for use with a "serious" GUI application. Has that changed? Amitha Perera wrote: > Folks, > > I find myself doing more threading with vxl code. I think it makes > sense to bring in pieces of boost into vxl to support this. (For > example, multi-threading in vgui to make the GUI not hang on long > computations.) > > So, I'd like to propose that pieces of boost be brought into v3p. (Not > all of boost, because it is huge, and most of it will not be useful for > vxl.) In particular, I suggest > - Boost.Thread > - Boost.SmartPtr > - Boost.Bind > - Boost.Function > > The v3p version of Boost will be modified to build via CMake, instead of > Boost's jam, so the user will not see any major impact. > > Of course, it should always be possible to use an external version of > boost instead of the v3p version. > > Thoughts? > > Amitha. |
From: Amitha P. <ami...@us...> - 2007-12-18 14:53:45
|
I've looked a briefly at the Intel TBB, and it seems to be a C++ library implementation of OpenMP. Being geared for C++, it may certainly be more powerful and useful. One issue that immediately came to mind there was the requirement for function objects: all the parallel code needs to be implemented in a function object. That may not be a bad thing by itself, but it is different from the way imperative C++ is typically written. (Mind you, heavy use of Boost would force you to write many more function objects.) However, having used neither TBB nor OpenMP, I'm not in a position to comment on the value of one over the other. Still, it didn't look like any of these libraries provided a clean wrapper around the concept of "asynchronous task": a thread that can be started and stopped arbitrarily (on user input, etc.). I think the TBB/OpenMP way helps with easily parallelizable implementations of algorithms, but doesn't help as much with "system-level" parallelism. (Think parallel GUI thread.) I think it will be difficult to avoid concurrent communicating process concepts (locks, semaphores, etc) when trying to do this. I do think that we need something like TBB to implement algorithms; I think explicit threading and locking is *not* the way to go there. I also think we need explicit threads to allow the building blocks to be put together into a system. Does anyone want to spend an hour on the phone to hash out some of these issues? I'm thinking of a discussion grounded on concrete goals. For example: - keeping the gui responsive an algorithm is running; - parallel implementation of Gaussian smoothing; - parallel implementation of connected component labeling. In particular, I'd be very interested to learn about what Ian has found out about the various options available. Amitha. |
From: Ian S. <ian...@st...> - 2007-12-18 15:13:58
|
Amitha Perera wrote: > I've looked a briefly at the Intel TBB, and it seems to be a C++ library > implementation of OpenMP. Being geared for C++, it may certainly be > more powerful and useful. One issue that immediately came to mind there > was the requirement for function objects: all the parallel code needs to > be implemented in a function object. That may not be a bad thing by > itself, but it is different from the way imperative C++ is typically > written. (Mind you, heavy use of Boost would force you to write many > more function objects.) I'd be tempted to include boost lambda at the same time, to minimise this problem. > I do think that we need something like TBB to implement algorithms; I > think explicit threading and locking is *not* the way to go there. I > also think we need explicit threads to allow the building blocks to be > put together into a system. I'd agree with that. What worries me is keeping the two thread implementations compatible. In particular keep them from fighting over access to cores and from blocking each others access to the memory allocator. > Does anyone want to spend an hour on the phone to hash out some of these > issues? I'm thinking of a discussion grounded on concrete goals. For > example: I'm up for that. This Thursday in the early afternoon, or January, is good for me > - keeping the gui responsive an algorithm is running; > - parallel implementation of Gaussian smoothing; > - parallel implementation of connected component labeling. > > In particular, I'd be very interested to learn about what Ian has found > out about the various options available. I'm afraid its literature review and simple coding exercises only so far. Ian. |
From: Amitha P. <ami...@us...> - 2007-12-18 17:25:42
|
Ian Scott wrote: >> Does anyone want to spend an hour on the phone to hash out some of >> these issues? I'm thinking of a discussion grounded on concrete >> goals. For example: > > I'm up for that. > This Thursday in the early afternoon, or January, is good for me Folks are likely to be on vacation this time of year. How about we push this discussion to a t-con on Friday, Jan 4? Amitha. |
From: Matt L. <mat...@gm...> - 2007-12-18 17:33:58
|
On Dec 18, 2007 12:25 PM, Amitha Perera <ami...@us...> wrote: > Folks are likely to be on vacation this time of year. How about we push > this discussion to a t-con on Friday, Jan 4? Fine with me. --Matt |
From: Amitha P. <ami...@us...> - 2007-12-21 14:14:31
|
Amitha Perera wrote: > Folks are likely to be on vacation this time of year. How about we push > this discussion to a t-con on Friday, Jan 4? Coordinating around the world is tough. http://www.timeanddate.com/worldclock/meetingtime.html?month=1&day=4&year=2008&p1=0&p2=179&p3=264&p4=136 How about Thursday Jan 3 at 18:00 UTC? Amitha. |
From: Ian S. <ian...@st...> - 2007-12-27 11:38:41
|
18:00 UTC on Thursday is fine by me. If no-one from Europe is joining that should be fine. I really prefer not to stay that late on Fridays, but other days are usually fine. Ian. > Amitha Perera wrote: >> Folks are likely to be on vacation this time of year. How about we push >> this discussion to a t-con on Friday, Jan 4? > > Coordinating around the world is tough. > > http://www.timeanddate.com/worldclock/meetingtime.html?month=1&day=4&year=2008&p1=0&p2=179&p3=264&p4=136 > > How about Thursday Jan 3 at 18:00 UTC? > > Amitha. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@gm...> - 2008-01-02 16:51:39
|
Amitha, Is the t-con still scheduled for Jan 4 at 14:00 UTC? There was a later message from Ian agreeing to Jan 3 at 18:00 UTC. I just want to make sure we are all on the same page. Also, could you give tell me how to join the call? Will you provide a number for me to call? I don't need the number yet if you don't have it, but it would help to know if it will be a toll free (i.e. 800 number) or regular long distance number. If it's long distance I'll need to obtain an access code in advance. Thanks, Matt On Dec 27, 2007 6:38 AM, Ian Scott <ian...@st...> wrote: > 18:00 UTC on Thursday is fine by me. If no-one from Europe is joining > that should be fine. I really prefer not to stay that late on > Fridays, but other days are usually fine. > > Ian. > > > > Amitha Perera wrote: > >> Folks are likely to be on vacation this time of year. How about we push > >> this discussion to a t-con on Friday, Jan 4? > > > > Coordinating around the world is tough. > > > > http://www.timeanddate.com/worldclock/meetingtime.html?month=1&day=4&year=2008&p1=0&p2=179&p3=264&p4=136 > > > > How about Thursday Jan 3 at 18:00 UTC? > > > > Amitha. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Ian S. <ian...@st...> - 2008-01-02 17:35:31
|
Sorry, Should have replied to the list. I can be there for 14:00UTC on Friday. Ian. Matt Leotta wrote: > Amitha, > > Is the t-con still scheduled for Jan 4 at 14:00 UTC? There was a > later message from Ian agreeing to Jan 3 at 18:00 UTC. I just want to > make sure we are all on the same page. > > Also, could you give tell me how to join the call? Will you provide > a number for me to call? I don't need the number yet if you don't > have it, but it would help to know if it will be a toll free (i.e. 800 > number) or regular long distance number. If it's long distance I'll > need to obtain an access code in advance. > > Thanks, > Matt > > > On Dec 27, 2007 6:38 AM, Ian Scott <ian...@st...> wrote: >> 18:00 UTC on Thursday is fine by me. If no-one from Europe is joining >> that should be fine. I really prefer not to stay that late on >> Fridays, but other days are usually fine. >> >> Ian. >> >> >>> Amitha Perera wrote: >>>> Folks are likely to be on vacation this time of year. How about we push >>>> this discussion to a t-con on Friday, Jan 4? >>> Coordinating around the world is tough. >>> >>> http://www.timeanddate.com/worldclock/meetingtime.html?month=1&day=4&year=2008&p1=0&p2=179&p3=264&p4=136 >>> >>> How about Thursday Jan 3 at 18:00 UTC? >>> >>> Amitha. >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Vxl-maintainers mailing list >>> Vxl...@li... >>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2008-01-02 18:37:54
|
Folks, I will be arranging dial-in numbers for the VXL v3p/boost/threading teleconference. If you plan to call in, let me know, and I will email dial-in information to you before the call. I'd rather not send the numbers to the archived list. There will be a toll-free 800 # in the US. Outside of the US you will have to make a toll call. Fred |
From: Matt L. <mat...@gm...> - 2007-12-18 17:31:36
|
Amitha and Ian, I'd like to participate and be kept in the loop on this. I have very little experience with threaded programming, but I'm will to learn as I go. I also can't comment on benefits of one thread library over another, but I agree that we need both a higher level abstraction (like Intel TBB) for algorithms and lower level thread control for the gui and a few other things. I'm available for a teleconference anytime this week, or in January. However, being a lowly student, I don't have direct access to phone line so I'll need to make arrangements to borrow one once we settle on a time. Here are my current thoughts and concerns: 1) The license on TBB looks to be GPL (not LGPL), does this conflict with VXL? 2) Are well looking to port a threading library into v3p or just optionally let users link to it? 3) Are we going to make threading mandatory in vxl or optional? Should we find a way make the code run in parallel if threading is available and run in serial otherwise, or do we want to create separate parallel versions of algorithms that are only available if the threading library is enabled? 4) Does TBB (or any other package) allow access to the lower level threading functionality? If so we won't have to worry as much about using two conflicting libraries. 5) I am in favor of bringing in Boost lamda, Boost smart pointers, or whatever Boost components we need to make this work. 6) In addition to the gui and parallel image processing, I'm also interested in parallel video processing. That is, have one thread read a video frame and another thread process the video frame while the first thread is concurrently reading the next frame, etc. Nested parallel computing is important here if this video processing involves the application of a parallel image processing algorithm. --Matt On Dec 18, 2007 10:12 AM, Ian Scott <ian...@st...> wrote: > I'd be tempted to include boost lambda at the same time, to minimise > this problem. > > > I do think that we need something like TBB to implement algorithms; I > > think explicit threading and locking is *not* the way to go there. I > > also think we need explicit threads to allow the building blocks to be > > put together into a system. > > I'd agree with that. What worries me is keeping the two thread > implementations compatible. In particular keep them from fighting over > access to cores and from blocking each others access to the memory > allocator. > > > Does anyone want to spend an hour on the phone to hash out some of these > > issues? I'm thinking of a discussion grounded on concrete goals. For > > example: > > I'm up for that. > This Thursday in the early afternoon, or January, is good for me > > > - keeping the gui responsive an algorithm is running; > > - parallel implementation of Gaussian smoothing; > > - parallel implementation of connected component labeling. > > > > In particular, I'd be very interested to learn about what Ian has found > > out about the various options available. > > I'm afraid its literature review and simple coding exercises only so > far. > > Ian. > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Ian S. <ian...@st...> - 2007-12-19 11:20:16
|
Some partial answers Matt Leotta wrote: > 1) The license on TBB looks to be GPL (not LGPL), does this conflict with VXL? IIRC It is GPL with the GLIBC library exception, which effectively allows anyone to use the code, to ship source code that uses the API, and to ship compiler-derived object files of the actual library without any relevant restriction. We would not be able to ship tbb source with our code, but we could provide a CMake option that found it. > 4) Does TBB (or any other package) allow access to the lower level > threading functionality? If so we won't have to worry as much about > using two conflicting libraries. I think the answer is currently no. Ian. |
From: Brendan M. <bre...@gm...> - 2007-12-19 23:50:56
|
G'day All, I too am interested in this, although I don't know if I could contribute much, and I'm not sure if a suitable time could be found for all of us - if not, I'm happy enough sitting out and hearing what you all come up with. From my perspective, algorithm level parallelism is much more interesting, although GUI type threads also need to be handled. Like Matt, I'm also interested in capturing/processing parallelism, but a threaded system is likely to handle that case as well? It looks like a big job though (is vxl thread safe now?). -- Cheers, Brendan |
From: Matt L. <mat...@gm...> - 2007-12-21 00:45:26
|
> > I do think that we need something like TBB to implement algorithms; I > > think explicit threading and locking is *not* the way to go there. I > > also think we need explicit threads to allow the building blocks to be > > put together into a system. > > I'd agree with that. What worries me is keeping the two thread > implementations compatible. In particular keep them from fighting over > access to cores and from blocking each others access to the memory > allocator. I can across an interested article related to TBB, OpenMP, and native threads: http://softwarecommunity.intel.com/articles/eng/1524.htm from the article: "Intel(R) TBB task scheduler is unfair and non-preemptive. Therefore, it is not recommended to use Intel(R) TBB for I/O bound tasks. Using native threads for such tasks is often a better idea and native threads co-exist with Intel(R) TBB components." I'm starting to get the impression that we want TBB for almost everything except VGUI and maybe live data capture, which need native threads. OpenMP is probably a middle ground that we don't need. In the case of libdc1394 that I use for video capture, the library spins off its own capture thread. I don't know if this is the case for other third party capture libraries. We might want to create a very simple native threads compatibility library in core or vcl (something like Openthreads) for use primarily in VGUI. Then we could bring in TBB for the rest. We can discuss this more in the teleconference. --Matt |
From: Amitha P. <ami...@us...> - 2007-12-21 14:26:11
|
Matt Leotta wrote: > I can across an interested article related to TBB, OpenMP, and native > threads: > > http://softwarecommunity.intel.com/articles/eng/1524.htm [...] > I'm starting to get the impression that we want TBB for almost > everything except VGUI and maybe live data capture, which need native > threads. [...] Of course, it looks like that article was written by the TBB designers. :-) Still, your conclusion is probably valid; it does look like for C++, TBB fits better than OpenMP, and TBB offers better support across compilers. Amitha. |
From: Matt L. <mat...@gm...> - 2007-12-21 17:09:39
|
On Dec 21, 2007 9:14 AM, Amitha Perera <ami...@us...> wrote: > How about Thursday Jan 3 at 18:00 UTC? That time works for me. Also, here is another library option to consider: STAPL (Standard Template Adaptive Parallel Library) http://parasol.tamu.edu/stapl/ It's a parallel extension of STL developed at Texas A&M. It seems very similar to TBB, maybe even a bit more complete. It claims to also work with distributed memory systems. I think it's a big plus to have a common API for parallel code that allows the same code to run efficiently on a computing cluster. However, STAPL appears to be only an academic research project for the moment. I haven't found code that is available to the public yet. --Matt |
From: Brendan M. <bre...@gm...> - 2007-12-23 07:21:00
|
G'day All, Hmm - to be honest, I think I'm unlikely to make that time:-}. On balance, I think you should go ahead and have a meeting that's convenient for you northern hemisphere types. I haven't really done my homework on it anyway. So I'm happy enough to go with the consensus. My two cents would be: threads level library for GUI/networking stuff, finer grained library for parallel algorithms. Both stapl and tbb look OK from the very brief look I had ... On 22/12/2007, Matt Leotta <mat...@gm...> wrote: > On Dec 21, 2007 9:14 AM, Amitha Perera > <ami...@us...> wrote: > > How about Thursday Jan 3 at 18:00 UTC? > > That time works for me. > > Also, here is another library option to consider: STAPL (Standard > Template Adaptive Parallel Library) > http://parasol.tamu.edu/stapl/ > It's a parallel extension of STL developed at Texas A&M. It seems > very similar to TBB, maybe even a bit more complete. It claims to > also work with distributed memory systems. I think it's a big plus to > have a common API for parallel code that allows the same code to run > efficiently on a computing cluster. However, STAPL appears to be only > an academic research project for the moment. I haven't found code > that is available to the public yet. > > --Matt > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Amitha P. <ami...@us...> - 2007-12-24 14:58:35
|
Brendan McCane wrote: > G'day All, > > Hmm - to be honest, I think I'm unlikely to make that time:-}. :-) Okay, let's change to Fri, Jan 4 at 14:00 UTC http://www.timeanddate.com/worldclock/meetingdetails.html?year=2008&month=1&day=4&hour=14&min=0&sec=0&p1=179&p2=264&p3=136 Amitha. |
From: Matt L. <mat...@gm...> - 2007-12-24 16:00:18
|
On Dec 24, 2007 9:58 AM, Amitha Perera <ami...@us...> wrote: > Okay, let's change to Fri, Jan 4 at 14:00 UTC Fine with me. Just let me know how to join the call, I've never done this before. Thanks, Matt |