Beman Dawes wrote:
Libor,
Log outputs from Android emulator are: times()-begin: c1=13829 tm1.tms_stime + tm1.tms_cstime=18, tm1.tms_utime + tm1.tms_cutime=638 times()-end: c2=13966 tm2.tms_stime + tm2.tms_cstime=18, tm2.tms_utime + tm2.tms_cutime=670 real 0.001s, cpu 0.000s (23.9%), user 0.000s, system 0.000s thread_clock: wall=1376ms, cpu=318ms
Could the problem be with the Android emulator rather than Android itself?
Google seems to find multiple reports of problems with the Android emulator related to time.
--Beman
Hello Beman and Vicente, it does not seem that the problem in stopclock test is caused by Android emulator. I have similar results from Android HW (BeagleBoard xM) and Linux PC (Ubuntu 11.04). Here is summary of stopclock test outputs on all tested platforms: Windows Vista: stopwatches::stopclock<>: real 1.031s, cpu 0.031s (3.0%), user 0.031s, system 0.000s thread_clock: wall=1031ms, cpu=31ms Android emulator: stopwatches::stopclock<>: real 0.001s, cpu 0.000s (23.2%), user 0.000s, system 0.000s thread_clock: wall=1377ms, cpu=312ms Android on BeagleBoard: stopwatches::stopclock<>: real 0.001s, cpu 0.000s (12.3%), user 0.000s, system 0.000s thread_clock: wall=1140ms, cpu=139ms Linux Ubuntu 11.04 (x86): stopwatches::stopclock<>: real 0.001s, cpu 0.000s (3.9%), user 0.000s, system 0.000s thread_clock: wall=1035ms, cpu=34ms My impression is that text output of stopwatches::stopclock<> on Android/Linux is 1000x less than shall be, so the printed values are not seconds but milliseconds. BR, Libor -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-Thread-clock-compatibility-problem... Sent from the Boost - Dev mailing list archive at Nabble.com.