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

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

ANN: matmul package available

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

Contents

  ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-19 10:43 +0000
    Re: ANN: matmul package available krishna.myneni@ccreweb.org - 2017-05-19 05:20 -0700
      Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-19 14:16 +0000
        Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-19 08:28 -0700
          Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-20 05:25 -0700
          Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-20 13:23 +0000
            Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-20 08:43 -0700
              Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-20 16:02 +0000
                Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-20 11:36 -0700
                  Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-21 07:52 +0000
                    Re: ANN: matmul package available mhx@iae.nl - 2017-05-21 03:28 -0700
                      Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-21 05:32 -0700
                        Re: ANN: matmul package available mhx@iae.nl - 2017-05-21 05:52 -0700
                          Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-21 07:54 -0700
                            Re: ANN: matmul package available mhx@iae.nl - 2017-05-21 08:32 -0700
                              Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-21 11:24 -0700
                      Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-21 13:52 +0000
                        Re: ANN: matmul package available mhx@iae.nl - 2017-05-21 08:47 -0700
                          Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-22 09:50 +0000
                            Re: ANN: matmul package available pahihu <pahihu@gmail.com> - 2017-05-22 07:14 -0700
                              Re: ANN: matmul package available mhx@iae.nl - 2017-05-22 07:39 -0700
                              Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-23 10:06 +0000
    Re: ANN: matmul package available albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-19 17:00 +0200
      Re: ANN: matmul package available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-20 13:59 +0000

Page 1 of 2  [1] 2  Next page →

#59543 — ANN: matmul package available

If you just want to multiply matrices, or if you want to see how
various systems perform on your hardware on the matrix multiplication
benchmark that I have posted about during the last week, you may be
interested in

<http://theforth.net/package/matmul>

It contains the actual matrix multiplication code (matmul.4th), as
well as some Forth-2012 extension implementations (so it can run on
Forth-94 systems), and testing and benchmarking code.

One goal of this package is that everything works out of the box, with
no need to change any source files or to invest an hour or two to make
it work.  Please report any problems.

- 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 2017: http://www.euroforth.org/ef17/

[toc] | [next] | [standalone]

#59546

On Friday, May 19, 2017 at 6:33:46 AM UTC-5, Anton Ertl wrote:
> If you just want to multiply matrices, ...

A word named MATMUL suggests general applicability for multiplying matrices, while your implementation has restrictions, namely for those cases where the output matrix C is square. In general, a matrix multiplication word should not restrict the number of columns for matrix B, to be equal to the number of rows for matrix A.

Krishna

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

#59549

krishna.myneni@ccreweb.org writes:
>A word named MATMUL suggests general applicability for multiplying matrices=
>, while your implementation has restrictions, namely for those cases where =
>the output matrix C is square. In general, a matrix multiplication word sho=
>uld not restrict the number of columns for matrix B, to be equal to the num=
>ber of rows for matrix A.

Thank you.  Now version 2.0.0 is online
<http://theforth.net/package/matmul>, which defines

matmulr ( a b c n1 n2 n3 -- )

A has n1 rows and n2 columns, B has n2 rows and n3 columns, and C has
n1 rows and n3 columns.

Users of version 1 can still download it at
<http://theforth.net/package/matmul/1.0.2> but are encouraged to
switch to version 2 and replace uses of MATMUL with TUCK MATMULR.

- 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 2017: http://www.euroforth.org/ef17/

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

#59552

This is about 15% faster using gforth-fast on Intel.

pahihu

: faxpy-nostride ( ra f_x f_y ucount -- )
    \ vy=ra*vx+vy
    dup >r 3 and ?dup IF
        0 do
            swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
        loop
        swap
    THEN
    r> 2 rshift 0 ?do
        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
    loop
    2drop fdrop ;

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

#59592

2017. május 19., péntek 17:28:02 UTC+2 időpontban pahihu a következőt írta:
> This is about 15% faster using gforth-fast on Intel.

Wearing my standard Forth jacket, the final gforth version is here.
The results are from on an old Core2 @ 1.6GHz:

0.40 real   0.38 user   0.01 sys    use Gforth's primitive FAXPY
1.99 real   1.97 user   0.01 sys    Forth-2012 by pahihu with unrolling <==
2.14 real   2.11 user   0.01 sys    Forth-2012 by pahihu, no unrolling <==
2.32 real   2.29 user   0.01 sys    Forth-2012, no unrolling
2.40 real   2.36 user   0.01 sys    Forth-2012 with unrolling
2.44 real   2.42 user   0.01 sys    Forth-94 by pahihu with unrolling
2.58 real   2.55 user   0.01 sys    Forth-94 by pahihu, no unrolling
2.65 real   2.62 user   0.01 sys    Forth-94 by Rees/Ertl with unrolling
2.71 real   2.68 user   0.01 sys    Forth-94 by Rees/Ertl, no unrolling

