Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #14394 > unrolled thread

Speed Test for Comparison

Back to article view | Back to comp.lang.c

Contents

  Speed Test for Comparison "Mel Smith" <med_cutout_syntel@aol.com> - 2011-12-08 10:09 -0700
    Re: Speed Test for Comparison Richard Sanders <lnr729@gmail.com> - 2011-12-08 11:19 -0800
      Re: Speed Test for Comparison "Mel Smith" <med_cutout_syntel@aol.com> - 2011-12-08 13:13 -0700
        Re: Speed Test for Comparison "Mel Smith" <med_cutout_syntel@aol.com> - 2011-12-08 13:18 -0700
          Re: Speed Test for Comparison Seebs <usenet-nospam@seebs.net> - 2011-12-08 20:41 +0000
            Re: Speed Test for Comparison Ben Pfaff <blp@cs.stanford.edu> - 2011-12-08 12:49 -0800
              Re: Speed Test for Comparison Seebs <usenet-nospam@seebs.net> - 2011-12-08 21:53 +0000
        Re: Speed Test for Comparison Seebs <usenet-nospam@seebs.net> - 2011-12-08 20:41 +0000
    Re: Speed Test for Comparison "BartC" <bc@freeuk.com> - 2011-12-08 21:43 +0000
    Re: Speed Test for Comparison ImpalerCore <jadill33@gmail.com> - 2011-12-08 13:58 -0800
    Re: Speed Test for Comparison Keith Thompson <kst-u@mib.org> - 2011-12-08 14:58 -0800
      Re: Speed Test for Comparison "Mel Smith" <med_cutout_syntel@aol.com> - 2011-12-10 11:28 -0700
        Re: Speed Test for Comparison "BartC" <bc@freeuk.com> - 2011-12-10 21:40 +0000
          Re: Speed Test for Comparison "Mel Smith" <med_cutout_syntel@aol.com> - 2011-12-10 19:26 -0700
        Re: Speed Test for Comparison Keith Thompson <kst-u@mib.org> - 2011-12-10 13:49 -0800

#14394 — Speed Test for Comparison

Hi:

    I have included below 56 speed test results when using the C-based 
Harbour language along with the MinGw 4.6.1 C compiler

    This test package was generated by running the Harbour compiler to 
create C modules which were then compiled by the MinGw compiler, and then 
linked..

    The executable was then run to create the test results below.

    I'd be interested in getting some purely C-based test results based on 
any of the 56 tests I ran below.

    Each test below was run 1,000,000 times. The results below are stated in 
decimal seconds.

    The assignment operator is ':='  rather than '='

    Variable Name Description:


    L means a Local vrbl
    S means a Static vrbl
    M means a 'Private' Memory Vrbl
    F means a 'Field vrbl' -- that is a Field in a database
    P means a 'Public' vrbl accessible by all modules in the .exe
and
    _C means a Character String vrbl
    _N means a Numeric vrbl
    _D means a Date vrbl

    The & means a 'macro' compilation whereby the string is compiled and run 
at runtime.

Thanks.
-- 
Mel Smith

**************  test results *******************

