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