: faxpy-nostride ( ra f_x f_y ucount -- )
    \ vy=ra*vx+vy
    0 ?do
        swap fdup dup f@ float+ f* swap dup f@ dup f+ f! float+
    loop
    2drop fdrop ;

pahihu

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

#59597

pahihu <pahihu@gmail.com> writes:
>This is about 15% faster using gforth-fast on Intel.
>
>pahihu
>
>: faxpy-nostride ( ra f_x f_y ucount -- )
>    \ vy=ra*vx+vy
>    dup >r 3 and ?dup IF
>        0 do
>            swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
>        loop
>        swap
>    THEN
>    r> 2 rshift 0 ?do
>        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
>        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
>        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
>        swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+
>    loop
>    2drop fdrop ;

Interesting:

cycles insts
2220M  7730M  fdup over f@ f* dup f@ f+ dup f! float+ swap float+ swap
1989M  7730M  swap fdup dup f@ f* float+ swap dup f@ f+ dup f! float+ 
1988M  7730M  fdup swap dup f@ f* float+ swap dup f@ f+ dup f! float+ 

So the number of instructions is the same, but your variant performs
better (and 3.89 instructions per cycle is pretty close to the speed
of light on this CPU).  Do you have an explanation for that, or was
this based on just trying different variants?

However, VFX and SwiftForth are slightly slower with variants 2 and 3,
and given that the default for Gforth does not use this code, I'll
stick with variant 1 for the matmul package.

- 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 2017: http://www.euroforth.org/ef17/

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

#59600

2017. május 20., szombat 15:54:11 UTC+2 időpontban Anton Ertl a következőt írta:
> Do you have an explanation for that, or was
> this based on just trying different variants?

I wanted to eliminate "OVER" and this was faster.
Just for reference on this particular machine the Gforth FAXPY primitive
compared to Forth-94/Forth-2012 versions on iForth 5 (which optimizes the 
return stack access very well):

Gforth   FAXPY   294

Pahi-12u UNTIL  295
Pahi-94u stack   299
Ertl-12u ------    305
Pahi-12u Gforth  308

> However, VFX and SwiftForth are slightly slower with variants 2 and 3,
> and given that the default for Gforth does not use this code, I'll
> stick with variant 1 for the matmul package.

Sure, variant 1 is gforth specific, ie non-standard.
Why not provide non-standard versions then for VFX and SwiftForth ?

pahihu

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

#59602

pahihu <pahihu@gmail.com> writes:
>2017. m=C3=A1jus 20., szombat 15:54:11 UTC+2 id=C5=91pontban Anton Ertl a k=
>=C3=B6vetkez=C5=91t =C3=ADrta:
>Just for reference on this particular machine the Gforth FAXPY primitive
>compared to Forth-94/Forth-2012 versions on iForth 5 (which optimizes the=
>=20
>return stack access very well):
>
>Gforth   FAXPY   294
>
>Pahi-12u UNTIL  295
>Pahi-94u stack   299
>Ertl-12u ------    305
>Pahi-12u Gforth  308

This table is not self-explanatory enough.  What do the columns mean?

>> However, VFX and SwiftForth are slightly slower with variants 2 and 3,
>> and given that the default for Gforth does not use this code, I'll
>> stick with variant 1 for the matmul package.
>
>Sure, variant 1 is gforth specific, ie non-standard.

Ah, posting editing mistake.  I meant that, for faxpy-nostride-variant
2 and 4, I decided to stick with the first (i.e., original) of the
three variants I showed in that posting, because it performs better on
VFX and SwiftForth, and does not affect the default for Gforth.

>Why not provide non-standard versions then for VFX and SwiftForth ?

Who is going to write them?  

FAXPY has been part of Gforth since 0.5.0 in 2000, and using it to
write FAXPY-NOSTRIDE was pretty simple, and I also wanted to see how
close the Forth systems are to this C-compiled code.