12/08/11 09:38:05 Windows XP 5.1.2600 Service Pack 3
Harbour 3.1.0dev (Rev. 17129) MinGW GNU C 4.6.1 (32-bit) x86
THREADS: 0
N_LOOPS: 1000000
[ T000: empty loop overhead ]...................................0.08
====================================================================
[ T001: x := L_C ]..............................................0.06
[ T002: x := L_N ]..............................................0.08
[ T003: x := L_D ]..............................................0.08
[ T004: x := S_C ]..............................................0.09
[ T005: x := S_N ]..............................................0.08
[ T006: x := S_D ]..............................................0.09
[ T007: x := M->M_C ]...........................................0.06
[ T008: x := M->M_N ]...........................................0.11
[ T009: x := M->M_D ]...........................................0.09
[ T010: x := M->P_C ]...........................................0.08
[ T011: x := M->P_N ]...........................................0.09
[ T012: x := M->P_D ]...........................................0.11
[ T013: x := F_C ]..............................................0.20
[ T014: x := F_N ]..............................................0.28
[ T015: x := F_D ]..............................................0.17
[ T016: x := o:Args ]...........................................0.20
[ T017: x := o[2] ].............................................0.14
[ T018: round( i / 1000, 2 ) ]..................................0.48
[ T019: str( i / 1000 ) ].......................................1.48
[ T020: val( s ) ]..............................................0.33
[ T021: val( a [ i % 16 + 1 ] ) ]...............................0.61
[ T022: dtos( d - i % 10000 ) ].................................0.48
[ T023: eval( { || i % 16 } ) ].................................0.45
[ T024: eval( bc := { || i % 16 } ) ]...........................0.31
[ T025: eval( { |x| x % 16 }, i ) ].............................0.39
[ T026: eval( bc := { |x| x % 16 }, i ) ].......................0.31
[ T027: eval( { |x| f1( x ) }, i ) ]............................0.55
[ T028: eval( bc := { |x| f1( x ) }, i ) ]......................0.50
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].................0.44
[ T030: x := &( "f1(" + str(i) + ")" ) ]........................2.63
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]................3.02
[ T032: x := valtype( x ) +  valtype( i ) ].....................0.47
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..........1.36
[ T034: x := a[ i % 16 + 1 ] == s ].............................0.44
[ T035: x := a[ i % 16 + 1 ] = s ]..............................0.45
[ T036: x := a[ i % 16 + 1 ] >= s ].............................0.45
[ T037: x := a[ i % 16 + 1 ] <= s ].............................0.45
[ T038: x := a[ i % 16 + 1 ] < s ]..............................0.47
[ T039: x := a[ i % 16 + 1 ] > s ]..............................0.44
[ T040: ascan( a, i % 16 ) ]....................................0.47
[ T041: ascan( a, { |x| x == i % 16 } ) ].......................3.59
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]....1.11
[ T043: x := a ]................................................0.06
[ T044: x := {} ]...............................................0.13
[ T045: f0() ]..................................................0.11
[ T046: f1( i ) ]...............................................0.23
[ T047: f2( c[1...8] ) ]........................................0.17
[ T048: f2( c[1...40000] ) ]....................................0.17
[ T049: f2( @c[1...40000] ) ]...................................0.17
[ T050: f2( @c[1...40000] ), c2 := c ]..........................0.22
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]....................0.70
[ T052: f2( a ) ]...............................................0.17
[ T053: x := f4() ].............................................0.66
[ T054: x := f5() ].............................................0.31
[ T055: x := space(16) ]........................................0.23
[ T056: f_prv( c ) ]............................................0.50
====================================================================
[ total application time: ]....................................31.94
[ total real time: ]...........................................31.95

**************** end of test ********************************

[toc] | [next] | [standalone]

#14397

On Thu, 8 Dec 2011 10:09:11 -0700, "Mel Smith"
<med_cutout_syntel@aol.com> wrote:

>Hi:
>
>    I have included below 56 speed test results when using the C-based 
>Harbour language along with the MinGw 4.6.1 C compiler
>
>    This test package was generated by running the Harbour compiler to 
>create C modules which were then compiled by the MinGw compiler, and then 
>linked..

Ok so what you are testing is the speed at wich a Harbour crerated C
program runs (on an un specified computer) with unspecified C code.

What is your point?   

[toc] | [prev] | [next] | [standalone]

#14399

Richard said:

> Ok so what you are testing is the speed at wich a Harbour crerated C
> program runs (on an un specified computer) with unspecified C code.
>

    The computer and OS  is specified at the top of the Test Run.

    The code is Harbour code which generates C-Code which is compiled into 
object code which is linked into an executable

> What is your point?

    Can you select a couple of obvious/clear tests (for you) and duplicate 
them with a C compiler of your choice, and post the results please. I expect 
that your optimized C-Code will significantly beat the test run, but by how 
much ?

    Please try to give the same info that's provided in the header of the 
test run.

Thank you !

-Mel

[toc] | [prev] | [next] | [standalone]

#14400

>    The computer and OS  is specified at the top of the Test Run.

Sorry !

    The computer is NOT specified. In my test run case, it is:

    an Intel(R) Core(TM) 2 CPU
    4300 @ 1.80 GHz with 1.99GB of Ram

Mel

[toc] | [prev] | [next] | [standalone]

#14401

On 2011-12-08, Mel Smith <med_cutout_syntel@aol.com> wrote:
>     an Intel(R) Core(TM) 2 CPU
>     4300 @ 1.80 GHz with 1.99GB of Ram

