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

Groups > comp.lang.forth > #29575 > unrolled thread

Forth vs Java in calculating partial sum ;)

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

Contents

  Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.com> - 2014-04-12 19:11 +0200
    Re: Forth vs Java in calculating partial sum ;) Paul Rubin <no.email@nospam.invalid> - 2014-04-12 10:15 -0700
      Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:15 +0200
        Re: Forth vs Java in calculating partial sum ;) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-14 23:20 +0000
          Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.invalid> - 2014-04-15 04:18 +0200
            Re: Forth vs Java in calculating partial sum ;) m.a.m.hendrix@tue.nl - 2014-04-15 00:32 -0700
              Re: Forth vs Java in calculating partial sum ;) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-15 11:33 +0000
              Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.com> - 2014-04-15 15:55 +0200
            Re: Forth vs Java in calculating partial sum ;) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 14:44 +0000
              Re: Forth vs Java in calculating partial sum ;) Paul Rubin <no.email@nospam.invalid> - 2014-04-15 09:00 -0700
                Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.invalid> - 2014-04-15 19:38 +0200
              Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-15 11:41 -0700
              Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.com> - 2014-04-16 07:10 +0200
              Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.com> - 2014-04-16 07:24 +0200
                Re: Forth vs Java in calculating partial sum ;) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-16 10:24 +0000
    Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-12 13:01 -0700
      Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-12 13:06 -0700
      Re: Forth vs Java in calculating partial sum ;) Paul Rubin <no.email@nospam.invalid> - 2014-04-12 15:49 -0700
        Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-12 23:00 -0700
          Re: Forth vs Java in calculating partial sum ;) Paul Rubin <no.email@nospam.invalid> - 2014-04-13 00:14 -0700
            Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-13 02:03 -0700
          Re: Forth vs Java in calculating partial sum ;) Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 14:52 +0200
      Re: Forth vs Java in calculating partial sum ;) "WJ" <w_a_x_man@yahoo.com> - 2014-12-12 23:45 +0000
    Re: Forth vs Java in calculating partial sum ;) mhx@iae.nl - 2014-04-12 13:33 -0700
      Re: Forth vs Java in calculating partial sum ;) Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-12 22:50 +0200
        Re: Forth vs Java in calculating partial sum ;) Melzzzzz <mel@zzzzz.invalid> - 2014-04-13 03:30 +0200
        Re: Forth vs Java in calculating partial sum ;) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 13:43 +0000
    Re: Forth vs Java in calculating partial sum ;) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 10:05 -0500
    Re: Forth vs Java in calculating partial sum ;) "WJ" <w_a_x_man@yahoo.com> - 2014-12-05 05:46 +0000
    Re: Forth vs Java in calculating partial sum ;) "WJ" <w_a_x_man@yahoo.com> - 2014-12-10 09:50 +0000
      Re: Forth vs Java in calculating partial sum ;) "WJ" <w_a_x_man@yahoo.com> - 2014-12-10 18:29 +0000

Page 1 of 2  [1] 2  Next page →

#29575 — Forth vs Java in calculating partial sum ;)

Seems that Java bits Forth in optimizing tight loops. Eg division by
constant optimization is performed automatically.

Idea for bench is from:
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M cumul.fs -e bye
62.1816300541229 
116.054248397871 
1666666616666667 

real	0m1.249s
user	0m1.225s
sys	0m0.023s

bmaxa@maxa:~/examples/forth$ time java Cumul
378.7878787878788
1190.4761904761904
1666666616666667

real	0m0.247s
user	0m0.215s
sys	0m0.042s

bmaxa@maxa:~/examples/forth$ cat cumul.fs
: N 50000000 ;

: init_cumul
	N 0 ?do
	i 3 / i +
	over i cells + !
	loop ;
	
: cumul 
	dup @ 
	N 1 ?do
	over i cells + @
	+ 2dup
	swap i cells + !
	loop 
	drop ;
: bench 2dup utime 2over execute drop utime 
	2swap d- d>f N s>f fswap f/ f. cr 2drop drop ;

N cells allocate throw
' init_cumul bench
' cumul bench
dup N 1 - cells + @ . cr
free throw


bmaxa@maxa:~/examples/forth$ cat Cumul.java
public class Cumul {

