Total time vs. file duration

[linadaud]

Hi,

I ran a profiling of a .mp4 file with the information below:

Initial Object Descriptor ID 1
Duration 00:00:15
Service Handler: GPAC IsoMedia Reader
Service URL: C:\\Documents and Settings\\daud\\Bureau\\gpac\\test_sequences\\kangaroo.mp4
Scene Description: Width 400 - Height 300
Scene Codec GPAC BIFS Decoder

However, in the call graph, I observed a total time of 9 677 035 s (in Windows via MS Visual Studio) and 10 069 015 s (in Ubuntu Linux) the main function!

Could someone explain how can this be possible? How can I observe a total time that is faster than the file duration itself?

Thanks,

Lina

[Peter_W_Intel]

Hi Lina,

I think that Call graph will spend more time than application itself, since Call graph will call functions in itslibraries.

You said that total time was from main function only, I suppose that is not enough! You have to count spending timefrom other threads.

See example for application vtunedemo on Linux*:

1. Run "time ./vtunedemo"

real 0m0.287s (real execution time)

user 0m0.812s (user's time consumed in eight cores of my system,was partialllyparallelized)

sys 0m0.002s

2. Run Call graph for vtunedemo, total time -

__libc_start_main (thread_0): 4,937,232 s

main_thread (thread_1) : 1,226,465 s

main_thread (thread_2) : 1,027,404 s

main_thread (thread_3) : 1,037,240 s

Therefore, total time = 8,228,341 s = 8.22s. It seems there are big overheads - but I have to deduct total wait time from four threads. They are

__libc_start_main (thread_0): 4,936,834 s

main_thread (thread_1) : 749,068 s

main_thread (thread_2) :746,968 s

main_thread (thread_3) : 761,892 s

Total wait time = 7,194,762 s.

Total no-wait time = 8,228,341 us - 7,194,762 s = 1,033,579 s = 1.03s

So real overheads = 1.03s - 0.81s = 0.22s

Can you please verify data again on your app, such as above example?

If you still have any concern, please let me know. Or you can submit a ticket with your example program to https://premier.intel.com. Thank you.

Regards, Peter

[linadaud]

I think that Call graph will spend more time than application itself, since Call graph will call fun ctions in itslibraries.

I agree with you, Peter and I'm confused with the result observed from the profiling.

You said that total time was from main function only, I suppose that is not enough! You have to count spending timefrom other threads.

I had a correct result when running in multi-thread. However, the result with total time shorter than the duration time was the one in mono-thread mode. Therefore, I think that observing the main total time would be enough since it corresponds to the application total time. Am I wrong?

See example for application vtunedemo on Linux*:

...

Can you please verify data again on your app, such as above example?

I'll do as you suggest in multi-thread mode :-)

Thanks, Peter.

Regards,

Lina

[linadaud]

Peter,

I ran the application as instructed. Below are the results:

1. run time ./application

real 15.95
user 0.20
sys 0.65

2. Run Call graph for the application (still in mono-threading)

__libc_start_main = 10, 012, 504 s

main = 10,012,458 s

I observed real execution time longer than the profiled time! How could this be?

[Peter_W_Intel]

Quoting linadaud

Peter,

I ran the application as instructed. Below are the results:

1. run time ./application

real 15.95
user 0.20
sys 0.65

2. Run Call graph for the application (still in mono-threading)

__libc_start_main = 10, 012, 504 s

main = 10,012,458 s

I observed real execution time longer than the profiled time! How could this be?

Ifyour application is single application, total wait time is almost "zero", main function is execuation time.

Please submit a ticket to https://premier.intel.com with you application (test case) to us for investigating ifthis is a Call graph bug.

Remindto chekcif you are using VTune Analyzer v9.1 Update 7, which is latest product.

Regards, Peter