You haven't specified the specs of the RAM -- not just speed, but CAS
timings, for instance.  Doesn't matter as much with a Core 2, but with
newer CPUs it might also matter how much cooling you have, as they'll
overclock themselves if there's extra bandwidth.

Is there any other software, at all, running on the machine?  Are you
counting CPU cycles or wall clock time?  How are you accounting for
context switch penalties if your code gets shuffled from one core to
another?

Benchmarking:  Hard to do well.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#14403

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-12-08, Mel Smith <med_cutout_syntel@aol.com> wrote:
>>     an Intel(R) Core(TM) 2 CPU
>>     4300 @ 1.80 GHz with 1.99GB of Ram
>
> You haven't specified the specs of the RAM -- not just speed, but CAS
> timings, for instance.  Doesn't matter as much with a Core 2, but with
> newer CPUs it might also matter how much cooling you have, as they'll
> overclock themselves if there's extra bandwidth.

I can't see how microbenchmarks that, e.g., measure the speed of
assignment to a local variable would depend much on the size of
RAM.  They probably run entirely in-cache.  If they don't, then
the language implementation is a hopeless pig.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#14407

On 2011-12-08, Ben Pfaff <blp@cs.stanford.edu> wrote:
> I can't see how microbenchmarks that, e.g., measure the speed of
> assignment to a local variable would depend much on the size of
> RAM.  They probably run entirely in-cache.  If they don't, then
> the language implementation is a hopeless pig.

Entire caches get flushed due to something else happening sometimes.  At
that point, timing of main memory can have measurable influences.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#14402

On 2011-12-08, Mel Smith <med_cutout_syntel@aol.com> wrote:
>     Can you select a couple of obvious/clear tests (for you) and duplicate 
> them with a C compiler of your choice, and post the results please. I expect 
> that your optimized C-Code will significantly beat the test run, but by how 
> much ?

I don't see where this would go, or why it would go there.  It's not even
a remotely meaningful test unless it's running on the same hardware, for
one thing.  And even if it were, so what?  Lots of languages use C backends,
and at least a couple have used C as an intermediate representation; so
what?

I assume you're trying to make a point, but I can see neither the point nor
the relevance to a discussion of C programming.

You don't see us posting random benchmarks in assembly groups and asking
them to run comparisons on unrelated hardware, do you?

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#14405

"Mel Smith" <med_cutout_syntel@aol.com> wrote in message
news:9kc99pFurU1@mid.individual.net...

>    I have included below 56 speed test results when using the C-based
> Harbour language along with the MinGw 4.6.1 C compiler

> 12/08/11 09:38:05 Windows XP 5.1.2600 Service Pack 3
> Harbour 3.1.0dev (Rev. 17129) MinGW GNU C 4.6.1 (32-bit) x86
> THREADS: 0
> N_LOOPS: 1000000
> [ T000: empty loop overhead ]...................................0.08

> ====================================================================
> [ T001: x := L_C ]..............................................0.06

Your tests consist of individual assignment statements? Then they are
probably too trivial to be meaningful.

The timings are also a little suspect: an empty loop executed a million
times would be expected to give a timing of zero, even when the compiler
doesn't eliminate the loop completely anyway, as it is likely to do on these
simple tests.

There are loads of well-known benchmarks around, perhaps you should try
testing some of those. Some of the assignments are difficult to reproduce in
C anyway, unless you explain exactly what str(i) means for example.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14406