	public static void sum(long[] data) {
		if(data.length == 0) return;
		for( int i = 1; i !=  data.length; ++i)
		  data[i] += data[i-1];
	}



    public static long[]  givemeanarray(int N) {
    	long[] bigarray = new long[N];
        for(int k = 0; k<N; ++k)
          bigarray[k] = k+k/3;
        return bigarray;
     }
     
     public static void test(int N) {
      long bef = System.currentTimeMillis();
      long[] data = givemeanarray(N);
      long aft = System.currentTimeMillis();
      System.out.println(N/(1000.0 * (aft-bef)));
      bef = System.currentTimeMillis();
      sum(data);
      aft = System.currentTimeMillis();
      System.out.println(N/(1000.0 * (aft-bef)));
      System.out.println(data[N-1]);
     }
     
     public static void main(String[] args) {
     	test( 50 * 1000 * 1000 );
     }


}



-- 
Click OK to continue...

[toc] | [next] | [standalone]

#29576

Melzzzzz <mel@zzzzz.com> writes:
> Seems that Java bits Forth in optimizing tight loops. Eg division by
> constant optimization is performed automatically....
> bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M cumul.fs -e bye
> ...
> bmaxa@maxa:~/examples/forth$ time java Cumul ...

What, you're comparing a compiler against an interpreter (gforth) and
saying the difference comes from division by constant optimization?  Try
comparing against iforth or vfx.

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

#29649

On Sat, 12 Apr 2014 10:15:16 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> Melzzzzz <mel@zzzzz.com> writes:
> > Seems that Java bits Forth in optimizing tight loops. Eg division by
> > constant optimization is performed automatically....
> > bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M cumul.fs -e
> > bye ...
> > bmaxa@maxa:~/examples/forth$ time java Cumul ...
> 
> What, you're comparing a compiler against an interpreter (gforth) and
> saying the difference comes from division by constant optimization?
> Try comparing against iforth or vfx.

Well, I tried iforth eval version and it's install scripts does
not work on Linux. Running from bin directory does not works
as it complains that it cannot load image file and I think
this is not because it can't find it.
Then I tried vfxforth and it runs without installing
but it looks overly complicated to me to compile,
as it seems there is no command line option, rather
I have to write some code in order to compile?
It is just 32 bit for eval anyway.
Than I tried lina64 (ciforth) it has compile
option (-c) and it does compile to executable
after some tweaking (seems does not support floats
and utime) but is slower than gforth in this test program.

-- 
Click OK to continue...

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

#29651

On Mon, 14 Apr 2014 22:15:17 +0200, Melzzzzz <mel@zzzzz.com> wrote:

>> > bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M cumul.fs -e
>> > bye ...
>> > bmaxa@maxa:~/examples/forth$ time java Cumul ...
>> 
>> What, you're comparing a compiler against an interpreter (gforth) and
>> saying the difference comes from division by constant optimization?
>> Try comparing against iforth or vfx.
>

>Then I tried vfxforth and it runs without installing
>but it looks overly complicated to me to compile,
>as it seems there is no command line option, rather
>I have to write some code in order to compile?

RTFM. vfxforth treats the rest of the command line as Forth
source code to interpret, e.g.
  vfxlin  include cumul.fs

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#29653

On Mon, 14 Apr 2014 23:20:57 GMT
stephenXXX@mpeforth.com (Stephen Pelc) wrote:

> On Mon, 14 Apr 2014 22:15:17 +0200, Melzzzzz <mel@zzzzz.com> wrote:
> 
> >> > bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M cumul.fs -e
> >> > bye ...
> >> > bmaxa@maxa:~/examples/forth$ time java Cumul ...
> >> 
> >> What, you're comparing a compiler against an interpreter (gforth)
> >> and saying the difference comes from division by constant
> >> optimization? Try comparing against iforth or vfx.
> >
> 
> >Then I tried vfxforth and it runs without installing
> >but it looks overly complicated to me to compile,
> >as it seems there is no command line option, rather
> >I have to write some code in order to compile?
> 
> RTFM. vfxforth treats the rest of the command line as Forth
> source code to interpret, e.g.
>   vfxlin  include cumul.fs
> 
> Stephen
> 

