ctime and e_ctime

[nickoppen]

I've been working on a small program to compare various data passing strategies. On the epiphany I'm using e_ctime and on the ARM the standard ctime functions.

The epiphany runs at 1GHz and the ARM at 833MHz so I'm assuming that the ARM number and the epiphany number at the end of the run cannot be compared.

Can I then assume that dividing the epiphany number by 1,000 and the ARM number by 833 will produce a comparable number? Indeed dividing by 1,000,000,000 and 833,000,000 will produce seconds?

nick

[jar]

Nick,

The e-lib e_ctimer_get/set routines use the hardware timer which counts down clock cycles. Most Parallella boards run at 600 MHz Epiphany and 667 MHz (I think) for ARM so I'm not sure why your clocks are faster. The host (ARM) ctime routines return time typically at a resolution in seconds rather than clock cycles. You may want to use the sys/time.h gettimeofday routine to get millisecond resolution on the host.

[nickoppen]

Thanks jar,

I am not actually sure what my clock rates are. I found those numbers from digging through documentation.

In the previous version of this system I used ctime::ticks(). I had another look through ctime documentation and I'm still not sure what it actually counts but there should be a value called CLOCKS_PER_SEC that will convert it to seconds.

Is there something similar for e_ctime? I don't see anything in the SDK reference. The reason I want a common base is to be able to see how much time is taken up with loading the kernel to the epiphany.

My goal is present a way of measuring overall execution time (from the ARM point of view) and then break that down into specific chunks on the epiphany side, e.g. overall processing time on the core, idle time, data read and data write times etc. In this way the application programmer will have a simple and robust way to see where the time is being taken and to test if changes to the code have improved performance.

nick

[jar]

[nickoppen]

Awesome. Thanks.

[sebraa]

[jar]

[sebraa]

[jar]

sebraa,

I didn't intend to sound as abrasive or dismissive. I appreciate high performance code and the macro is useful.