On Dec 8, 12:09 pm, "Mel Smith" <med_cutout_syn...@aol.com> wrote:
> Hi:
>
>     I have included below 56 speed test results when using the C-based
> Harbour language along with the MinGw 4.6.1 C compiler
>
>     This test package was generated by running the Harbour compiler to
> create C modules which were then compiled by the MinGw compiler, and then
> linked..
>
>     The executable was then run to create the test results below.
>
>     I'd be interested in getting some purely C-based test results based on
> any of the 56 tests I ran below.
>
>     Each test below was run 1,000,000 times. The results below are stated in
> decimal seconds.
>
>     The assignment operator is ':='  rather than '='
>
>     Variable Name Description:
>
>     L means a Local vrbl
>     S means a Static vrbl
>     M means a 'Private' Memory Vrbl
>     F means a 'Field vrbl' -- that is a Field in a database
>     P means a 'Public' vrbl accessible by all modules in the .exe
> and
>     _C means a Character String vrbl
>     _N means a Numeric vrbl
>     _D means a Date vrbl
>
>     The & means a 'macro' compilation whereby the string is compiled and run
> at runtime.
>
> Thanks.
> --
> Mel Smith
>
> **************  test results *******************
>
> 12/08/11 09:38:05 Windows XP 5.1.2600 Service Pack 3
> Harbour 3.1.0dev (Rev. 17129) MinGW GNU C 4.6.1 (32-bit) x86
> THREADS: 0
> N_LOOPS: 1000000
> [ T000: empty loop overhead ]...................................0.08
> ====================================================================
> [ T001: x := L_C ]..............................................0.06
> [ T002: x := L_N ]..............................................0.08
> [ T003: x := L_D ]..............................................0.08
> [ T004: x := S_C ]..............................................0.09
> [ T005: x := S_N ]..............................................0.08
> [ T006: x := S_D ]..............................................0.09
> [ T007: x := M->M_C ]...........................................0.06
> [ T008: x := M->M_N ]...........................................0.11
> [ T009: x := M->M_D ]...........................................0.09
> [ T010: x := M->P_C ]...........................................0.08
> [ T011: x := M->P_N ]...........................................0.09
> [ T012: x := M->P_D ]...........................................0.11
> [ T013: x := F_C ]..............................................0.20
> [ T014: x := F_N ]..............................................0.28
> [ T015: x := F_D ]..............................................0.17
> [ T016: x := o:Args ]...........................................0.20
> [ T017: x := o[2] ].............................................0.14
> [ T018: round( i / 1000, 2 ) ]..................................0.48
> [ T019: str( i / 1000 ) ].......................................1.48
> [ T020: val( s ) ]..............................................0.33
> [ T021: val( a [ i % 16 + 1 ] ) ]...............................0.61
> [ T022: dtos( d - i % 10000 ) ].................................0.48
> [ T023: eval( { || i % 16 } ) ].................................0.45
> [ T024: eval( bc := { || i % 16 } ) ]...........................0.31
> [ T025: eval( { |x| x % 16 }, i ) ].............................0.39
> [ T026: eval( bc := { |x| x % 16 }, i ) ].......................0.31
> [ T027: eval( { |x| f1( x ) }, i ) ]............................0.55
> [ T028: eval( bc := { |x| f1( x ) }, i ) ]......................0.50
> [ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].................0.44
> [ T030: x := &( "f1(" + str(i) + ")" ) ]........................2.63
> [ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]................3.02
> [ T032: x := valtype( x ) +  valtype( i ) ].....................0.47
> [ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..........1.36
> [ T034: x := a[ i % 16 + 1 ] == s ].............................0.44
> [ T035: x := a[ i % 16 + 1 ] = s ]..............................0.45
> [ T036: x := a[ i % 16 + 1 ] >= s ].............................0.45
> [ T037: x := a[ i % 16 + 1 ] <= s ].............................0.45
> [ T038: x := a[ i % 16 + 1 ] < s ]..............................0.47
> [ T039: x := a[ i % 16 + 1 ] > s ]..............................0.44
> [ T040: ascan( a, i % 16 ) ]....................................0.47
> [ T041: ascan( a, { |x| x == i % 16 } ) ].......................3.59
> [ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]....1.11
> [ T043: x := a ]................................................0.06
> [ T044: x := {} ]...............................................0.13
> [ T045: f0() ]..................................................0.11
> [ T046: f1( i ) ]...............................................0.23
> [ T047: f2( c[1...8] ) ]........................................0.17
> [ T048: f2( c[1...40000] ) ]....................................0.17
> [ T049: f2( @c[1...40000] ) ]...................................0.17
> [ T050: f2( @c[1...40000] ), c2 := c ]..........................0.22
> [ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]....................0.70
> [ T052: f2( a ) ]...............................................0.17
> [ T053: x := f4() ].............................................0.66
> [ T054: x := f5() ].............................................0.31
> [ T055: x := space(16) ]........................................0.23
> [ T056: f_prv( c ) ]............................................0.50
> ====================================================================
> [ total application time: ]....................................31.94
> [ total real time: ]...........................................31.95
>
> **************** end of test ********************************

It might be more prudent to take a more well known benchmark that's
implemented in C, reimplement it in your language, and compare the
results?  I doubt you'll find much interest here in writing C code for
comparison tests to benchmark against a new and less well known
language.

Perhaps someone knows a heavy memory or computation benchmark that is
built in C that you could easily adapt to Harbour and do the
comparison yourself, as you have the best control over the hardware
used in the test?

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#14408

"Mel Smith" <med_cutout_syntel@aol.com> writes:
>     I have included below 56 speed test results when using the C-based 
> Harbour language along with the MinGw 4.6.1 C compiler
>
>     This test package was generated by running the Harbour compiler to 
> create C modules which were then compiled by the MinGw compiler, and then 
> linked..
>
>     The executable was then run to create the test results below.
>
>     I'd be interested in getting some purely C-based test results based on 
> any of the 56 tests I ran below.
>
>     Each test below was run 1,000,000 times. The results below are stated in 
> decimal seconds.
>
>     The assignment operator is ':='  rather than '='
>
[snip]
>
>     The & means a 'macro' compilation whereby the string is compiled and run 
> at runtime.
[...]
[ T028: eval( bc := { |x| f1( x ) }, i ) ]......................0.50

I had to manually copy-and-paste one of your test cases for this
followup, because for some reason you put all the test results after a
sig delimiter ("-- ").

So what you're looking for is, for example, benchmark results for C code
equivalent to whatever

    eval( bc := { |x| f1( x ) }, i )

means in your language.  Are you asking us to manually translate your
code snippets to C, then write wrappers to perform and report the
timings?

Speaking only for myself, that's far more work than I'm willing to do.
If you provided the C code you want benchmarked, someone *might* be more
likely to run it for you.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14445

Hi:

   I have extracted Test 019 (T019) from the test suite, and have recoded
part of it to show the translation and compilation sequence to .C code

   and at the bottom of this post I have include the Harbour source code for 
the test

-Mel Smith


***** following is the C code for Test 019 (T019) **********
This test took approx 1.52 seconds on my machine noted above

/*
 * Harbour 3.1.0dev (Rev. 17129)
 * MinGW GNU C 4.6.1 (32-bit)
 * Generated C source from "source\T019.prg"
 */

#include "hbvmpub.h"
#include "hbpcode.h"
#include "hbinit.h"
#include "hbxvm.h"


HB_FUNC( MAIN );
HB_FUNC_EXTERN( SCROLL );
HB_FUNC_EXTERN( SETPOS );
HB_FUNC( T019 );
HB_FUNC_EXTERN( QOUT );
HB_FUNC_EXTERN( STR );
HB_FUNC_EXTERN( INKEY );
HB_FUNC_EXTERN( HB_SECONDSCPU );
HB_FUNC_EXTERN( PROCNAME );


HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_T019 )
{ "MAIN", {HB_FS_PUBLIC | HB_FS_FIRST | HB_FS_LOCAL}, {HB_FUNCNAME( MAIN )}, 
NULL },
{ "SCROLL", {HB_FS_PUBLIC}, {HB_FUNCNAME( SCROLL )}, NULL },
{ "SETPOS", {HB_FS_PUBLIC}, {HB_FUNCNAME( SETPOS )}, NULL },
{ "T019", {HB_FS_PUBLIC | HB_FS_LOCAL}, {HB_FUNCNAME( T019 )}, NULL },
{ "QOUT", {HB_FS_PUBLIC}, {HB_FUNCNAME( QOUT )}, NULL },
{ "STR", {HB_FS_PUBLIC}, {HB_FUNCNAME( STR )}, NULL },
{ "INKEY", {HB_FS_PUBLIC}, {HB_FUNCNAME( INKEY )}, NULL },
{ "HB_SECONDSCPU", {HB_FS_PUBLIC}, {HB_FUNCNAME( HB_SECONDSCPU )}, NULL },
{ "PROCNAME", {HB_FS_PUBLIC}, {HB_FUNCNAME( PROCNAME )}, NULL }
HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_T019, "source\\T019.prg", 0x0, 
0x0003 )