Thanks, I tweaked it to use (ticks) instead of utime and this
is result:
bmaxa@maxa:~/vfxforth/VfxLinEval/Bin$ time ./vfxlin include ../Lib/Ndp387.fth include /home/bmaxa/examples/forth/cumul.fs





 VFX Forth for Linux IA32
 © MicroProcessor Engineering Ltd, 1998-2013 

 Version: 4.62 [build 0522]
 Build date: 4 November 2013

 Free dictionary = 7900431 bytes [7715kb]


Including ../Lib/Ndp387.fth
Including /home/bmaxa/examples/forth/cumul.fs
238.09524 
555.55556 
262486571 

real	0m0.330s
user	0m0.313s
sys	0m0.016s


It is much faster than gforth but still slower than Java.

-- 
Click OK to continue...

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

#29657

On Tuesday, April 15, 2014 4:18:49 AM UTC+2, Melzzzzz wrote:
> On Mon, 14 Apr 2014 23:20:57 GMT
> 
[..]
>  VFX Forth for Linux IA32
>  © MicroProcessor Engineering Ltd, 1998-2013 
>  Version: 4.62 [build 0522]
>  Build date: 4 November 2013
>  Free dictionary = 7900431 bytes [7715kb]
> 
> Including ../Lib/Ndp387.fth
> Including /home/bmaxa/examples/forth/cumul.fs

> 238.09524 
> 555.55556 
> 262486571 
> 
> real	0m0.330s
> user	0m0.313s
> sys	0m0.016s
> 
> It is much faster than gforth but still slower than Java.
> 

But much more important, the result is wrong.

-marcel

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

#29663

On Tue, 15 Apr 2014 00:32:28 -0700 (PDT), m.a.m.hendrix@tue.nl wrote:

>> It is much faster than gforth but still slower than Java.
>>=20
>
>But much more important, the result is wrong.

It's a 32 bit overflow issue. Tested with a 32 bit version of
gforth-fast as well as VFX.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#29667

On 4/15/14, 9:32 AM, m.a.m.hendrix@tue.nl wrote:
> On Tuesday, April 15, 2014 4:18:49 AM UTC+2, Melzzzzz wrote:
>> On Mon, 14 Apr 2014 23:20:57 GMT
>>
> [..]
>>   VFX Forth for Linux IA32
>>   © MicroProcessor Engineering Ltd, 1998-2013
>>   Version: 4.62 [build 0522]
>>   Build date: 4 November 2013
>>   Free dictionary = 7900431 bytes [7715kb]
>>
>> Including ../Lib/Ndp387.fth
>> Including /home/bmaxa/examples/forth/cumul.fs
>
>> 238.09524
>> 555.55556
>> 262486571
>>
>> real	0m0.330s
>> user	0m0.313s
>> sys	0m0.016s
>>
>> It is much faster than gforth but still slower than Java.
>>
>
> But much more important, the result is wrong.
>
> -marcel
>
Original Java program used 32 bit int's, so result was
same, but I corrected it to use longs.

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

#29669

Melzzzzz <mel@zzzzz.invalid> writes:
>Including ../Lib/Ndp387.fth
>Including /home/bmaxa/examples/forth/cumul.fs
>238.09524=20
>555.55556=20
>262486571=20
>
>real	0m0.330s
>user	0m0.313s
>sys	0m0.016s
>
>
>It is much faster than gforth but still slower than Java.

Several things to note: 

1) The init takes longer than cumul, probably
mostly due to the division; if a compiler optimizes the division by
three, it will look significantly faster in this benchmark, but does
that transfer to other programs?

2) Note the significant proportion of system time, due to the need to
allocate 50MB of memory.

I tried this on a slower, simpler CPU (AMD E450), and compared the
three variants I posted earlier:

                  ticks it/tick
Melzzzzz cumul      440 113636.36 
  Paysan cumul      530 94339.623 
    Ertl cumul      400 125000. 

To check my theory that the large array size makes things mostly
memory-bound, I changed the benchmark to run repeatedly on a 2000-cell
array, same number of total iterations:

                  ticks it/tick
