On Thu, 13 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> For previous tests MSVC 2005 was used, with a local
> production built Harbour (r9921), using usual HB_NO_DEBUG
> switch, nothing else. I've been using memtst (with WAITs
> removed) and speedtst. The machine is idle while tests are
> running, and there is no background process doing anything
> significant.
> Pls find results for tst01 and tst02, and also earlier
> test repeated (with similar results).
Thank you. Please look carefully on results.
Im tst01 which tries to show the highest possible difference
you have:
5.36 NO FM STAT
6.64 DISABLED DYN FM STAT
quite big but not amazing.
In tst02 which shows .prg overhead:
2.28 NO FM STAT
2.11 DISABLED DYN FM STAT
So faster (shorter) code gives worse results.
Still acceptable. The time was small and sth happen with
your OS during tests. Why it was added to process CPU time
it MS programmer secret - not my job ;-). With new CPUs
which can dynamically change clock frequency it's sometimes
hard to well scale some operations and calculate real CPU
time.
In memtst you do not have any difference in both mode.
I expected such results.
but in speedtst.prg in one test loop T029 you have:
4.28 NO FM STAT
7.20 DISABLED DYN FM STAT
which creates nearly the whole final difference. All other
tests gives in practice the same results. Somtimes 1-st binary
is faster and sometimes 2-nd one. The differences are on the
precision level and can be ignored.
Please also note that test t030 makes exactly the same operarions
plus additional eval() and the results are:
7.27 NO FM STAT
7.36 DISABLED DYN FM STAT
Nearly equal and much closer to 7.20 and the proportions are
expected. T030 should be a little bit slower then T029.
And here is the problem. What happen with T029 NO FM STAT
that it was suddenly executed such fast.
In practice all test you send so far had such "strange" results
somewhere. Especially when it was MSVC build.
I can understand that sth is suddenly executed slower due to some
unexpected asynchronous events. OS has to serve them switching
CPU context what reduce CPU cache efficiency so it also increase
CPU time calculated for process. But how it's possible that sth
begins to work such incredibly faster? It's 40% faster? If you
take it as a base then for some reasons in the second test you
have 70% speed overhead. It's not normal for me. It's interesting
if such results are repeatable when you run the test few times
again.
Windows is designed as interactive system and it automatically
balance priorities prefferering processes and threads which do
not make have calculations but often call some windows API
functions. Maybe it may cause such effect. Other processes may
not do anything significant, just simply call some yield()
function so they do not produce measurable overhead for
process manager. But it will be enough that they will be preferred
and will receive CPU quite often to strongly reduce the performance
of tested code. F.e. due to CPU cache resetting. It may explain
the speed differences which appears in your tests. It may be
also answer why you have such good results in some of your
MSVC test when 90% of tests gives comparable results to other
compilers but some of them are unexpectedly faster. Small
manipulation in process priority in CRTL will be enough.
But this is only speculation. Anyhow I suggest MS-Windows
users to make some experiments with process priority to check
how it change the result of ST speedtst. In good test environment
it should not make any difference because other jobs should
not need CPU.
If you are interested then just create simple .prg wrapper to
MS-Windows process priority function and used call it with
different priorities at the begining of speedtst.prg.
Or maybe you have other ides why such things
4.28 NO FM STAT
7.20 DISABLED DYN FM STAT
are possible in MSVC builds.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
