bvanevery@gmail.com wrote:
> Arlet wrote:
> >
> > For a software solution, make sure you have an accurate hardware timer,
> > and take a timestamp at beginning and end, then subtract the values,
> > and report (through printf, or any other suitable method). Use the same
> > method to time an empty piece of code to measure the timestamping
> > overhead.
>
> If the task is amenable, put the assembly code in a loop and run it
> millions of times.  This makes the calculation take much longer and
> then you don't need quite so accurate a timer.  Of course, you have to
> be careful that you're not changing the basic nature of the processing,
> such as reading in lotsa data from main memory that otherwise would
> have been in a cache.  Anyways, "put a loop around it" is a general
> trick for benchmarking.
>
>
> Cheers,
> Brandon Van Every


Hi,
I found something interesting w.r.t Code Composer Studio (CCS) under
the topic of Benchmarking .
Pls find the info below that i got from a link . (Looks interesting !!
)

Code Composer Studio has the capability of benchmarking your code,
meaning that you can analyze how long your code takes to execute. In
the following example, you will be analyzing how long it takes to
execute each call of the dotp() function.

One way of benchmarking your code is to set two breakpoints. When you
run the program, the breakpoints will tell the debugger to stop
execution. A clock-cycle counter, built into the debugger, can be used
to count the number of cycles between these breakpoints.

DO THIS
=======
Do DEBUG:RESTART to set the PC at the beginning of the code.

Choose PROFILER:START NEW SESSION... with session name of your choice.

You can profile, count the number of clock cycles, a function by adding
it to the profile session you created. To do this, left double click on
the lab1.c file in the Project View to view the file. Place the cursor
on any line inside the dotp() function and right click. Choose Profile
Fimction -> in (session-name) Session, where (session-name)
identifies the profiling session you created.
Execute the code by DEBUG:RUN.

After CPU halts, click on the Functions tab of the profiling window to
see the result of the profiling of the dotp() function.

The numbers displayed are the statistics of the execution of the dotp()
function gathered by CCS while executing the code.

For interpretations of these numbers, read the CCS help topic
Profiler:Viewing Profile Data by choosing the Help:Contents menu on the
CCS menu bar.

You can also add a particular line of the code to the profile session.
Learn how to do this by reading the helps. There are lots of profiling
capabilities that cannot be covered fully in this manual.
How many clock cycles (on average) does it take to execute the dotp()
function? 

Regards,
Karthik Balaguru

Arlet wrote:
>
> For a software solution, make sure you have an accurate hardware timer,
> and take a timestamp at beginning and end, then subtract the values,
> and report (through printf, or any other suitable method). Use the same
> method to time an empty piece of code to measure the timestamping
> overhead.

If the task is amenable, put the assembly code in a loop and run it
millions of times.  This makes the calculation take much longer and
then you don't need quite so accurate a timer.  Of course, you have to
be careful that you're not changing the basic nature of the processing,
such as reading in lotsa data from main memory that otherwise would
have been in a cache.  Anyways, "put a loop around it" is a general
trick for benchmarking.


Cheers,
Brandon Van Every

  You dont have to if you code modular , the kernel will do it and

 run it without crash , because kernel has stats on all Primatives ,

 refuses to run a module that does not fit 110% in that slot .

 This is the essence of my Multi-tasking techniques , that never

 allow interupts , i always poll ....   Just in time software !!


  See , simple .....
 I am the worlds greatest systems programmer ....
____________________________________________________________



karthikbg wrote:
> Hi,
>
> I have some 20 lines of code in assembly .
> I have various tasks running. How to calculate the total time of
> execution of the code in assembly alone in Vxworks ?
>
> Since any task might get invoked due to various reasons ,
> Is putting one printf that prints the current time at the start of
> assmbly and another printf at the end of assmbly code that prints the
> current time the only way for caculating the assmbly code execution
> time ?
> 
> Any other ideas.
> 
> Thx in advans,
> Karthik Balaguru

karthikbg wrote:

>Hi,
>
>I have some 20 lines of code in assembly .
>I have various tasks running. How to calculate the total time of
>execution of the code in assembly alone in Vxworks ?
>
>Since any task might get invoked due to various reasons ,
>Is putting one printf that prints the current time at the start of
>assmbly and another printf at the end of assmbly code that prints the
>current time the only way for caculating the assmbly code execution
>time ?
>
>Any other ideas.