Melzzzzz cumul      410 121951.22 
  Paysan cumul      380 131578.95 
    Ertl cumul      450 111111.11 

Does not look like my memory-bound idea is actually true, and I don't
know how to explain the variations (especially why Paysan is slower
with a big array, but faster with a small one).

Let's look at a bigger CPU (Xeon 5450, like a Core 2 Quad):

With array size N=50M I get:

                  ticks it/tick
Melzzzzz cumul      170 294117.65 
  Paysan cumul      160 312500. 
    Ertl cumul      150 333333.33 

With array size N=2000 I get:

                  ticks it/tick
Melzzzzz cumul      140 357142.86 
  Paysan cumul      140 357142.86 
    Ertl cumul      150 333333.33 

Program below, invocation with

vfxlin "include /usr/share/doc/VfxForth/Lib/Ndp387.fth include cumul.fs bye"

- anton
---------------------
: iters 50000000 ;
: N 2000 ;

: init_cumul
	N 0 ?do
	i 3 / i +
	over i cells + !
	loop ;
	
: cumul 
    dup @ 
    N 1 ?do
        over i cells + @
        + 2dup
        swap i cells + !
    loop 
    drop ;

: bench ( addr xt -- addr )
    2dup (ticks) 0
    iters N / 0 ?do
        2over execute drop
    loop
    (ticks) 0
    2swap d- 2dup 8 d.r space d>f iters s>f fswap f/ f. cr 2drop drop ;

: cumul-paysan ( addr -- addr )
    dup N 1- cells bounds ?do
	i @ i cell+ +!
    cell +loop ;

: cumul-ertl ( addr -- addr )
  0 over N cells bounds ?do
    i @ + dup i !
  cell +loop 
  drop ;
    
N cells allocate throw
cr
\ ."           init " ' init_cumul bench
init_cumul
."                   ticks it/tick" cr
." Melzzzzz cumul " ' cumul bench
."   Paysan cumul " ' cumul-paysan bench
."     Ertl cumul " ' cumul-ertl bench
dup N 1 - cells + @ . cr
free throw

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

#29670

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Does not look like my memory-bound idea is actually true, and I don't
> know how to explain the variations (especially why Paysan is slower
> with a big array, but faster with a small one).

I've been wondering about this too-- one idea is that the serial
bandwidth of modern DRAM is tremendous, and maybe there is some cache
preloading happening in the cpu, so big and small arrays don't end up
that much different.  With random access the big array might be
much slower.  

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

#29671

On Tue, 15 Apr 2014 09:00:43 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > Does not look like my memory-bound idea is actually true, and I
> > don't know how to explain the variations (especially why Paysan is
> > slower with a big array, but faster with a small one).
> 
> I've been wondering about this too-- one idea is that the serial
> bandwidth of modern DRAM is tremendous, and maybe there is some cache
> preloading happening in the cpu, so big and small arrays don't end up
> that much different.  With random access the big array might be
> much slower.  

Exactly right. I have tested qsort on doubly linked list
and accessing nodes serially is faster than randomly.
Also in place sort (assigning values) instead of relinking nodes
results in much faster linked list eg traversing.
So if nodes are serially placed in memory it is much
faster than if nodes are randomly placed in memory.
Speed up was significant even with just 512kb of cache
on P4.

-- 
Click OK to continue...

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

#29672

On Tuesday, April 15, 2014 4:44:48 PM UTC+2, Anton Ertl wrote:
[..]
> With array size N=50M I get:
> 
>                   ticks it/tick
> Melzzzzz cumul      170 294117.65
>   Paysan cumul      160 312500.
>     Ertl cumul      150 333333.33
>
> With array size N=2000 I get:
>
>                   ticks it/tick
> Melzzzzz cumul      140 357142.86
>   Paysan cumul      140 357142.86
>     Ertl cumul      150 333333.33
[..]

On i7 920 compiled with 64bit iForth 5.0, I can 
duplicate this:

                  ticks it/tick
Melzzzzz cumul      154 324675.324675
  Paysan cumul      123 406504.065041
    Ertl cumul      116 431034.482759

N = 2000  ok

                  ticks it/tick
Melzzzzz cumul      116 431034.482759
  Paysan cumul      135 370370.370370
    Ertl cumul      127 393700.787402