But thinking about it, using F+!, which is present in both VFX and
SwiftForth, provides an opportunity for both.  Let's see how it works
(if it's not there, it is replaced by a colon definition):

cycles
Forth-2012 Forth-2012
no f+!     with f+!
 1046M     1048M      vfxlin Ndp387.fth
 2220M     2484M      gforth-fast
 4844M     3584M      SwiftForth HW stack, no WAIT

VFX's compiler is so good that the F+! primitive does not buy
anything, but SwiftForth gets a good benefit out of it.  New version
uploaded.

- 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 2017: http://www.euroforth.org/ef17/

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

#59606

2017. május 20., szombat 18:47:51 UTC+2 időpontban Anton Ertl a következőt írta:
> >Gforth   FAXPY   294
> >
> >Pahi-12u UNTIL  295
> >Pahi-94u stack   299
> >Ertl-12u ------    305
> >Pahi-12u Gforth  308
> 
> This table is not self-explanatory enough.  What do the columns mean?

Last column in milliseconds, first and second describes the version:

Gforth FAXPY
- FAXPY primitive in Gforth

Pahi-12u UNTIL
- unrolled Forth-2012 version using BEGIN ... UNTIL instead of ?DO ... LOOP

Pahi-94u stack
- unrolled Forth-94 version, does not use faxpy-ra helper variable,
  everything is on the stack

Ertl-12u ------
- your unrolled Forth-2012 version

Pahi-12u Gforth
- unrolled Forth-2012 version, which I posted here for gforth-fast


pahihu

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

#59638

pahihu <pahihu@gmail.com> writes:
>2017. m=C3=A1jus 20., szombat 18:47:51 UTC+2 id=C5=91pontban Anton Ertl a k=
>=C3=B6vetkez=C5=91t =C3=ADrta:
>> >Gforth   FAXPY   294
>> >
>> >Pahi-12u UNTIL  295
>> >Pahi-94u stack   299
>> >Ertl-12u ------    305
>> >Pahi-12u Gforth  308
>>=20
>> This table is not self-explanatory enough.  What do the columns mean?
>
>Last column in milliseconds, first and second describes the version:

So iforth is about as fast on FAXPY-NOSTRIDE (all versions) as gcc is
on FAXPY.  Impressive!

- 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 2017: http://www.euroforth.org/ef17/

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

#59640

On Sunday, May 21, 2017 at 9:55:08 AM UTC+2, Anton Ertl wrote:
> pahihu <pahihu@gmail.com> writes:
> >2017. m=C3=A1jus 20., szombat 18:47:51 UTC+2 id=C5=91pontban Anton Ertl a k=
> >=C3=B6vetkez=C5=91t =C3=ADrta:
> >> >Gforth   FAXPY   294
> >> >
> >> >Pahi-12u UNTIL  295
> >> >Pahi-94u stack   299
> >> >Ertl-12u ------    305
> >> >Pahi-12u Gforth  308
> >>
> >> This table is not self-explanatory enough.  What do the columns mean?
> >
> >Last column in milliseconds, first and second describes the version:
>
> So iforth is about as fast on FAXPY-NOSTRIDE (all versions) as gcc is
> on FAXPY.  Impressive!

I'm sorry, but it gets extremely confusing with all these
indirect references and changes. Is gcc (in gForth) using SSE2
and auto-vectorizing, or is it forced to use the FPU? If the
latter, a range of only 10 - 30% is to be expected. If the
former, we would ideally find a 4x speedup of gcc, unless we
go out of cache.

IMHO in practical programs matrix/vector math should not be
the bottleneck at all (e.g. in SPICE only ~25% of the time
is spent in the sparse solver). SPICE seems to be written
by people who were very fond of linked lists, 10-deep
nested structures and 15 page long functions.

-marcel

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

#59647

2017. május 21., vasárnap 12:28:49 UTC+2 időpontban m...@iae.nl a következőt írta:
> I'm sorry, but it gets extremely confusing with all these
> indirect references and changes. Is gcc (in gForth) using SSE2
> and auto-vectorizing, or is it forced to use the FPU? If the
> latter, a range of only 10 - 30% is to be expected. If the
> former, we would ideally find a 4x speedup of gcc, unless we
> go out of cache.

Take this discussion as an excercise, how far can we get writing high-level
Forth code and compiling with an optimizing Forth compiler.

GCC on FAXPY means here the FAXPY primitive in the gforth-0.7.9-20170427
source.  The generated assembler code:

_faxpy:
LFB2:
    pushq   %rbp
LCFI0:
    movq    %rsp, %rbp
LCFI1:
    movapd  %xmm0, %xmm1
    movq    %r8, %rax
    testq   %r8, %r8
    je  L5
L4:
    movapd  %xmm1, %xmm0
    mulsd   (%rdi), %xmm0
    addsd   (%rdx), %xmm0
    movsd   %xmm0, (%rdx)
    addq    %rsi, %rdi
    addq    %rcx, %rdx
    decq    %rax
    jne L4
L5:
    leave
    ret

For reference in iForth5 the GotoBLAS DAXPY runs at 131 ms.

> SPICE seems to be written
> by people who were very fond of linked lists, 10-deep
> nested structures and 15 page long functions.

That's why we did not use the SPICE sources in the '90s to
implement thermal feedback in the electrical simulation ;)

