[Harbour] 2008-10-03 21:53 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

Szakáts Viktor harbour.01 at syenar.hu
Fri Oct 3 20:37:05 EDT 2008


Thanks Przemek. And just one note, these weren't measured in a
VM. In fact I've only run tests in VM once (on the Mac to see
some Core2 results), but I didn't post the result, since they
looked odd.

Brgds,
Viktor

On 2008.10.04., at 2:32, Przemyslaw Czerpak wrote:

> On Sat, 04 Oct 2008, Szak�ts Viktor wrote:
>
> Hi Viktor,
>
>>>> [ total application time: ]........................43.00 ..37.75
>>>> [ total real time: ]...............................37.47 ..31.09
>>> I would seriously check how MSVC measure time.
>>> In ST build "total application time" should be lower then
>>> "total real time". I do not know why you have such results.
>>> Maybe MSVC C-RTL executes some internal threads?
>> I was also wondering why is there a big difference at all,
>> this used to happen in virtual machines only so far.
>> I really don't know.
>> BTW, I'm trying to guess it since long, but I couldn't
>> yet find the answer what is the difference between these
>> values, especially in ST builds.
>
> "application time" is CPU time given to process by OS.
> It should not contain the time CPU spends executing other
> processes.
> "real time" is just a _real_ time.
> In single CPU machine and multi process OS "real time"
> is always slower or equal to "application time" because
> it does not contain time when other processes where executed.
> Of course sometimes due to rounded total results you can see few
> milliseconds more.
> When you have more then one CPU used by application simultaneously
> in MT program then it can be bigger because. Your results suggest
> that MSVC uses its own helper thread or the cost of virtual machine
> executed on other CPU is added to application time. In such case
> running more then one thread will reduce the VM performance and
> final results are worse then in real world.
> Anyway it is hard to compare such results and take some decisions
> because they can be strongly dependent on VM implementation.
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list
> Harbour at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour



More information about the Harbour mailing list