N = 50000000  ok

-marcel

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

#29674

On Tue, 15 Apr 2014 14:44:48 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Melzzzzz <mel@zzzzz.invalid> writes:
> >Including ../Lib/Ndp387.fth
> >Including /home/bmaxa/examples/forth/cumul.fs
> >238.09524=20
> >555.55556=20
> >262486571=20
> >
> >real	0m0.330s
> >user	0m0.313s
> >sys	0m0.016s
> >
> >
> >It is much faster than gforth but still slower than Java.
> 
> Several things to note: 
> 
> 1) The init takes longer than cumul, probably
> mostly due to the division; if a compiler optimizes the division by
> three, it will look significantly faster in this benchmark, but does
> that transfer to other programs?
> 
> 2) Note the significant proportion of system time, due to the need to
> allocate 50MB of memory.
> 
> I tried this on a slower, simpler CPU (AMD E450), and compared the
> three variants I posted earlier:
> 
>                   ticks it/tick
> Melzzzzz cumul      440 113636.36 
>   Paysan cumul      530 94339.623 
>     Ertl cumul      400 125000. 
> 
> To check my theory that the large array size makes things mostly
> memory-bound, I changed the benchmark to run repeatedly on a 2000-cell
> array, same number of total iterations:
> 
>                   ticks it/tick
> Melzzzzz cumul      410 121951.22 
>   Paysan cumul      380 131578.95 
>     Ertl cumul      450 111111.11 
> 
> Does not look like my memory-bound idea is actually true, and I don't
> know how to explain the variations (especially why Paysan is slower
> with a big array, but faster with a small one).
> 
> Let's look at a bigger CPU (Xeon 5450, like a Core 2 Quad):
> 
> With array size N=50M I get:
> 
>                   ticks it/tick
> Melzzzzz cumul      170 294117.65 
>   Paysan cumul      160 312500. 
>     Ertl cumul      150 333333.33 

                  ticks it/tick
Melzzzzz cumul      100 500000. 
  Paysan cumul      100 500000. 
    Ertl cumul       90 555555.56 
-1300935111 

> 
> With array size N=2000 I get:
> 
>                   ticks it/tick
> Melzzzzz cumul      140 357142.86 
>   Paysan cumul      140 357142.86 
>     Ertl cumul      150 333333.33 
> 
                  ticks it/tick
Melzzzzz cumul      170 294117.65 
  Paysan cumul      100 500000. 
    Ertl cumul       80 625000. 
-204177195 

Machine is i5 3570k with 1600Mhz DDR3
-- 
Click OK to continue...

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

#29675

On Tue, 15 Apr 2014 14:44:48 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Melzzzzz <mel@zzzzz.invalid> writes:
> >Including ../Lib/Ndp387.fth
> >Including /home/bmaxa/examples/forth/cumul.fs
> >238.09524=20
> >555.55556=20
> >262486571=20
> >
> >real	0m0.330s
> >user	0m0.313s
> >sys	0m0.016s
> >
> >
> >It is much faster than gforth but still slower than Java.
> 
> Several things to note: 
> 
> 1) The init takes longer than cumul, probably
> mostly due to the division; if a compiler optimizes the division by
> three, it will look significantly faster in this benchmark, but does
> that transfer to other programs?

I think that vfxforth optimizes division by three as on first run
it is slightly slower than Java but on second run it is faster.

N 50000000

                  ticks it/tick
          init      220 227272.73 
Melzzzzz cumul      100 500000. 
          init      140 357142.86 
  Paysan cumul      100 500000. 
          init      140 357142.86 
    Ertl cumul       80 625000. 
262486571

N 2000

                  ticks it/tick
          init      200 250000. 
Melzzzzz cumul      110 454545.45 
          init      140 357142.86 
  Paysan cumul       90 555555.56 
          init      140 357142.86 
    Ertl cumul       80 625000. 
-991186997 

-- 
Click OK to continue...

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

#29679

Melzzzzz <mel@zzzzz.com> writes:
>I think that vfxforth optimizes division by three as on first run
>it is slightly slower than Java but on second run it is faster.