pahihu

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

#59649

On Sunday, May 21, 2017 at 2:32:38 PM UTC+2, pahihu wrote:
> 2017. május 21., vasárnap 12:28:49 UTC+2 időpontban m...@iae.nl a következőt írta:
> > I'm sorry, but it gets extremely confusing with all these
> > indirect references and changes. Is gcc (in gForth) using SSE2
> > and auto-vectorizing, or is it forced to use the FPU? If the
> > latter, a range of only 10 - 30% is to be expected. If the
> > former, we would ideally find a 4x speedup of gcc, unless we
> > go out of cache.
> 
> Take this discussion as an excercise, how far can we get writing high-level
> Forth code and compiling with an optimizing Forth compiler.
> 
> GCC on FAXPY means here the FAXPY primitive in the gforth-0.7.9-20170427
> source.  The generated assembler code:
> 
> _faxpy:
> LFB2:
>     pushq   %rbp
> LCFI0:
>     movq    %rsp, %rbp
> LCFI1:
>     movapd  %xmm0, %xmm1
>     movq    %r8, %rax
>     testq   %r8, %r8
>     je  L5
> L4:
>     movapd  %xmm1, %xmm0
>     mulsd   (%rdi), %xmm0
>     addsd   (%rdx), %xmm0
>     movsd   %xmm0, (%rdx)
>     addq    %rsi, %rdi
>     addq    %rcx, %rdx
>     decq    %rax
>     jne L4
> L5:
>     leave
>     ret
> 
> For reference in iForth5 the GotoBLAS DAXPY runs at 131 ms.
[..] 

Not sure if it is already in iForth5 (we *do* continue
development :-)