#if defined( HB_PRAGMA_STARTUP )
   #pragma startup hb_vm_SymbolInit_T019
#elif defined( HB_DATASEG_STARTUP )
   #define HB_DATASEG_BODY    HB_DATASEG_FUNC( hb_vm_SymbolInit_T019 )
   #include "hbiniseg.h"
#endif

HB_FUNC( MAIN )
{
   do {
 hb_xvmFrame( 1, 0 );
 hb_xvmSetLine( 5 );
 hb_xvmPushFuncSymbol( symbols + 1 );
 if( hb_xvmDo( 0 ) ) break;
 hb_xvmPushFuncSymbol( symbols + 2 );
 hb_xvmPushInteger( 0 );
 hb_xvmPushInteger( 0 );
 if( hb_xvmDo( 2 ) ) break;
 hb_xvmSetLine( 8 );
 hb_xvmPushFuncSymbol( symbols + 3 );
 if( hb_xvmFunction( 0 ) ) break;
 hb_xvmPopLocal( 1 );
 hb_xvmSetLine( 17 );
 hb_xvmPushFuncSymbol( symbols + 4 );
 hb_xvmPushLocal( 1 );
 if( hb_xvmArrayItemPush( 1 ) ) break;
 hb_xvmPushStringConst( " *** ", 5 );
 if( hb_xvmPlus() ) break;
 hb_xvmPushFuncSymbol( symbols + 5 );
 hb_xvmPushLocal( 1 );
 if( hb_xvmArrayItemPush( 2 ) ) break;
 hb_xvmPushInteger( 5 );
 hb_xvmPushInteger( 2 );
 if( hb_xvmFunction( 3 ) ) break;
 if( hb_xvmPlus() ) break;
 if( hb_xvmDo( 1 ) ) break;
 hb_xvmSetLine( 20 );
 hb_xvmPushFuncSymbol( symbols + 4 );
 if( hb_xvmDo( 0 ) ) break;
 hb_xvmSetLine( 21 );
 hb_xvmPushFuncSymbol( symbols + 4 );
 hb_xvmPushStringConst( "Press any Key to Exit: ", 23 );
 if( hb_xvmDo( 1 ) ) break;
 hb_xvmSetLine( 22 );
 hb_xvmPushFuncSymbol( symbols + 6 );
 hb_xvmPushInteger( 0 );
 if( hb_xvmDo( 1 ) ) break;
 hb_xvmSetLine( 23 );
 hb_xvmRetNil();
 /* *** END PROC *** */
   } while( 0 );
}