It doesn't; inner loop of init_cumul:

( 080C53B0    8B1424 )                MOV       EDX, [ESP]
( 080C53B3    B903000000 )            MOV       ECX, 00000003
( 080C53B8    8BC2 )                  MOV       EAX, EDX
( 080C53BA    99 )                    CDQ
( 080C53BB    F7F9 )                  IDIV      ECX
( 080C53BD    8B1424 )                MOV       EDX, [ESP]
( 080C53C0    03D0 )                  ADD       EDX, EAX
( 080C53C2    8B0C24 )                MOV       ECX, [ESP]
( 080C53C5    89148B )                MOV       [EBX+ECX*4], EDX
( 080C53C8    83042401 )              ADD       [ESP], 01
( 080C53CC    8344240401 )            ADD       [ESP+04], 01
( 080C53D1    71DD )                  JNO       080C53B0

Maybe the slower execution of the first init is due to the CPU being
lower-clocked at first (if ticks measure real time, not CPU clocks).

In any case, the volatile results indicate that you cannot draw any
conclusions from small performance differences on such a small
benchmark; they don't even predict relative performance of the same
benchmarks on a different data size, not even qualitatively.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#29590

On Saturday, April 12, 2014 7:11:11 PM UTC+2, Melzzzzz wrote:
> Seems that Java bits Forth in optimizing tight loops. Eg division by
> constant optimization is performed automatically.
[..]

Paraphrased:

ANEW -cumul

#50000000 =: N 
N CELLS ALLOCATE ?ALLOCATE =: addr

: init_cumul ( -- ) addr  N 0 ?DO  I 3 / I +   SWAP !+   LOOP DROP ; 
         
: cumul ( -- )
	addr @+ ( [a] a -- )
	N 1 ?DO 
		OVER @ + DUP ( a [a]+x [a]+x -- )
		ROT !+ ( [a]+x a2 -- )	SWAP
	   LOOP 2DROP ; 

: bench ( xt -- ) 
	TIMER-RESET 
	EXECUTE   
	MS? S>F  N S>F  F/  CR F.N1 ." s/op, "  .ELAPSED ; 

  ' init_cumul bench 
  ' cumul      bench 
CR addr N 1- CELL[] @ .  
   addr FREE ?ALLOCATE

\ 3.68 us/op, 0.186 seconds elapsed.
\ 2.16 us/op, 0.109 seconds elapsed.
\ 1666666616666667  ok

I guess Java programmers are paid per LOC.

-marcel

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

#29591

On Saturday, April 12, 2014 10:01:53 PM UTC+2, m...@iae.nl wrote:
> On Saturday, April 12, 2014 7:11:11 PM UTC+2, Melzzzzz wrote:
[..]
Oh yeah, division optimization ...
$01224000  : init_cumul
$0122400A  push          $1B040050 d#
$0122400F  mov           rcx, $02FAF080 d#
$01224016  xor           rbx, rbx
$01224019  call          (?DO) offset NEAR
$01224023  lea           rax, [rax 0 +] qword
$01224028  mov           rdi, [rbp 0 +] qword
$0122402C  mov           rcx, rbx
$0122402F  mov           rbx, rdi
$01224032  mov           r8, rbx
$01224035  sar           r8, #63 b#
$01224039  xor           rbx, r8
$0122403C  sub           rbx, r8
$0122403F  xchg          rdx, rbx
$01224042  mov           rax, $55555555:55555556 q#
$0122404C  mul           rdx
$0122404F  xchg          rdx, rbx
$01224052  xor           rbx, r8
$01224055  sub           rbx, r8
$01224058  mov           rdi, [rbp 0 +] qword
$0122405C  lea           rax, [rbx rdi*1] qword
$01224060  mov           [rcx] qword, rax
$01224063  lea           rbx, [rcx 8 +] qword
$01224067  add           [rbp 0 +] qword, 1 b#
$0122406C  add           [rbp 8 +] qword, 1 b#
$01224071  jno           $01224028 offset NEAR
$01224077  add           rbp, #24 b#
$0122407B  ;

-marcel

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

#29596