FORTH> see DAXPY_sse2
Flags:
$0123B6C8  pop           rbx
$0123B6C9  lea           rbp, [rbp -8 +] qword
$0123B6CD  mov           [rbp 0 +] qword, rbx
$0123B6D1  fpop,
$0123B6DB  sub           rsp, 8 b#
$0123B6DF  fstp          [rsp] qword
$0123B6E2  movsd         xmm7, [rsp] xmmword
$0123B6E7  movhps        xmm7, xmm7
$0123B6EA  add           rsp, 8 b#
$0123B6EE  pop           rcx
$0123B6EF  pop           rbx
$0123B6F0  pop           rax
$0123B6F1  mov           rdx, rcx
$0123B6F4  shr           rdx, 1 b#
$0123B6F8  and           rdx, 7 b#
$0123B6FC  je            $0123B83E offset NEAR
$0123B702  movupd        xmm6, [rax] xmmword
$0123B706  movupd        xmm8, [rbx] xmmword
$0123B70B  mulpd         xmm6, xmm7
$0123B70F  addpd         xmm6, xmm8
$0123B714  movupd        [rbx] xmmword, xmm6
$0123B718  cmp           rdx, 3 b#
$0123B71C  jg            $0123B77F offset SHORT
$0123B71E  jne           $0123B757 offset SHORT
$0123B720  movupd        xmm5, [rax #16 +] xmmword
$0123B725  movupd        xmm8, [rbx #16 +] xmmword
$0123B72B  mulpd         xmm5, xmm7
$0123B72F  addpd         xmm5, xmm8
$0123B734  movupd        [rbx #16 +] xmmword, xmm5
$0123B739  movupd        xmm4, [rax #32 +] xmmword
$0123B73E  movupd        xmm8, [rbx #32 +] xmmword
$0123B744  mulpd         xmm4, xmm7
$0123B748  addpd         xmm4, xmm8
$0123B74D  movupd        [rbx #32 +] xmmword, xmm4
$0123B752  jmp           $0123B83E offset NEAR
$0123B757  cmp           rdx, 2 b#
$0123B75B  jl            $0123B83E offset NEAR
$0123B761  movupd        xmm5, [rax #16 +] xmmword
$0123B766  movupd        xmm8, [rbx #16 +] xmmword
$0123B76C  mulpd         xmm5, xmm7
$0123B770  addpd         xmm5, xmm8
$0123B775  movupd        [rbx #16 +] xmmword, xmm5
$0123B77A  jmp           $0123B83E offset NEAR
$0123B77F  movupd        xmm3, [rax #48 +] xmmword
$0123B784  movupd        xmm8, [rbx #48 +] xmmword
$0123B78A  mulpd         xmm3, xmm7
$0123B78E  movupd        xmm4, [rax #32 +] xmmword
$0123B793  addpd         xmm3, xmm8
$0123B798  movupd        [rbx #48 +] xmmword, xmm3
$0123B79D  mulpd         xmm4, xmm7
$0123B7A1  movupd        xmm8, [rbx #32 +] xmmword
$0123B7A7  movupd        xmm5, [rax #16 +] xmmword
$0123B7AC  addpd         xmm4, xmm8
$0123B7B1  movupd        [rbx #32 +] xmmword, xmm4
$0123B7B6  movupd        xmm8, [rbx #16 +] xmmword
$0123B7BC  mulpd         xmm5, xmm7
$0123B7C0  addpd         xmm5, xmm8
$0123B7C5  movupd        [rbx #16 +] xmmword, xmm5
$0123B7CA  cmp           rdx, 5 b#
$0123B7CE  jg            $0123B7ED offset SHORT
$0123B7D0  jne           $0123B83E offset SHORT
$0123B7D2  movupd        xmm2, [rax #64 +] xmmword
$0123B7D7  movupd        xmm8, [rbx #64 +] xmmword
$0123B7DD  mulpd         xmm2, xmm7
$0123B7E1  addpd         xmm2, xmm8
$0123B7E6  movupd        [rbx #64 +] xmmword, xmm2
$0123B7EB  jmp           $0123B83E offset SHORT
$0123B7ED  movupd        xmm1, [rax #80 +] xmmword
$0123B7F2  mulpd         xmm1, xmm7
$0123B7F6  movupd        xmm8, [rbx #80 +] xmmword
$0123B7FC  movupd        xmm2, [rax #64 +] xmmword
$0123B801  addpd         xmm1, xmm8
$0123B806  movupd        [rbx #80 +] xmmword, xmm1
$0123B80B  movupd        xmm8, [rbx #64 +] xmmword
$0123B811  mulpd         xmm2, xmm7
$0123B815  addpd         xmm2, xmm8
$0123B81A  movupd        [rbx #64 +] xmmword, xmm2
$0123B81F  cmp           rdx, 6 b#
$0123B823  je            $0123B83E offset SHORT
$0123B825  movupd        xmm0, [rax #96 +] xmmword
$0123B82A  movupd        xmm8, [rbx #96 +] xmmword
$0123B830  mulpd         xmm0, xmm7
$0123B834  addpd         xmm0, xmm8
$0123B839  movupd        [rbx #96 +] xmmword, xmm0
$0123B83E  shl           rdx, 4 b#
$0123B842  sub           rdx, #64 b#
$0123B846  add           rbx, rdx
$0123B849  add           rax, rdx
$0123B84C  mov           rdx, rcx
$0123B84F  shr           rcx, 4 b#
$0123B853  je            $0123B9A9 offset NEAR
$0123B859  movupd        xmm2, [rax #96 +] xmmword
$0123B85E  movupd        xmm8, [rbx #96 +] xmmword
$0123B864  mulpd         xmm2, xmm7
$0123B868  movupd        xmm1, [rax #80 +] xmmword
$0123B86D  movupd        xmm0, [rax #64 +] xmmword
$0123B872  mulpd         xmm1, xmm7
$0123B876  addpd         xmm2, xmm8
$0123B87B  jmp           $0123B8E2 offset NEAR
$0123B880  movupd        xmm3, [rax #48 +] xmmword
$0123B885  mulpd         xmm0, xmm7
$0123B889  movupd        xmm8, [rbx #16 +] xmmword
$0123B88F  movupd        [rbx #32 +] xmmword, xmm2
$0123B894  addpd         xmm1, xmm8
$0123B899  movupd        xmm2, [rax #96 +] xmmword
$0123B89E  mulpd         xmm3, xmm7
$0123B8A2  movupd        xmm8, [rbx] xmmword
$0123B8A7  movupd        [rbx #16 +] xmmword, xmm1
$0123B8AC  addpd         xmm0, xmm8
$0123B8B1  movupd        xmm1, [rax #80 +] xmmword
$0123B8B6  mulpd         xmm2, xmm7
$0123B8BA  movupd        xmm8, [rbx #48 +] xmmword
$0123B8C0  movupd        [rbx] xmmword, xmm0
$0123B8C4  addpd         xmm3, xmm8
$0123B8C9  movupd        xmm0, [rax #64 +] xmmword
$0123B8CE  mulpd         xmm1, xmm7
$0123B8D2  movupd        xmm8, [rbx #96 +] xmmword
$0123B8D8  movupd        [rbx #48 +] xmmword, xmm3
$0123B8DD  addpd         xmm2, xmm8
$0123B8E2  movupd        xmm3, [rax #112 +] xmmword
$0123B8E7  mulpd         xmm0, xmm7
$0123B8EB  movupd        xmm8, [rbx #80 +] xmmword
$0123B8F1  movupd        [rbx #96 +] xmmword, xmm2
$0123B8F6  addpd         xmm1, xmm8
$0123B8FB  movupd        xmm2, [rax #160 +] xmmword
$0123B903  mulpd         xmm3, xmm7
$0123B907  movupd        xmm8, [rbx #64 +] xmmword
$0123B90D  movupd        [rbx #80 +] xmmword, xmm1
$0123B912  addpd         xmm0, xmm8
$0123B917  movupd        xmm1, [rax #144 +] xmmword
$0123B91F  mulpd         xmm2, xmm7
$0123B923  movupd        xmm8, [rbx #112 +] xmmword
$0123B929  movupd        [rbx #64 +] xmmword, xmm0
$0123B92E  addpd         xmm3, xmm8
$0123B933  movupd        xmm0, [rax #128 +] xmmword
$0123B93B  mulpd         xmm1, xmm7
$0123B93F  movupd        xmm8, [rbx #160 +] xmmword
$0123B948  movupd        [rbx #112 +] xmmword, xmm3
$0123B94D  addpd         xmm2, xmm8
$0123B952  add           rbx, #128 d#
$0123B959  add           rax, #128 d#
$0123B960  dec           rcx
$0123B963  jne           $0123B880 offset NEAR
$0123B969  movupd        xmm3, [rax #48 +] xmmword
$0123B96E  mulpd         xmm0, xmm7
$0123B972  movupd        xmm8, [rbx #16 +] xmmword
$0123B978  movupd        [rbx #32 +] xmmword, xmm2
$0123B97D  addpd         xmm1, xmm8
$0123B982  mulpd         xmm3, xmm7
$0123B986  movupd        xmm8, [rbx] xmmword
$0123B98B  movupd        [rbx #16 +] xmmword, xmm1
$0123B990  addpd         xmm0, xmm8
$0123B995  movupd        xmm8, [rbx #48 +] xmmword
$0123B99B  movupd        [rbx] xmmword, xmm0
$0123B99F  addpd         xmm3, xmm8
$0123B9A4  movupd        [rbx #48 +] xmmword, xmm3
$0123B9A9  and           rdx, 1 b#
$0123B9AD  je            $0123B9C2 offset SHORT
$0123B9AF  movsd         xmm4, [rax #64 +] xmmword
$0123B9B4  mulsd         xmm4, xmm7
$0123B9B8  addsd         xmm4, [rbx #64 +] xmmword
$0123B9BD  movsd         [rbx #64 +] xmmword, xmm4
$0123B9C2  mov           rbx, [rbp 0 +] qword
$0123B9C6  lea           rbp, [rbp 8 +] qword
$0123B9CA  jmp           rbx

-marcel

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

#59654

2017. május 21., vasárnap 14:52:12 UTC+2 időpontban m...@iae.nl a következőt írta:
> 
> Not sure if it is already in iForth5 (we *do* continue
> development :-)

Yes it's here, in dfwforth/examples/asm/daxpy64.frt.

DAXPY    0.130 seconds elapsed.
DAXPY_1  0.301 seconds elapsed.
DAXPY_16 0.342 seconds elapsed.
DAXPY_sse2 0.097 seconds elapsed.

pahihu

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

#59661

On Sunday, May 21, 2017 at 4:54:47 PM UTC+2, pahihu wrote:
> 2017. május 21., vasárnap 14:52:12 UTC+2 időpontban m...@iae.nl a következőt írta:
> > 
> > Not sure if it is already in iForth5 (we *do* continue
> > development :-)
> 
> Yes it's here, in dfwforth/examples/asm/daxpy64.frt.
> 
> DAXPY    0.130 seconds elapsed.
> DAXPY_1  0.301 seconds elapsed.
> DAXPY_16 0.342 seconds elapsed.
> DAXPY_sse2 0.097 seconds elapsed.
> 
> pahihu

?? You have some nice hardware there!

DAXPY and SAXPY are calls to the ACML (on Windows7),
the others are CODE.

FORTH> BM
matrices of size 160 x 160, repeats = 10,000,000
DAXPY_1       1.342 seconds elapsed.
DAXPY_16      0.590 seconds elapsed.
DAXPY_sse2    0.401 seconds elapsed.
DAXPY_sse2UN  0.395 seconds elapsed.
DAXPY_sse2UN4 0.499 seconds elapsed.
DAXPY         0.810 seconds elapsed. ok

With some luck, twice faster than calling out to C.

FORTH> BMs
matrices of size 160 x 160, repeats = 10,000,000
SAXPY_sse2   0.234 seconds elapsed.
SAXPY_sse2UN 0.235 seconds elapsed.
SAXPY        0.645 seconds elapsed. ok

About 3 times better than ACML, but single floats, 
who needs them?

Run on OS: Windows 7 Service Pack 1
CPU: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz
Logical processors: 12
Total DRAM available = 32702.8 MB.

-marcel

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

#59682

2017. május 21., vasárnap 17:32:59 UTC+2 időpontban m...@iae.nl a következőt írta:
> ?? You have some nice hardware there!

Nope ;)
Comparing apples to apples:

FORTH> BM
matrices of size 160 x 160, repeats = 10,000,000 
DAXPY_1       4.176 seconds elapsed.
DAXPY_16      4.747 seconds elapsed.
DAXPY_sse2    1.376 seconds elapsed.
DAXPY_sse2UN  4.306 seconds elapsed.
DAXPY_sse2UN4 4.524 seconds elapsed.
DAXPY         2.434 seconds elapsed. ok
FORTH> BMs 
matrices of size 160 x 160, repeats = 10,000,000 
SAXPY_sse2   0.784 seconds elapsed.
SAXPY_sse2UN 4.758 seconds elapsed.
SAXPY        1.904 seconds elapsed. ok

Run on:
macOS 10.11.6
Core 2 Duo 1.4GHz SU9400
2 cores
2GB RAM

pahihu

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

#59651

mhx@iae.nl writes:
>On Sunday, May 21, 2017 at 9:55:08 AM UTC+2, Anton Ertl wrote:
>> So iforth is about as fast on FAXPY-NOSTRIDE (all versions) as gcc is
>> on FAXPY.  Impressive!
>
>I'm sorry, but it gets extremely confusing with all these
>indirect references and changes. Is gcc (in gForth) using SSE2
>and auto-vectorizing, or is it forced to use the FPU?

When using AMD64, gcc uses SSE2 scalar (not normally vector)
instructions by default, when using IA-32, it uses 387 instructions by
default.  I don't know what pahihu used.

Vectorization is prevented by the stride argument of FAXPY, and even
for vectorizable code, I have yet to see gcc's auto-vectorization
trigger; seems to be mostly a benchmarketing feature.

>IMHO in practical programs matrix/vector math should not be
>the bottleneck at all (e.g. in SPICE only ~25% of the time
>is spent in the sparse solver). SPICE seems to be written
>by people who were very fond of linked lists, 10-deep
>nested structures and 15 page long functions.

It depends very much on how the program is written*, and that depends
to a good extent on what problem the program solves; but not as much
as many people think.  E.g., one would think that a program like TeX
is not vectorizable, but Bernd Paysan has made a good argument that
paragraph formatting could benefit well from vectorization.  Linked
lists are not amenable to vectorization.

*) That's why I consider auto-vectorization the wrong way to go: you
have to express vectorization to the compiler anyway, so express it
directly, instead of by writing scalar code in an "auto-vectorizable"
style and hoping that the compiler actually manages to auto-vectorize
it.

You can find my thoughts on vector computing in Forth in a video in
German in

<https://wiki.forth-ev.de/doku.php/events:tagung-2016:simd>

- 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 2017: http://www.euroforth.org/ef17/

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

#59664

On Sunday, May 21, 2017 at 4:13:43 PM UTC+2, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Sunday, May 21, 2017 at 9:55:08 AM UTC+2, Anton Ertl wrote:
[..]
> It depends very much on how the program is written*, and that depends
> to a good extent on what problem the program solves; but not as much
> as many people think.  E.g., one would think that a program like TeX
> is not vectorizable, but Bernd Paysan has made a good argument that
> paragraph formatting could benefit well from vectorization.  Linked
> lists are not amenable to vectorization.

So there Forth could have some impact :-)

> *) That's why I consider auto-vectorization the wrong way to go: you
> have to express vectorization to the compiler anyway, so express it
> directly, instead of by writing scalar code in an "auto-vectorizable"
> style and hoping that the compiler actually manages to auto-vectorize
> it.

Indeed. But people with a >2000 file dusty deck probably
see some benefit in the auto route. I don't blame them.

> You can find my thoughts on vector computing in Forth in a video in
> German in
>
> <https://wiki.forth-ev.de/doku.php/events:tagung-2016:simd>

It was really nice to see the faces (I checked some other videos
too), but i.c. the vector computing a paper would be better for
me.

IIUC, you propose a vector wordset to work on 8 (?) float-ops at
a time? It looked a bit verbose, still... Given my experience with
AXPY I'd rather not work on a too low level, all of the time. 
The BLAS spec. should have distilled all useful operations by 
now, and we could use these as a kind of super-instructions?

-marcel

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

#59714

mhx@iae.nl writes:
>> *) That's why I consider auto-vectorization the wrong way to go: you
>> have to express vectorization to the compiler anyway, so express it
>> directly, instead of by writing scalar code in an "auto-vectorizable"
>> style and hoping that the compiler actually manages to auto-vectorize
>> it.
>
>Indeed. But people with a >2000 file dusty deck probably
>see some benefit in the auto route. I don't blame them.

Many people with an incurable disease see some benefit in snake oil,
and they find people willing to sell it to them.  The problem arises
when the snake oil industry or its modern equivalent is marketing
their stuff so successfully that patients prefer it to evidence-based
medicine for curable diseases.

For problems where vectorization helps, there is a cure: identify the
hot code (typically relatively little), and let programmers rework it
into vectorized code.  This will often involve some other
reorganizations, such as replacing linked lists with something else,
and these reorganizations cannot be done by compilers.

Letting programmers vectorize means having vector features in the
programming language, and GNU C actually has such vector features, but
they are sorely neglected (the produced code is horribly inefficient).
They rather preferred to invest their effort in auto-vectorization.

Why?  My explanation is that the "relevant benchmarks" don't use the
vector features, so investing effort in them does not make gcc
"better" (in the metrics they use for evaluating their performance),
while you can tune the auto-vectorizer to actually perform some
auto-vectorization of the benchmarks.

And of course auto-vectorization looks attractive to managers with
lots of existing code.  It promises speedups for free, while the real
cure requires an investment in programmers who know how to vectorize.

>> You can find my thoughts on vector computing in Forth in a video in
>> German in
>>
>> <https://wiki.forth-ev.de/doku.php/events:tagung-2016:simd>
>
>It was really nice to see the faces (I checked some other videos
>too), but i.c. the vector computing a paper would be better for
>me.

Maybe I will write a paper for EuroForth 2017.

>IIUC, you propose a vector wordset to work on 8 (?) float-ops at
>a time?

No, the basic idea is to have arbitrary-length vectors on a vector
stack.

>It looked a bit verbose, still... Given my experience with
>AXPY I'd rather not work on a too low level, all of the time. 
>The BLAS spec. should have distilled all useful operations by 
>now, and we could use these as a kind of super-instructions?

BLAS is for linear algebra, and for that it's probably better than a
general vector wordset, but if you do something vectorizable that's
not linear algebra (e.g., TeX paragraph formatting), you need
something else.

- 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 2017: http://www.euroforth.org/ef17/

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

#59719

2017. május 22., hétfő 13:22:09 UTC+2 időpontban Anton Ertl a következőt írta:
> And of course auto-vectorization looks attractive to managers with
> lots of existing code.  It promises speedups for free, while the real
> cure requires an investment in programmers who know how to vectorize.
> 

I've got GCC 4.9.4 on my machine and tried auto vectorization.
I compiled this dumb C routine with it:

void daxpy(double ra,double *x,double *y,unsigned n)
{
        unsigned i;

        for (i = 0; i < n; i++)
            y[i] += ra * x[i];
}

with the GCC options -march=native -mfpmath=sse -O3 -ffast-math -msse -msse2 -msse3 -m64.

Usign Mr. Hendrix's benchmark setup, I performed a 160x160 DAXPY 10M times, the results are
here for iForth5 and the GCC compiled code.

FORTH> BM 
matrices of size 160 x 160, repeats = 10,000,000 
DAXPY_1       1.970 seconds elapsed.
DAXPY_16      2.260 seconds elapsed.
DAXPY_sse2    0.646 seconds elapsed.
DAXPY_sse2UN  2.043 seconds elapsed.
DAXPY_sse2UN4 2.138 seconds elapsed.
DAXPY         1.163 seconds elapsed. ok

gcc 4.9.4_1   0.920 seconds elapsed

So without much effort I've got better times than GotoBLAS and about 70% of the performance of the
hand written DAXPY_sse2.

pahihu

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web