Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #59543 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2017-05-19 10:43 +0000 |
| Last post | 2017-05-20 13:59 +0000 |
| Articles | 4 on this page of 24 — 5 participants |
Back to article view | Back to comp.lang.forth
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 2 of 2 — ← Prev page 1 [2]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-05-22 07:39 -0700 |
| Message-ID | <7d7dd3a6-4731-4345-8ffd-696e4cd00fa5@googlegroups.com> |
| In reply to | #59719 |
On Monday, May 22, 2017 at 4:14:22 PM UTC+2, pahihu wrote:
> 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.
Which routines do you think the gcc people used to
test their vectorizer? This experiment might not be
random enough for a general conclusion.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-23 10:06 +0000 |
| Message-ID | <2017May23.120638@mips.complang.tuwien.ac.at> |
| In reply to | #59719 |
pahihu <pahihu@gmail.com> writes:
>2017. m=C3=A1jus 22., h=C3=A9tf=C5=91 13:22:09 UTC+2 id=C5=91pontban Anton =
>Ertl a k=C3=B6vetkez=C5=91t =C3=ADrta:
>> 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.
>>=20
>
>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 =3D 0; i < n; i++)
> y[i] +=3D ra * x[i];
>}
That's actually daxpy_nostride; a real daxpy is
daxpy (N, DA, DX, INCX, DY, INCY)
<http://www.netlib.org/lapack/explore-html/d9/dcd/daxpy_8f.html>
On AMD64, already gcc -O3 produces vectorized SSE2 code for
this function; the function is compiled into a 229-byte machine-code
routine, with the inner loop being:
83: 66 0f 10 0c 08 movupd (%rax,%rcx,1),%xmm1
88: 41 83 c0 01 add $0x1,%r8d
8c: 66 0f 59 ca mulpd %xmm2,%xmm1
90: 66 41 0f 58 0c 0a addpd (%r10,%rcx,1),%xmm1
96: 41 0f 29 0c 0a movaps %xmm1,(%r10,%rcx,1)
9b: 48 83 c1 10 add $0x10,%rcx
9f: 45 39 c8 cmp %r9d,%r8d
a2: 72 df jb 83 <xdaxpy+0x83>
If I compile it with gcc -O3 -mavx2, I get a 385-byte routine, with
the inner code being
ca: c4 a1 79 10 0c 00 vmovupd (%rax,%r8,1),%xmm1
d0: 41 83 c3 01 add $0x1,%r11d
d4: c4 a3 75 18 4c 00 10 vinsertf128 $0x1,0x10(%rax,%r8,1),%ymm1,%ymm1
db: 01
dc: c5 f5 59 ca vmulpd %ymm2,%ymm1,%ymm1
e0: c4 81 75 58 0c 04 vaddpd (%r12,%r8,1),%ymm1,%ymm1
e6: c4 81 7d 29 0c 04 vmovapd %ymm1,(%r12,%r8,1)
ec: 49 83 c0 20 add $0x20,%r8
f0: 45 39 cb cmp %r9d,%r11d
f3: 72 d5 jb ca <xdaxpy+0xca>
The xmm registers are 128-bits (2 C doubles) wide, the ymm registers
256 bits (4 C doubles).
However, wrt to the part of my posting you cited, the question is how
much of the code is like the C code above, and how much contains
various stumbling blocks for vectorization. E.g., gcc 4.9 does not
vectorize faxpy (which is much closer to the real daxpy than the
function above). Another question is how much of the code where the
stumbling blocks can be overcome is actually vectorized by gcc.
- 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]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-19 17:00 +0200 |
| Message-ID | <ofn19o$8p5$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59543 |
In article <2017May19.124347@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >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. It uses include which is not a standard word, without notice. It uses lower case standard words, without notice. The most likely dependancy that is unfullfilled is (LOCAL). This is also without notice. > >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-20 13:59 +0000 |
| Message-ID | <2017May20.155941@mips.complang.tuwien.ac.at> |
| In reply to | #59550 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>It uses include which is not a standard word, without notice.
Thanks, I have now replaced the Forth-2012 INCLUDE with the Forth-94
INCLUDED. I have also uploaded a new release with this change and
various other minor changes.
I have also refined my workflow for producing the "notices" so that it
actually exercises the feature replacement code and thus produces
notices for it. It is interesting how many words the replacement code
adds.
Given that the notices actually depend on which features are
available, including such notices does not make much sense; trying to
load the program is a simple procedure and gives you a precise result
for your system rather than a lower or upper limit. Generating the
report with the notices is useful for the developper, though: It gives
a good indication of the words used by the program, and in particular,
the non-standard or new (Forth-2012) words.
>It uses lower case standard words, without notice.
I am pretty sure the user does not need a notice to notice that the
code is not shouting at him.
>The most likely dependancy that is unfullfilled is (LOCAL).
Interestingly, even SwiftForth has (LOCAL) out of the box, while
getting the FP wordset requires a system-specific incantation.
- 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] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.forth
csiph-web