Check out the functions in VxWorks' timexLib library.

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at hotmail dot com     |          - The Who, Bargain

Arlet escribi�:
> John B wrote:
> 
>> On 04/01/2007 karthikbg wrote:
>>
>>> Hi,
>>>
>>> I have some 20 lines of code in assembly .
>>> I have various tasks running. How to calculate the total time of
>>> execution of the code in assembly alone in Vxworks ?
>>>
>>> Since any task might get invoked due to various reasons ,
>>> Is putting one printf that prints the current time at the start of
>>> assmbly and another printf at the end of assmbly code that prints the
>>> current time the only way for caculating the assmbly code execution
>>> time ?
>>>
>>> Any other ideas.
>>>
>>> Thx in advans,
>>> Karthik Balaguru
>> Calling 'printf()' at the start and end of 20 lines of assembler is
>> meaningless. The execution time of the library code will far exceed
>> that of the assembler. Use the old method of counting processor cycles
>> and adding them up. You'll be surprised at how easy it is. If you don't
>> have access to a pencil and paper then an abacus is quite useful.
> 
> I agree. To get the time for longer/more complicated pieces of code,
> you can toggle an IO pin at the beginning and end, and use a scope to
> measure the time. If the time isn't constant, a digital scope with
> infinite persistence is very handy, while trying to exercise all
> possible execution paths.
> 
> For a software solution, make sure you have an accurate hardware timer,
> and take a timestamp at beginning and end, then subtract the values,
> and report (through printf, or any other suitable method). Use the same
> method to time an empty piece of code to measure the timestamping
> overhead.
> 
If you use a Pentium target, you can use the internal processor's cycle 
counter, which can be accesed with a pair of protected instructions. I 
used it when debugging a subtle concurrency problem years ago, and was 
very handy.

John B wrote:

> On 04/01/2007 karthikbg wrote:
>
> > Hi,
> >
> > I have some 20 lines of code in assembly .
> > I have various tasks running. How to calculate the total time of
> > execution of the code in assembly alone in Vxworks ?
> >
> > Since any task might get invoked due to various reasons ,
> > Is putting one printf that prints the current time at the start of
> > assmbly and another printf at the end of assmbly code that prints the
> > current time the only way for caculating the assmbly code execution
> > time ?
> >
> > Any other ideas.
> >
> > Thx in advans,
> > Karthik Balaguru
>
> Calling 'printf()' at the start and end of 20 lines of assembler is
> meaningless. The execution time of the library code will far exceed
> that of the assembler. Use the old method of counting processor cycles
> and adding them up. You'll be surprised at how easy it is. If you don't
> have access to a pencil and paper then an abacus is quite useful.

I agree. To get the time for longer/more complicated pieces of code,
you can toggle an IO pin at the beginning and end, and use a scope to
measure the time. If the time isn't constant, a digital scope with
infinite persistence is very handy, while trying to exercise all
possible execution paths.

For a software solution, make sure you have an accurate hardware timer,
and take a timestamp at beginning and end, then subtract the values,
and report (through printf, or any other suitable method). Use the same
method to time an empty piece of code to measure the timestamping
overhead.

On 04/01/2007 karthikbg wrote:

> Hi,
> 
> I have some 20 lines of code in assembly .
> I have various tasks running. How to calculate the total time of
> execution of the code in assembly alone in Vxworks ?
> 
> Since any task might get invoked due to various reasons ,
> Is putting one printf that prints the current time at the start of
> assmbly and another printf at the end of assmbly code that prints the
> current time the only way for caculating the assmbly code execution
> time ?
> 
> Any other ideas.
> 
> Thx in advans,
> Karthik Balaguru

Calling 'printf()' at the start and end of 20 lines of assembler is
meaningless. The execution time of the library code will far exceed
that of the assembler. Use the old method of counting processor cycles
and adding them up. You'll be surprised at how easy it is. If you don't
have access to a pencil and paper then an abacus is quite useful.

-- 
John B

Hi,

I have some 20 lines of code in assembly .
I have various tasks running. How to calculate the total time of
execution of the code in assembly alone in Vxworks ?

Since any task might get invoked due to various reasons ,
Is putting one printf that prints the current time at the start of
assmbly and another printf at the end of assmbly code that prints the
current time the only way for caculating the assmbly code execution
time ?

Any other ideas.

Thx in advans,
Karthik Balaguru