mhx@iae.nl writes:
>   MS? S>F  N S>F  F/  CR F.N1 ." s/op, "  .ELAPSED ; 
> ...
> \ 3.68 us/op, 0.186 seconds elapsed.
> \ 2.16 us/op, 0.109 seconds elapsed.

What kind of hardware is that?  What does F.N1 do?  Is that compiled
with all the iforth optimizations?

The C++ and Java versions on that web page got around 0.005 usec/op,
about 2 ghz, and I just got around the same in a C version that I tried.
I think it is basically measuring the speed of sequential memory
transfer.  I get approx the same ops/sec on a 2.6 ghz machine and on a
3.1 ghz machine with similar architecture.

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

#29601

Paul Rubin <no.email@nospam.invalid> writes Re: Forth vs Java in calculating partial sum ;)
>>   MS? S>F  N S>F  F/  CR F.N1 ." s/op, "  .ELAPSED ; 
>> ...
>> \ 3.68 us/op, 0.186 seconds elapsed.
>> \ 2.16 us/op, 0.109 seconds elapsed.

> What kind of hardware is that?  

You are quoting an old and subsequently corrected posting. 
The actual result on an i7 920 @ 2.66 GHz with iForth 5.0 is

\ 3.68 ns/op, 0.186 seconds elapsed.
\ 2.16 ns/op, 0.109 seconds elapsed.

>                                What does F.N1 do?  Is that compiled
> with all the iforth optimizations?

If this were a contest I could do more :-)

( F: r -- ) F.N1 prints r in the shortest electrical engineering form, e.g.
FORTH> 1e-15 f.n1  1 f ok
FORTH> 1e-21 f.n1  1 y ok
FORTH> 1e+17 f.n1  100 P ok
FORTH> pi f.n1  3.141592   ok

> The C++ and Java versions on that web page got around 0.005 usec/op,
> about 2 ghz, and I just got around the same in a C version that I tried.

That is 5 ns/op or about twice slower than what I get on the i7.

> I think it is basically measuring the speed of sequential memory
> transfer.  I get approx the same ops/sec on a 2.6 ghz machine and on a
> 3.1 ghz machine with similar architecture.

By unrolling I can improve the figures above to

  3.02 ns/op, 0.153 seconds elapsed.
  1.1 ns/op, 0.057 seconds elapsed.
  1666666616666667  ok

-marcel

---
ANEW -cumul

#50000000 =: N 
N CELLS ALLOCATE ?ALLOCATE =: addr

: init_cumul ( -- ) 
	addr  N 0 ?DO   
			I       3 / I       +   SWAP !+   
			I   1 + 3 / I   1 + +   SWAP !+   
			I   2 + 3 / I   2 + +   SWAP !+   
			I   3 + 3 / I   3 + +   SWAP !+   

			I   4 + 3 / I   4 + +   SWAP !+   
			I   5 + 3 / I   5 + +   SWAP !+   
			I   6 + 3 / I   6 + +   SWAP !+   
			I   7 + 3 / I   7 + +   SWAP !+   
	      8 +LOOP 
	DROP ; 
         
: cumul ( -- )
	addr @+ ( [a] a -- )
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP

		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP
	N 8 ?DO 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 

		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
		OVER @ + DUP ( a [a]+x [a]+x -- ) ROT !+ SWAP 
	8 +LOOP 2DROP ; 

: bench ( xt -- ) 
	TIMER-RESET 
	EXECUTE   
	MS? S>F 1e-3 F* N S>F  F/  CR F.N1 ." s/op, "  .ELAPSED ; 

  ' init_cumul bench 
  ' cumul      bench 
CR addr N 1- CELL[] @ .  
   addr FREE ?ALLOCATE

\ 3.02 ns/op, 0.153 seconds elapsed.
\ 1.1 ns/op, 0.057 seconds elapsed.
\ 1666666616666667  ok

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

#29603

mhx@iae.nl writes:
>> The C++ and Java versions on that web page got around 0.005 usec/op,
>> about 2 ghz, and I just got around the same in a C version that I tried.
>
> That is 5 ns/op or about twice slower than what I get on the i7.

Sorry, meant 0.0005 us (0.5 ns or 2 ghz).  But I think the speed is
limited by memory, so stuff like loop unrolling is unlikely to help.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web