HB_FUNC( T019 )
{
   HB_BOOL fValue;
   do {
 hb_xvmFrame( 2, 0 );
 hb_xvmSetLine( 30 );
 hb_xvmPushNil();
 hb_xvmPopLocal( 2 );
 hb_xvmSetLine( 31 );
 hb_xvmPushFuncSymbol( symbols + 7 );
 if( hb_xvmFunction( 0 ) ) break;
 hb_xvmPopLocal( 1 );
 hb_xvmSetLine( 33 );
 hb_xvmPushInteger( 1 );
 hb_xvmPushUnRef();
 hb_xvmPopLocal( 2 );
 goto lab00002;
lab00001: ;
 hb_xvmSetLine( 34 );
 hb_xvmPushFuncSymbol( symbols + 5 );
 hb_xvmPushLocal( 2 );
 if( hb_xvmDivideByInt( 1000 ) ) break;
 if( hb_xvmDo( 1 ) ) break;
 hb_xvmSetLine( 33 );
 if( hb_xvmLocalIncPush( 2 ) ) break;
lab00002: ;
 if( hb_xvmGreaterThenIntIs( 1000000, &fValue ) ) break;
 if( !fValue )
  goto lab00001;
 hb_xvmSetLine( 37 );
 hb_xvmPushFuncSymbol( symbols + 7 );
 if( hb_xvmFunction( 0 ) ) break;
 hb_xvmPushLocal( 1 );
 if( hb_xvmMinus() ) break;
 hb_xvmPopLocal( 1 );
 hb_xvmSetLine( 43 );
 hb_xvmPushFuncSymbol( symbols + 8 );
 if( hb_xvmFunction( 0 ) ) break;
 hb_xvmPushStringConst( ": ", 2 );
 if( hb_xvmPlus() ) break;
 hb_xvmPushStringConst( "str(i/1000)", 11 );
 if( hb_xvmPlus() ) break;
 hb_xvmPushLocal( 1 );
 hb_xvmArrayGen( 2 );
 hb_xvmRetValue();
 /* *** END PROC *** */
   } while( 0 );
}
****************   end of C code **********************

