Subject: Re: [boost] Flow-based programming library for Boost?
From: Marcus Tomlinson (themarcustomlinson_at_[hidden])
Date: 2012-12-06 07:08:22
Thomas, thanks for the support :) I do understand where Dave is coming from though, the overhead of constructing the circuit (particularly one that is static throughout the lifetime of the application) on startup can be avoided with compile-time wiring. My intention was to create a library that allows for building both static and/or dynamic circuits, hence it was designed with particular focus on run-time.
Your HPX work is very interesting! I'm curious, what are your thoughts on my approach to parallel execution in DSPatch (explained in my previous post)?
On 06 Dec 2012, at 9:24 AM, Thomas Heller <thom.heller_at_[hidden]> wrote:
> On 12/05/2012 10:34 PM, Vicente J. Botet Escriba wrote:
>> Le 05/12/12 18:26, Marcus Tomlinson a Ã©crit :
>>> Hmm, well SystemC is clearly very powerful and can easily achieve the same results, but my particular domain is more the higher-level, cross platform, easy-to-use, PC applications.
>> How is your context different? Could you describe the kind of applications using your library?
>>> OMNet++ is closer to what I have, but my aim is total abstraction from the particular application.
>> What do you mean?
>>> DSPatch allows you to build flow-based programs for any application you can think of.
>> Could you elaborate on this?
> I've been working with Dataflows for past couple of months and I agree. Dataflow or Flow-Based programming is a very nifty paradigm to express programs. Especially when it comes to parallel execution.
> I am not working in a signal processing background where this technique is well known. I investigated this programming paradigm in the past for one specific linear algebra application (Results can be seen here: http://stellar.cct.lsu.edu/pubs/isc2012.pdf and here: http://www10.informatik.uni-erlangen.de/Publications/Theses/2012/Heller_MA12.pdf). We constructed the dataflow tree completely dynamicly in an almost natural way (modulo the syntatic differences). So i have to disagree with Dave Abrahams that purely compile-time based dataflow "wiring" is the most efficient way.
>>> I looked at many implantations of this nature while developing DSPatch and found that there was almost always a steep learning curve to using them.
>> This is the case for any complete framework.
>>> Not only do I want to make dataflow / flow-based programming easier for developers, I want to make it more accessable.
>> How do you think do you achieve that compared to them?
>>> Hopefully if I can get the support I need to get this project on Boost, it'll be widely accessible and helpful to people like me who are/were looking for something like this. This kind of programming paradigm is so useful in so many applications, it really shouldn't be as niche a topic as it is. Perhaps it's always been portrayed as too complex?
>> Note that SystemC and OMNet++ have a quite different engine. To which you library is closer and how it is different?
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk