Agreed. If we want to rename it I'm fine with that, but I'd like to keep it. It was invaluable during the buffer patch development.
On Mon, Dec 15, 2014 at 12:06 PM, Ola Liljedahl <[email protected]> wrote: > > On 15 December 2014 at 18:58, Bill Fischofer <[email protected]> > wrote: > > Eventually yes, however right now with the CUnit tests only covering > "sunny > > day" tests that's not sufficient. odp_example at least is multi-theaded > and > > does some limited stress testing of the APIs, which is needed. > So it is a rather complete smoke test (functionality and performance) > but not really an example. > > > > > On Mon, Dec 15, 2014 at 11:54 AM, Mike Holmes <[email protected]> > > wrote: > >> > >> > >> > >> On 15 December 2014 at 12:13, Bill Fischofer <[email protected] > > > >> wrote: > >>> > >>> The odp_example() call is a very useful sanity test. > >> > >> > >> That is an interesting observation that I hope goes away :) the sanity > >> test should now come via "make check" or we failed with the unit tests. > >> You should only want to look in examples to learn how to use a api that > is > >> new to you, any other reason and you risk losing the simplicity needed > to be > >> a lucid example. > >> > >>> > >>> The problem with many of the others is that they are not self-contained > >>> and assume some sort of (unspecified) I/O configuration and > source/sink. > >> > >> > >> Agree and if the doxygen starts to work with the examples a lot of > >> supporting text and even diagrams can be given. > >> > >>> > >>> > >>> On Mon, Dec 15, 2014 at 11:06 AM, Ola Liljedahl > >>> <[email protected]> wrote: > >>>> > >>>> On 15 December 2014 at 17:04, Mike Holmes <[email protected]> > >>>> wrote: > >>>> > > >>>> > > >>>> > On 15 December 2014 at 09:56, Savolainen, Petri (NSN - FI/Espoo) > >>>> > <[email protected]> wrote: > >>>> >> > >>>> >> > >>>> >> > >>>> >> > -----Original Message----- > >>>> >> > From: ext Ola Liljedahl [mailto:[email protected]] > >>>> >> > Sent: Monday, December 15, 2014 2:53 PM > >>>> >> > To: Savolainen, Petri (NSN - FI/Espoo) > >>>> >> > Cc: ext Mike Holmes; [email protected] > >>>> >> > Subject: Re: [lng-odp] [PATCH 0/3] Remove odp_schedule_one for > 1.0 > >>>> >> > compliance > >>>> >> > > >>>> >> > On 15 December 2014 at 13:45, Savolainen, Petri (NSN - FI/Espoo) > >>>> >> > <[email protected]> wrote: > >>>> >> > > Otherwise OK, but shouldn't remove the timer example. > >>>> >> > I also think it is good to have a timer example. Just shouldn't > be > >>>> >> > called odp_timer_test. Since we don't have any other timer > example, > >>>> >> > this one will have to do for now. > >>>> >> > > >>>> >> > > > >>>> >> > > Why it's a bad example? I think we need a set of simple > examples. > >>>> >> > > It > >>>> >> > would also demonstrate how to step out from a schedule loop (== > >>>> >> > pause -> > >>>> >> > schedule until ODP_BUFFER_INVALID is returned -> tear down / step > >>>> >> > out). > >>>> >> > > > >>>> >> > > The new timer example could be more performance oriented, etc. > >>>> >> > What is that that we want to demonstrate? > >>>> >> > 1) basic timer usage (single-threaded?) > >>>> >> > 2) multithreaded, combining timer and scheduler > >>>> >> > 3) more? > >>>> >> > > >>>> >> > Can you be more specific with "more performance oriented"? > >>>> >> > >>>> >> I think all examples should be multi-threaded. There could be two > >>>> >> categories of examples: "hello world" and more > realistic/performance > >>>> >> oriented. The first would demonstrate usage of an API in simplest > >>>> >> possible > >>>> >> way and with low dependency to other APIs. > >>>> The simplest possible way is probably not multithreaded. Just some > >>>> straight code from main, creating necessary resources (e.g. memory > >>>> regions, buffer pools, queues) and then some sunny day usage of the > >>>> API in question. > >>>> > >>>> > > >>>> > > >>>> > These should be in odp/examples. I think they should be called out > >>>> > from the > >>>> > doxygen API documentation to get the most value from them. > >>>> > > >>>> >> > >>>> >> The second would be more complex, but would run more things in > >>>> >> parallel > >>>> >> and measure performance as well (easy / light weight check that > >>>> >> parallel > >>>> >> execution works and performs OK). > >>>> These are benchmarks, not examples. As Mike writes below... > >>>> > >>>> Benchmarks might not be particularly simple and easy to understand. > >>>> > >>>> > > >>>> > > >>>> > These should be in odp/benchmarks, they need to allow for being too > >>>> > complex > >>>> > to be an introductory example to a feature, but they also need to do > >>>> > something useful beyond creating the configuration needed for > testing > >>>> > unlike > >>>> > anything in odp/test. > >>>> If they are micro benchmarks, they shouldn't really do anything else. > >>>> If they do something else, that processing will also be included in > >>>> the benchmark results. > >>>> > >>>> > >>>> > > >>>> >> > >>>> >> > >>>> >> From current examples: > >>>> >> - odp_example is type 2 for queues/scheduling. There could be > another > >>>> >> "hello world" queues/scheduling app. > >>>> >> > >>>> >> - odp_timer_test is type 1 for timers (runs 20 sec and exists). > There > >>>> >> could be another that runs long / forever and measures cpu load, > >>>> >> timeout > >>>> >> accuracy, etc > >>>> Sounds like a benchmark to me (measuring characteristics in general, > >>>> not just throughout for some specific function). This can easily > >>>> become complicated. > >>>> > >>>> > > >>>> > > >>>> > I believe that the current examples are not ideal, I also feel we > >>>> > need to > >>>> > delete test/api_test, these should be examples, benchmarks or tests. > >>>> Kill them all! > >>>> > >>>> > > >>>> >> > >>>> >> > >>>> >> > >>>> >> -Petri > >>>> >> > >>>> >> > >>>> > > >>>> > > >>>> > -- > >>>> > Mike Holmes > >>>> > Linaro Sr Technical Manager > >>>> > LNG - ODP > >>>> > >>>> _______________________________________________ > >>>> lng-odp mailing list > >>>> [email protected] > >>>> http://lists.linaro.org/mailman/listinfo/lng-odp > >> > >> > >> > >> -- > >> Mike Holmes > >> Linaro Sr Technical Manager > >> LNG - ODP >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