************************************************************
Following is the harbour code that generated the C Code above

function main()
local aResult

// clear the screen
CLS

// then call the Test Function T019
aResult := T019()

// Now Print the results to the Screen:
// (The question mark '?') skips a line and print the String Expression
//  to its right)
// 1st element is a character string
// 2nd element must be converted from a numeric to a character string
// so that it can be printed. The format here has two decimals

? aResult[1] + " *** " + str(aResult[2],5,2)

// wait for a key press before exiting
?
? "Press any Key to Exit: "
inkey(0)
return nil

// Here is the test function for making a string of an real number
// after taking an incremented integer and dividing it by 1000,
// and doing this 1,000,000 times

function T019()
local time, i:= nil
time = hb_secondscpu()  // get the cpu seconds to this moment for this app

for i := 1 to 1000000
   str( i / 1000 )     // no assignment of the return value
next

time := hb_secondscpu() - time   // compute cpu seconds used

// now return a 2-element array containing
// 1. The Procedure Name and the Expression to be analyzed
// 2. The time in decimal seconds taken to run the loop

return { procname() + ": " +  'str(i/1000)', time }

************* end of Harbour Code **********

[toc] | [prev] | [next] | [standalone]

#14455

"Mel Smith" <med_cutout_syntel@aol.com> wrote in message
news:9khmneF4udU1@mid.individual.net...

> for i := 1 to 1000000
>   str( i / 1000 )     // no assignment of the return value
> next

You want to compare C code that does this *directly*, or C code that
implements some arbitrary virtual machine that does the same job?

In either case, the timings will be dominated by the time needed to convert
floating point numbers to strings, and, if the implementation does proper
string handling, by the overheads of creating and discarding a million short
strings.

Any comparison is anyway likely to be meaningless because you are testing
one arbitrary implementation against another.

FWIW, a simple sprintf() loop in C took about 1 second on my machine. Your 
str(i/1000) loop in one of my scripting languages, with proper string 
handling, took 2 seconds to execute a million times. This language is 
usually much slower than C. So the actual task, rather than language 
overheads, seems to be dominating execution time.

However, given the complicated-looking C code that your language generates, 
I'm surprised it isn't much slower. Your first step might be to simply find 
out how long the task itself might be expected to take, but I'm not sure why 
you can't do this for yourself:

#include <stdio.h>

int main(void) {
int i;
char str[100];

for (i=0; i<1000000; ++i) {
 sprintf(str,"%f",i/1000.0);
}
}

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14469

Bart said:

> You want to compare C code that does this *directly*, or C code that
> implements some arbitrary virtual machine that does the same job?
>
> In either case, the timings will be dominated by the time needed to 
> convert
> floating point numbers to strings, and, if the implementation does proper
> string handling, by the overheads of creating and discarding a million 
> short
> strings.
>
> Any comparison is anyway likely to be meaningless because you are testing
> one arbitrary implementation against another.
>
> FWIW, a simple sprintf() loop in C took about 1 second on my machine. Your 
> str(i/1000) loop in one of my scripting languages, with proper string 
> handling, took 2 seconds to execute a million times. This language is 
> usually much slower than C. So the actual task, rather than language 
> overheads, seems to be dominating execution time.
>
> However, given the complicated-looking C code that your language 
> generates, I'm surprised it isn't much slower. Your first step might be to 
> simply find out how long the task itself might be expected to take, but 
> I'm not sure why you can't do this for yourself:
>
> #include <stdio.h>
>
> int main(void) {
> int i;
> char str[100];
>
> for (i=0; i<1000000; ++i) {
> sprintf(str,"%f",i/1000.0);
> }
> }


Hi Bart:

    Thanks for the code:

    I'm going to use my MinGw 4.6.1 compiler and try to compile it and run 
it myself.

Thank you !

    (I need nothing more than this !)

and to Keith:  I don't expect anything more. Bart has provided what I wish.


-Mel Smith

[toc] | [prev] | [next] | [standalone]

#14457

"Mel Smith" <med_cutout_syntel@aol.com> writes:
>    I have extracted Test 019 (T019) from the test suite, and have recoded
> part of it to show the translation and compilation sequence to .C code
>
>    and at the bottom of this post I have include the Harbour source code for 
> the test
[snip]

Ok, that's 1 out of 56.

Just how much work do you expect us to do for you?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web