Subject: Re: [boost] Flow-based programming library for Boost?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-12-06 02:24:21
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:
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
> Note that SystemC and OMNet++ have a quite different engine. To which
> you library is closer and how it is different?
> Unsubscribe & other changes: