[GSoC] pipelines questions
Hi, I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following: * Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1] * If the former is true, should be n3534 [2] considered as a strict requirement or as a vague suggestion? * If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation? * I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway? Thanks, Benedek [0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/source/browse/include/p... [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Proposal
Le 24/02/14 21:58, Thaler Benedek a écrit :
Hi, Hi, I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following:
* Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1] from scratch using whatever C++11 library (or Boost). The Google implementation is just one implementation that can be inspected. * If the former is true, should be n3534 [2] considered as a strict requirement or as a vague suggestion? I'm open to any design that improves the proposal.
* If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation? I have not inspected too much the Google implementation :(
I would prefer to have an implementation that takes advantage of any C++11 feature that make the user interface more friendly. Only once we have this implementation we would move to a portable implementation to C++98 compilers using Boost.
* I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway?
I would prefer that the project delivers something that can be included into boost at each step. That is the project would be iterative and so there would be something useful at the end. Boost.thread contains already most of the building blocks (thread safe queue and executors), so I don't think that the project will take too long. The time given by GSoC should be enough. Best, Vicente
Thanks, Benedek
[0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/source/browse/include/p... [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Proposal
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, Then n3534 shows the following example: [0] pipeline::execution task( pipeline::from(filenames) | pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) | output_queue).run(&thread_pool); I can't figure out how to create a segment from "read_file | grep_fn | vgrep_fn | sed_fn" without overloading the free function operator|(function, function). Is this really we want to do? Shouldn't we use pipeline::make() here? Thanks, Benedek [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Parallel On Tue, Feb 25, 2014 at 12:01 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 24/02/14 21:58, Thaler Benedek a écrit :
Hi,
Hi,
I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following:
* Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1]
from scratch using whatever C++11 library (or Boost). The Google implementation is just one implementation that can be inspected.
* If the former is true, should be n3534 [2] considered as a strict
requirement or as a vague suggestion?
I'm open to any design that improves the proposal.
* If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation?
I have not inspected too much the Google implementation :(
I would prefer to have an implementation that takes advantage of any C++11 feature that make the user interface more friendly. Only once we have this implementation we would move to a portable implementation to C++98 compilers using Boost.
* I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway?
I would prefer that the project delivers something that can be included into boost at each step. That is the project would be iterative and so there would be something useful at the end. Boost.thread contains already most of the building blocks (thread safe queue and executors), so I don't think that the project will take too long. The time given by GSoC should be enough.
Best, Vicente
Thanks, Benedek
[0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/ source/browse/include/pipeline.h [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/ n3534.html#Proposal
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 1 Mar 2014 at 16:32, Thaler Benedek wrote:
pipeline::execution task( pipeline::from(filenames) | pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) | output_queue).run(&thread_pool);
If you're going down the road of adding pipelined i/o, do look into proposed Boost.AFIO which already implements chainable asynchronous file i/o for you. Should save you a ton of work. Failing that, Boost.Iostreams also provides a huge amount of chainable i/o implementation already written and tested. Boost.Iostreams can't do async easily though.
I can't figure out how to create a segment from "read_file | grep_fn | vgrep_fn | sed_fn" without overloading the free function operator|(function, function). Is this really we want to do? Shouldn't we use pipeline::make() here?
I would look at Google's proposal as merely a suggestion. Microsoft have their own proposals for (mis)using the C++ operator syntax as a DSL for specifying asynchronous operations. Just because Google proposed it doesn't mean it's special. You're right that overloading global functions is generally to be avoided unless you absolutely control the implementation of the types entering the global function. I personally think that the "Improvements to future<T>" proposal is far safer and much more likely to get standardised. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Le 01/03/14 16:32, Thaler Benedek a écrit :
Hi,
Then n3534 shows the following example: [0]
pipeline::execution task( pipeline::from(filenames) | pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) | output_queue).run(&thread_pool);
I can't figure out how to create a segment from "read_file | grep_fn | vgrep_fn | sed_fn" without overloading the free function operator|(function, function). Is this really we want to do? Shouldn't we use pipeline::make() here?
Yes, I think make is missing here. Best, Vicente
participants (3)
-
Niall Douglas -
Thaler Benedek -
Vicente J. Botet Escriba