Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52599 > unrolled thread
| Started by | polymorph self <jackvanc3@gmail.com> |
|---|---|
| First post | 2016-11-13 18:33 -0800 |
| Last post | 2016-11-29 13:58 -0500 |
| Articles | 20 on this page of 129 — 26 participants |
Back to article view | Back to comp.lang.forth
Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-13 18:33 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-13 23:02 -0500
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-14 16:59 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-14 22:27 -0500
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-17 06:26 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 08:08 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-17 10:52 -0800
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-17 09:57 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-17 15:58 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 16:29 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-18 08:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 11:17 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-18 06:37 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 15:30 +0000
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:25 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 05:08 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 15:12 -1000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-27 21:06 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 12:20 +0000
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 13:43 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 08:52 -0600
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 17:19 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 11:58 -0600
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 20:39 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 21:56 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:22 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-29 11:06 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-29 09:44 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 13:07 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:37 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:02 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 14:41 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-29 21:32 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 12:43 -0500
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 18:38 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:57 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 16:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 00:19 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-18 10:58 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-19 11:29 +1100
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-18 18:18 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-19 00:31 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-20 14:02 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-20 23:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 09:51 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-24 14:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 15:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-19 17:42 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:26 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-22 10:38 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 12:46 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-24 15:15 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 14:30 -0800
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-25 05:37 -0800
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-25 09:58 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:39 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-25 12:26 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:57 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-26 13:40 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-01 05:35 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-01 18:38 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 21:52 -0800
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 08:45 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 08:50 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:34 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-12-02 10:20 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:04 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 11:59 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:44 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 13:23 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-12-02 15:12 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-03 17:35 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 10:31 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 12:01 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 13:53 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 14:59 +0200
Re: Are stack machines inherently faster? minforth@arcor.de - 2017-01-09 08:15 -0800
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 19:33 +0100
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-12-02 21:09 -1000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-03 13:01 +0100
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 14:51 +0000
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-02 04:28 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-25 16:10 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-25 16:51 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-26 15:09 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-26 13:03 +0100
Re: Are stack machines inherently faster? franck.bensusan@gmail.com - 2016-11-27 10:11 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 16:00 +0000
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-24 22:44 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-24 23:11 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 16:38 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-25 07:28 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-25 04:24 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-25 14:37 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-26 10:54 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 10:56 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:27 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 11:42 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:35 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-22 17:43 +1100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-22 12:51 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 13:30 -0800
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-18 20:27 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:23 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-17 12:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? Manuel Rodriguez <aa5@gmx.net> - 2016-11-28 11:00 -0800
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-11-28 16:10 -0500
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 00:46 -0600
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 02:01 -0500
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-12-01 13:01 -0500
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-03 17:15 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 02:29 -0500
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-04 03:41 -0600
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 10:10 -0500
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 17:16 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-28 13:33 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:17 +0100
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 09:17 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 14:46 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:44 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 18:39 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-30 15:00 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 18:42 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:26 -1000
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-18 18:18 -1000 |
| Message-ID | <5rydnQPnNuYST7LFnZ2dnUU7-I3NnZ2d@supernews.com> |
| In reply to | #52724 |
On 11/18/16 2:29 PM, HAA wrote: > Stephen Pelc wrote: >> On Thu, 17 Nov 2016 15:58:33 -0800, Paul Rubin >> <no.email@nospam.invalid> wrote: >> >>> I don't know about Foxaudio, but I'd say "very well" means the ITC >>> performance is enough to satisfy users' real-world requirements. Most >>> of my stuff these days is written in Python and it's fast enough for my >>> purposes, and Gforth-itc is probably >10x faster than Python. I've >>> never written a Forth program that wasn't a benchmark, that used enough >>> computation time for me to notice. >> >> One of our clients has a recalculation that used to take 15 or so >> seconds on our DTC ProForth for Windows. The boss excitedly took >> me to his office to show that the conversion to VFX Forth took >> about 1.5 seconds. To him, that was important. >> >> These days, there are plenty of algorithms that do not follow the >> "90% of the time in 10% of the code" model. >> >> Stephen > > No doubt your client could also demonstrate that VFX is faster than > SwiftForth. Yet Forth Inc still exists and presumably gets work. > The model which states 'fastest is best' appears not to follow. > What happens when 1.5 seconds is not good enough? Discard Forth > for C? That's not unreasonable either. CPU, clock, language, facilities, > I rank greater than compiler technology. Get those wrong and it won't > matter whether it's DTC or NCC. SwiftForth is substantially faster than ITC Forths. Its compiler isn't as complex as VFX, but it delivers satisfactory performance. Most of our users say they prefer SwiftForth's user interface, particularly as a host for our interactive cross compilers. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-19 00:31 -0800 |
| Message-ID | <87fumndg6m.fsf@nightsong.com> |
| In reply to | #52724 |
"HAA" <someone@microsoft.com> writes: > What happens when 1.5 seconds is not good enough? Discard Forth for > C? That's not unreasonable either. CPU, clock, language, facilities, > I rank greater than compiler technology. Get those wrong and it won't > matter whether it's DTC or NCC. I have to wonder what kind of hardware Stephen's client was running DTC Forth on. If it's old enough then a 10x or more speedup might be had by just upgrading it. VFX code output should run at comparable speed to the output of a decent C compiler. A fancy optimizing C compiler might get a little more speedup, but the next thing to pursue is more likely parallelism, GPU's, etc. That assumes that the algorithm is already decent, the existing host PC is reasonably fast by today's standards, etc.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-20 14:02 +0000 |
| Message-ID | <2016Nov20.150210@mips.complang.tuwien.ac.at> |
| In reply to | #52729 |
Paul Rubin <no.email@nospam.invalid> writes:
>VFX code output should run at comparable speed to the output of a decent
>C compiler.
Quite doubtful, because a decent C compiler performs "global" (i.e.,
intraprocedural, but across basic block boundaries) register
allocation, while VFX performs only local register allocation (and
only for data stack items AFAICS).
But let's see. I'll use the benchmarks in
<http://www.complang.tuwien.ac.at/forth/bench.zip>, because they come
in both Forth and C versions (plus another C version produced by
compiling the Forth version with forth2c):
As C compiler I use gcc-3.4.0 -m32 -O (using gcc-4.9 for invoking the
linker), the oldest gcc I could get to run without much ado, and the
lowest optimization option that includes register allocation.
Note that the startup overhead including compilation of the benchmark
is 12M-13M cycles and 9M-10M instructions on VFX; you can subtract
that from the VFX numbers in the following, but it does not change
much.
cycles on Skylake (Core i7-6700K):
fib sieve bubble-sort matrix-mult
103,918,294 90,766,932 130,074,697 37,612,032 gcc-3.4.0
114,757,879 208,334,551 250,370,641 81,795,422 vfxlin
101,972,847 120,005,096 117,031,810 27,122,738 forth2c+gcc-3.4.0
instruction counts (might provide insight into the cycle numbers):
fib sieve bubble-sort matrix-mult
277,239,469 158,698,839 136,036,718 91,708,093 gcc-3.4.0
193,834,212 190,441,316 313,932,162 173,199,451 vfxlin
304,920,087 272,868,329 144,091,955 107,261,137 forth2c+gcc-3.4.0
Discussion:
VFX does nicely on fib, with only the startup+compile overhead as
difference, but is significantly slower than gcc and forth2c+gcc on
the other benchmarks.
Forth2c is relatively close to the manually written C code in cycles,
although it has some overhead in instructions; the speedup over
c-manual in matrix-mult may by due to inner-product() returning its
result by writing to a passed pointer in c-manual, while the forth
version passes the result on the stack (and c-generated therefore
passes it in a register). The forth2c speedup over c-manual for
bubble-sort appears due to a freak slowdown for c-manual/bubble-sort
when enabling -fomit-frame-pointer that does not affect
c-generated/bubble-sort.
Conclusion: global register allocation pays off.
BTW, forth2c is neither commercial nor proprietary. You can download
it at <http://www.complang.tuwien.ac.at/forth/forth2c.tar.gz>. It's
proof-of-concept software, that's 20 years old, however.
One other BTW is that the C code that compiled fine 20 years ago
needed some massaging to compile today, while the Forth programs just
compiled fine. The C problems mainly have to do with the way that
stan.c (the Stanford benchmarks) are written, but the kind of failing
I saw is pretty C-specific, so a part of the blame is also in the
language design. Those who want to experience the failure can get the
old version at <http://www.complang.tuwien.ac.at/forth/bench.tar.gz>.
The command lines I used are:
#in c-manual:
for i in fib sieve bubble-sort matrix-mult; do gcc-3.4.0 -fomit-frame-pointer -m32 -O -DUNIX -c $i.c; gcc -m32 $i.o -o $i; echo $i; perf stat -B -r100 -e cycles -e instructions $i >/dev/null; done
#in forth:
for i in fib sieve bubble-sort matrix-mult; do echo $i; perf stat -B -r100 -e cycles -e instructions vfxlin "include $i.fs bye" >/dev/null; perf stat -B -r100 -e cycles -e instructions vfxlin "include $i.fs main bye" >/dev/null; done
#in c-generated:
for i in fib sieve bubble-sort matrix-mult; do gcc-3.4.0 -fomit-frame-pointer -m32 -O -DUNIX -c $i.c; gcc -m32 $i.o -o $i; echo $i; perf stat -B -r100 -e cycles -e instructions $i >/dev/null; done
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-20 23:16 -0800 |
| Message-ID | <87lgwdb8v7.fsf@nightsong.com> |
| In reply to | #52764 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > VFX does nicely on fib, with only the startup+compile overhead as > difference, but is significantly slower than gcc and forth2c+gcc on > the other benchmarks. Thanks, that's more of a difference than I expected. Can you try -O0 and -Os ? > BTW, forth2c is neither commercial nor proprietary. I may have mentioned it before, but here's another backend that might interest you: http://c9x.me/compile/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-22 09:51 +0000 |
| Message-ID | <2016Nov22.105129@mips.complang.tuwien.ac.at> |
| In reply to | #52785 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> VFX does nicely on fib, with only the startup+compile overhead as
>> difference, but is significantly slower than gcc and forth2c+gcc on
>> the other benchmarks.
>
>Thanks, that's more of a difference than I expected. Can you try -O0
>and -Os ?
cycles on Skylake (Core i7-6700K):
fib sieve bubble-sort matrix-mult
114,757,879 208,334,551 250,370,641 81,795,422 vfxlin
103,918,294 90,766,932 130,074,697 37,612,032 gcc-3.4.0 -O
110,917,296 142,023,925 127,515,900 40,082,593 gcc-3.4.0 -Os
117,783,304 282,271,421 230,553,817 72,302,347 gcc-3.4.0 -O0
101,972,847 120,005,096 117,031,810 27,122,738 forth2c+gcc-3.4.0 -O
105,767,852 123,021,305 121,547,076 27,284,693 forth2c+gcc-3.4.0 -Os
635,649,325 646,799,258 946,796,814 563,021,402 forth2c+gcc-3.4.0 -O0
instruction counts (might provide insight into the cycle numbers):
fib sieve bubble-sort matrix-mult
193,834,212 190,441,316 313,932,162 173,199,451 vfxlin
277,239,469 158,698,839 136,036,718 91,708,093 gcc-3.4.0 -O
258,784,624 190,090,078 172,001,838 75,431,668 gcc-3.4.0 -Os
268,012,628 310,659,184 290,144,319 188,642,125 gcc-3.4.0 -O0
304,920,087 272,868,329 144,091,955 107,261,137 forth2c+gcc-3.4.0 -O
286,467,831 244,777,496 162,397,933 99,100,847 forth2c+gcc-3.4.0 -Os
1,006,307,340 1,005,039,966 1,202,060,005 887,457,536 forth2c+gcc-3.4.0 -O0
I am surprised by the sometimes large differences between -O and -Os
for the manually written code (I expected small difference like those
we see for the forth2c-generated code). For -O0, which does not
allocate variables into registers, I am surprised that it does not
suffer more against VFX. OTOH, forth2c and gcc -O0 is the perfect
mismatch, leading to a factor >20 slowdown for matrix-mult; it is a
mismatch, because forth2c was written to rely on register allocation
and copy propagation, and gcc -O0 does neither.
>I may have mentioned it before, but here's another backend that might
>interest you: http://c9x.me/compile/
Thanks. Looks like it suffers from the same ABI-calls-only
disadvantage that LLVM suffers from, and it only has one target, but
it's still under development. Still, an interesting project; maybe we
get a useful C compiler from it.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-24 14:16 -0800 |
| Message-ID | <bc01aec1-d855-4d8d-ae0c-44a2b7a7c318@googlegroups.com> |
| In reply to | #52810 |
Thanks for the benchmarks. It's interesting that a good analytical Forth compiler comes to under 2:1 compared to GCC. It seems this is a small difference that could be swamped by other factors such as better algorithm polishing or explicit memory layout to minimize cache misses, both strengths of Forth. As for target architectures, stack machines seem to have about the same semantic density as register machines. A dense stack machine language is about as good as a dense register machine language (like Thumb or some CISCs). The difference is that a Forth compiler is much simpler for the former.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-25 15:26 +0000 |
| Message-ID | <2016Nov25.162606@mips.complang.tuwien.ac.at> |
| In reply to | #52850 |
Brad Eckert <hwfwguy@gmail.com> writes:
>Thanks for the benchmarks. It's interesting that a good analytical Forth co=
>mpiler comes to under 2:1 compared to GCC.
Actually, the good analytical Forth compiler achieves around 1:1
compared to GCC. The other analytical Forth compiler (VFX) comes to
under 2:1. The main reasons for VFX's worse performance are that it
does not keep stack items other than TOS in registers across control
flow, and that it does not keep return stack items in registers at
all. E.g., something like
: foo >r r> ;
becomes
FOO
( 080C08A0 53 ) PUSH EBX
( 080C08A1 5B ) POP EBX
( 080C08A2 C3 ) NEXT,
I had not expected that to result in such large differences, and I had
expected VFX to significantly outperform gcc -O0. My guess is that
the reason for the large differences to gcc -O is recurrences through
memory in the inner loop (which means at least 5 cycles per
iteration); and the reason for gcc -O0 not being worse is that having
two or three recurrences is not much worse than having one, as long as
they dont depend on each other: they all wait in parallel.
>It seems this is a small differe=
>nce that could be swamped by other factors such as better algorithm polishi=
>ng or explicit memory layout to minimize cache misses, both strengths of Fo=
>rth.
C is just as strong at these as Forth is, and my impression is that
there is a certain ignorant attitude in the Forth community for such
topics (the C community with its faith in compiler optimization
miracles is getting there, too, however). E.g., 20 years after sharing
of instructions and data was pointed out as a performance problem,
most Forth systems still mix instructions and data in the dictionary,
with a bit of occasional padding as a workaround that helps in some
cases.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-19 17:42 +0000 |
| Message-ID | <58308c02.828401392@news.eternal-september.org> |
| In reply to | #52724 |
On Sat, 19 Nov 2016 11:29:47 +1100, "HAA" <someone@microsoft.com> wrote: >No doubt your client could also demonstrate that VFX is faster than >SwiftForth. Yet Forth Inc still exists and presumably gets work. >The model which states 'fastest is best' appears not to follow. >What happens when 1.5 seconds is not good enough? Discard Forth >for C? That's not unreasonable either. CPU, clock, language, facilities, >I rank greater than compiler technology. Get those wrong and it won't >matter whether it's DTC or NCC. I was asked a question about performance and I answered it. If you want to compare performance between two Forth systems, try downloading the MPE benchmark suite ... and using it. That performance is just one factor in tool chain selection is obvious. Another is the GUI. Another is the level of library support. And so on, and so on. It is also a fallacy to assume that the commercial Forth vendors are in competition with each other. We are very rarely in competition for the same client. Our competition is the toolchains for other languages. 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-21 14:26 -0800 |
| Message-ID | <590c89f1-3c0e-4fda-865e-c3acc59b34a6@googlegroups.com> |
| In reply to | #52736 |
On Saturday, November 19, 2016 at 10:42:25 AM UTC-7, Stephen Pelc wrote:
> It is also a fallacy to assume that the commercial Forth
> vendors are in competition with each other. We are very rarely
> in competition for the same client. Our competition is the
> toolchains for other languages.
Your goal in supporting ANS-Forth seems to be to make the Forth community look stupid. Good job! Having the parameters backwards in LOCALS| was, by itself, the killing stroke for the entire Forth community.
You are not in competition with Forth Inc.. I think you rely on them to do your sales, then when they find a customer they outsource the actual programming to you, so you both make money.
You are in competition with Forth programmers such as myself. The whole purpose of ANS-Forth is to allow you to tell everybody in the Forth community that they are non-standard unless they adhere to the idiotic restrictions of Elizabeth Rather's toy language.
You don't adhere to ANS-Forth though. You routinely abandon ANS-Forth compatibility, even when doing so is not necessary. For example, in regard to SYONYM and ALIAS, you told me (quite condescendingly) to RTFM. You meant the VFX manual where you provide a SYNONYM that is VFX-specific and would get me trapped in vendor lock-in. I wrote SYNONYM and ALIAS in ANS-Forth though --- it was easy --- it did require me to have the disambiguifiers already installed.
Here is the code, so RTFM yourself:
: :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if xt compile, ;, exit then
true abort" *** :SYNONYM given an invalid xt ***" ;
: :synonym-fast-check ( -- )
state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;
: :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if postpone :synonym-fast-check
xt lit, postpone compile, ;, immediate exit then
true abort" *** :SYNONYM-FAST given an invalid xt ***" ;
: 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;
: synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl word hstr to new
'find new wid :synonym
new dealloc ;
: synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl parse <hstr> to new
'find new wid :synonym-fast
new dealloc ;
\ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
\ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.
1234512345 constant alias-id \ an arbitrary number used to identify alias'd definitions
0
w field alias.xt \ this should be the first field so the DOES> portion of ALIAS will be fast (no addition needed)
w field alias.adr \ the address of the body, used to identify alias'd definitions
w field alias.id \ the constant ALIAS-ID, used to identify alias'd definitions
constant alias-struct
: alias ( wid -- ) \ stream: new-name old-name \ the new word is compiled into the WID word-list
get-current swap set-current create set-current
here >r alias-struct allot
'find 1 = if immediate then r@ alias.xt !
r@ r@ alias.adr !
alias-id r@ alias.id !
rdrop
does>
alias.xt @ execute ;
\ ALIAS does the same thing as SYNONYM but has the advantage that >BODY will work on it.
\ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).
: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
r> alias.xt @ >body exit then then \ return the body of the original word
r> ; \ return the body of this word
\ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-11-22 10:38 +0000 |
| Message-ID | <o1175p$dtv$1@dont-email.me> |
| In reply to | #52795 |
On 21/11/2016 22:26, hughaguilar96@gmail.com wrote:
> You don't adhere to ANS-Forth though. You routinely abandon ANS-Forth compatibility, even when doing so is not necessary. For example, in regard to SYONYM and ALIAS, you told me (quite condescendingly) to RTFM. You meant the VFX manual where you provide a SYNONYM that is VFX-specific and would get me trapped in vendor lock-in. I wrote SYNONYM and ALIAS in ANS-Forth though --- it was easy --- it did require me to have the disambiguifiers already installed.
>
> Here is the code, so RTFM yourself:
>
> : :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> str wid :name
> flg 1 = if xt lit, execute, ;, immediate exit then
> flg -1 = if xt compile, ;, exit then
> true abort" *** :SYNONYM given an invalid xt ***" ;
>
> : :synonym-fast-check ( -- )
> state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;
>
> : :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> str wid :name
> flg 1 = if xt lit, execute, ;, immediate exit then
> flg -1 = if postpone :synonym-fast-check
> xt lit, postpone compile, ;, immediate exit then
> true abort" *** :SYNONYM-FAST given an invalid xt ***" ;
>
> : 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
> bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;
>
> : synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> bl word hstr to new
> 'find new wid :synonym
> new dealloc ;
>
> : synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> bl parse <hstr> to new
> 'find new wid :synonym-fast
> new dealloc ;
>
> \ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
> \ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.
Because it compiles a colon definition for the synonym I don't think
your definition of SYNONYM works in all cases. For example (ignoring the
wid which is non-standard anyway):
123 value foo
synonym bar foo
456 to bar \ Fails as TO can't save a value to a colon definition
Similarly
defer x
:noname ... ; is x
synonym y x
:noname ... ; is y \ Would fail
Probably a minor restriction.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-24 12:46 -0800 |
| Message-ID | <036e05cf-5352-4bb1-b1af-e27916ba29c0@googlegroups.com> |
| In reply to | #52811 |
On Tuesday, November 22, 2016 at 3:38:22 AM UTC-7, Gerry wrote:
> On 21/11/2016 22:26, hughaguilar96@gmail.com wrote:
> > You don't adhere to ANS-Forth though. You routinely abandon ANS-Forth compatibility, even when doing so is not necessary. For example, in regard to SYONYM and ALIAS, you told me (quite condescendingly) to RTFM. You meant the VFX manual where you provide a SYNONYM that is VFX-specific and would get me trapped in vendor lock-in. I wrote SYNONYM and ALIAS in ANS-Forth though --- it was easy --- it did require me to have the disambiguifiers already installed.
> >
> > Here is the code, so RTFM yourself:
> >
> > : :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> > str wid :name
> > flg 1 = if xt lit, execute, ;, immediate exit then
> > flg -1 = if xt compile, ;, exit then
> > true abort" *** :SYNONYM given an invalid xt ***" ;
> >
> > : :synonym-fast-check ( -- )
> > state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;
> >
> > : :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> > str wid :name
> > flg 1 = if xt lit, execute, ;, immediate exit then
> > flg -1 = if postpone :synonym-fast-check
> > xt lit, postpone compile, ;, immediate exit then
> > true abort" *** :SYNONYM-FAST given an invalid xt ***" ;
> >
> > : 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
> > bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;
> >
> > : synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> > bl word hstr to new
> > 'find new wid :synonym
> > new dealloc ;
> >
> > : synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> > bl parse <hstr> to new
> > 'find new wid :synonym-fast
> > new dealloc ;
> >
> > \ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
> > \ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.
>
> Because it compiles a colon definition for the synonym I don't think
> your definition of SYNONYM works in all cases. For example (ignoring the
> wid which is non-standard anyway):
>
> 123 value foo
> synonym bar foo
> 456 to bar \ Fails as TO can't save a value to a colon definition
>
> Similarly
>
> defer x
> :noname ... ; is x
> synonym y x
> :noname ... ; is y \ Would fail
>
> Probably a minor restriction.
>
> --
> Gerry
SYNONYM is generates fast code, but it doesn't work with >BODY.
ALIAS compiles a CREATE DOES> definition so it generates slow code. I works with >BODY because I wrote a new >BODY for it --- supporting >BODY was the whole point of ALIAS.
The problem with supporting VALUE in a similar way, is that VALUE isn't defined to necessarily use CREATE DOES> internally. In SwiftForth VALUE is just a CREATE DOES> definer, so this does work:
12345 value vvv ok
vvv . 12345 ok
' vvv >body @ . 12345 ok
get-current alias new-vvv vvv ok
new-vvv . 12345 ok
' new-vvv >body @ . 12345 ok
This doesn't work in VFX though because VALUE is not a CREATE DOES> definer. VFX is ANS-Forth compliant in this case because the ANS-Forth document doesn't require VALUE to use CREATE DOES> and it is okay for VFX to do something else internally.
Anyway --- VALUE and TO are abominations --- I never use them (except for locals which have to use TO because the abomination is required).
Anyway, I hate ANS-Forth and I'm never going to become an ANS-Forth programmer. I just wrote SYNONYM and ALIAS as a joke because Stephen Pelc had said that this was impossible in ANS-Forth --- so I wrote it in ANS-Forth and got >BODY to work, although as you said: VALUE still doesn't work.
BTW: I found it rather humorous that you said: "ignoring the wid which is non-standard anyway." What??? SYNONYM and ALIAS are not in the ANS-Forth Standard. What Standard is my wid feature being non-standard to???
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-11-24 15:15 -0600 |
| Message-ID | <o17l81$96u$1@dont-email.me> |
| In reply to | #52847 |
On 11/24/2016 2:46 PM, hughaguilar96@gmail.com wrote: > > SYNONYM is generates fast code, but it doesn't work with >BODY. > > ALIAS compiles a CREATE DOES> definition so it generates slow code. I works with >BODY because I wrote a new >BODY for it --- supporting >BODY was the whole point of ALIAS. > > The problem with supporting VALUE in a similar way, is that VALUE isn't defined to necessarily use CREATE DOES> internally. In SwiftForth VALUE is just a CREATE DOES> definer, so this does work: > > 12345 value vvv ok > vvv . 12345 ok > ' vvv >body @ . 12345 ok > get-current alias new-vvv vvv ok > new-vvv . 12345 ok > ' new-vvv >body @ . 12345 ok > > This doesn't work in VFX though because VALUE is not a CREATE DOES> definer. VFX is ANS-Forth compliant in this case because the ANS-Forth document doesn't require VALUE to use CREATE DOES> and it is okay for VFX to do something else internally. > > Anyway --- VALUE and TO are abominations --- I never use them (except for locals which have to use TO because the abomination is required). > > Anyway, I hate ANS-Forth and I'm never going to become an ANS-Forth programmer. I just wrote SYNONYM and ALIAS as a joke because Stephen Pelc had said that this was impossible in ANS-Forth --- so I wrote it in ANS-Forth and got >BODY to work, although as you said: VALUE still doesn't work. > > BTW: I found it rather humorous that you said: "ignoring the wid which is non-standard anyway." What??? SYNONYM and ALIAS are not in the ANS-Forth Standard. What Standard is my wid feature being non-standard to??? > Pardon my ignorance but in what way does ANSI Forth create slow code by using CREATE DOES ? With older Forth that I'm used to CREATE DOES creates as efficient code as one wants, no overhead of any kind, only the code you use so it's up to the programmer to create an efficient definition. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-24 14:30 -0800 |
| Message-ID | <5a6bc50e-47fd-4dec-90e9-5b79218d7524@googlegroups.com> |
| In reply to | #52848 |
On Thursday, November 24, 2016 at 2:15:57 PM UTC-7, Cecil - k5nwa wrote:
> Pardon my ignorance but in what way does ANSI Forth create slow code by
> using CREATE DOES ?
>
> With older Forth that I'm used to CREATE DOES creates as efficient code
> as one wants, no overhead of any kind, only the code you use so it's up
> to the programmer to create an efficient definition.
CREATE DOES> is inefficient because, in most cases, you are storing constant data in the >BODY struct (the data is known at compile-time and it never changes). At run-time you have to fetch this data out of memory as if it were mutable. It would be a lot more efficient if you compiled code with this data being a literal in the code.
I brought this up a long time ago (2009) and Stephen Pelc argued vigorously that CREATE DOES> is efficient. Weirdly though, he didn't provide source-code using CREATE DOES> that did the same thing as my code that didn't use CREATE DOES>. Finally, he did provide source-code --- it was VFX-specific and not ANS-Forth compliant! --- VFX has some non-standard way to declare data in the >BODY struct as being immutable. By comparison, all of my code in the novice-package is ANS-Forth compliant. It seems strange to me that I write ANS-Forth compliant code but I'm not considered to be an ANS-Forth programmer, whereas Stephen Pelc writes code that is not ANS-Forth compliant but he is considered to be an expert on ANS-Forth (that is why Elizabeth Rather appointed him to the Forth-200x committee).
CREATE DOES> is typically implemented with the code compiled by CREATE doing a CALL to the code that precedes the DOES> code and falls through into it. The CALL pushes the address after the CALL onto the return-stack. This is not code however; this is the address of the >BODY struct where data is held. The code that precedes the DOES> code pops this address off the return-stack and pushes it onto the data-stack so the DOES> code will have it. Both VFX and SwiftForth are implemented like this. This technique goes back to the 1970s when Charles Moore thought it up. On a modern processor however, this is inefficient. The x86 has RET prediction (up to 16 levels of function calls get predicted correctly), but if you pop an address off the return-stack and use it as data, the whole RET prediction thing fails and all of that data is lost. The x86 is no longer able to predict RET destinations! Failure to predict branches is a big speed-killer on the x86 --- if the x86 predicts branches correctly then it is able to compile trace-code ahead of time and have it ready to go --- if the x86 mispredicts a branch though, then the whole trace-cache has to be abandoned and the machine-code at the actual destination has to be compiled into trace-code before it can execute (this is not being done in parallel with the execution of previous trace-code and hence it causes a huge delay in execution).
Anyway, getting back to the first point I made about CREATE DOES> treating immutable data as mutable, here is quote from the ANS-Forth "leading expert:"
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;
Note that this doesn't work properly, because it is using 1 as the base index rather than 0 which is more common. Most likely, Elizabeth Rather wrote it this way because COBOL uses 1 as the base index for arrays and COBOL is the only programming language that she knows. Another related problem is that her range-checking is done with two signed comparisons --- it should be done with one unsigned comparison.
Here I have fixed her code for her:
: array ( n -- )
create dup , cells allot
does> ( index base-adr -- )
2dup @ u< 0= abort" *** ARRAY out of range ***"
swap 1+ cells + ;
None of these CREATE DOES> definers are any good though. The limit value that is comma'd into the >BODY struct is known at compile-time and it never changes --- it should be a literal --- instead it is treated as if it were mutable.
In my novice-package I have 1ARRAY that is for defining one-dimensional arrays. It is general-purpose in that you can use any size of element, not just cell-sized elements. Also, you can turn off the range-checking if you don't need it. Here is a demonstration of 1ARRAY in SwiftForth (with error-checking turned on) --- notice the instruction A # EBX MOV in which the limit value is treated as being immutable.
10 w 1array mmm ok
0 mmm . 4782256 ok
9 mmm . 4782292 ok
10 mmm . mmm *** array index 1 out of bounds ***
-1 mmm . mmm *** array index 1 out of bounds ***
see mmm
48F90F 4 # EBP SUB 83ED04
48F912 EBX 0 [EBP] MOV 895D00
48F915 A # EBX MOV BB0A000000
48F91A 48BA2F ( check1 ) CALL E810C1FFFF
48F91F EBX 2 # SHL C1E302
48F922 48F8B0 # EBX ADD 81C3B0F84800
48F928 RET C3 ok
see check1
48BA2F 0 [EBP] EBX CMP 3B5D00
48BA32 0 # EBX MOV BB00000000
48BA37 48BA3A JBE 7601
48BA39 EBX DEC 4B
48BA3A -1 # EBX XOR 83F3FF
48BA3D 4076BF ( (S") ) CALL E87DBCF7FF
48BA42 "*** array index 1 out of bounds ***"
48BA67 407E9F ( ?ABORT ) JMP E933C4F7FF ok
Here it is with range-checking turned off:
false to bounds-check? ok
10 w 1array nnn ok
0 nnn . 4782572 ok
9 nnn . 4782608 ok
see nnn
48FA2F EBX 2 # SHL C1E302
48FA32 48F9EC # EBX ADD 81C3ECF94800
48FA38 RET C3 ok
Note that 1ARRAY 2ARRAY etc. are obsolete now though --- I have ARY that is more convenient --- ARY also produces fast code though.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-11-25 05:37 -0800 |
| Message-ID | <4b916947-a764-4954-ae96-b64e4bf8c046@googlegroups.com> |
| In reply to | #52852 |
пятница, 25 ноября 2016 г., 1:30:41 UTC+3 пользователь hughag...@gmail.com написал: > On Thursday, November 24, 2016 at 2:15:57 PM UTC-7, Cecil - k5nwa wrote: > > Pardon my ignorance but in what way does ANSI Forth create slow code by Small, but importan question. Why performance takes so much care? In 90-th, performance was a priority for programming, but no longer. Having a variety of CPU from 1.5 GHz Atom to 4 GHz Core-i7, we should keep in mind our program will run on an average-speed CPU and user will not count every frame or every loop iteration per second. Having pure interpreted code is no good, but having x2-x3 slower compiled code is still acceptable if you can highlight other important features of your program/language.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-25 09:58 -0600 |
| Message-ID | <hdedncXFma0swqXFnZ2dnUU78QHNnZ2d@supernews.com> |
| In reply to | #52867 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > ???????, 25 ?????? 2016 ?., 1:30:41 UTC+3 ???????????? hughag...@gmail.com ???????: >> On Thursday, November 24, 2016 at 2:15:57 PM UTC-7, Cecil - k5nwa wrote: >> > Pardon my ignorance but in what way does ANSI Forth create slow code by > > Small, but importan question. Why performance takes so much care? In > 90-th, performance was a priority for programming, but no > longer. Having a variety of CPU from 1.5 GHz Atom to 4 GHz Core-i7, > we should keep in mind our program will run on an average-speed CPU > and user will not count every frame or every loop iteration per > second. Having pure interpreted code is no good, but having x2-x3 > slower compiled code is still acceptable if you can highlight other > important features of your program/language. It's an interesting question. Firstly, Stephen has already answered part of that by pointing out that he hasn't written an interrupt handler in assembly code for many, many years. But also, we're competing in a marketplace for bang for the buck. People have power budgets, not only in mobile applications but increasingly also in server farms. If your program runs only once this sort of consideration perhaps doesn't matter. But if it runs many times, then it matters a lot more. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-11-26 10:39 -0800 |
| Message-ID | <61a6f7fa-cf2b-4601-baca-4f056c37e018@googlegroups.com> |
| In reply to | #52870 |
> It's an interesting question. Firstly, Stephen has already answered > part of that by pointing out that he hasn't written an interrupt > handler in assembly code for many, many years. But also, we're > competing in a marketplace for bang for the buck. People have power > budgets, not only in mobile applications but increasingly also in > server farms. If your program runs only once this sort of > consideration perhaps doesn't matter. But if it runs many times, then > it matters a lot more. We should separate application domains and goals. If you plan to use Forth in supercomputing applications or CPU-based calculations (GPU also possible to use here), you need to consider some trade-offs. Forth already has these trade-offs - if we want to keep translator as simple as possible, we must agreed with other features/misfeatures. Accept performance 'as is' while you try to get maximum profit from other features. An idea about '1% performance increase means thousands years of overall PC runtime worldwide' is a myth. First, in general you have no thousands PCs running your program all time. For Forth it is especially important :) Second, not all programs performs heavy calculations 100% of their runtime. This may be more important for users to have some program now instead of having 10% faster program later. Performance was a key feature in 90-th. DSL and custom syntax may be more interesting today.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-11-25 12:26 -0600 |
| Message-ID | <o19vn6$9g7$1@dont-email.me> |
| In reply to | #52867 |
On 11/25/2016 7:37 AM, Ilya Tarasov wrote: > пятница, 25 ноября 2016 г., 1:30:41 UTC+3 пользователь hughag...@gmail.com написал: >> On Thursday, November 24, 2016 at 2:15:57 PM UTC-7, Cecil - k5nwa wrote: >>> Pardon my ignorance but in what way does ANSI Forth create slow code by > > Small, but importan question. Why performance takes so much care? In 90-th, performance was a priority for programming, but no longer. Having a variety of CPU from 1.5 GHz Atom to 4 GHz Core-i7, we should keep in mind our program will run on an average-speed CPU and user will not count every frame or every loop iteration per second. Having pure interpreted code is no good, but having x2-x3 slower compiled code is still acceptable if you can highlight other important features of your program/language. > A desktop computer is not the only place where Forth is used, on small embedded CPUs, performance can be important. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-11-26 10:57 -0800 |
| Message-ID | <0733ea56-878c-4049-8d34-1b650b97e596@googlegroups.com> |
| In reply to | #52874 |
> A desktop computer is not the only place where Forth is used, on small > embedded CPUs, performance can be important. Since embedded is my preferred area, I can't completely agrees with you, by many reasons. From my experience, I never had a kind of success story by claiming Forth as a tool for achieving maximum performance. 1. MCUs often has enough performance for simple tasks. If not, we must review system architecture and use some kind of acceleration. It is very risky to use, say, 100 MHz MCU and rely on programmers skills to keep performance level from scratch to final product. 99% programmers prefer to have a certain slack while developing. 2. In embedded applications, we always can switch to assembler. If not, don't complain on Forth performance. 3. Main and very important feature of Forth is an ability to create your own code as fast as possible. We may ask for money saving (less actual with a lot of freeware development tools) or for our own toolchain with better system integration. This may be summarized as 'we need our own tool and can accept misfeatures of this approach'.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-11-26 13:40 -0600 |
| Message-ID | <o1cocg$ud2$1@dont-email.me> |
| In reply to | #52879 |
On 11/26/2016 12:57 PM, Ilya Tarasov wrote: > >> A desktop computer is not the only place where Forth is used, on small >> embedded CPUs, performance can be important. > > Since embedded is my preferred area, I can't completely agrees with you, by many reasons. From my experience, I never had a kind of success story by claiming Forth as a tool for achieving maximum performance. > > 1. MCUs often has enough performance for simple tasks. If not, we must review system architecture and use some kind of acceleration. It is very risky to use, say, 100 MHz MCU and rely on programmers skills to keep performance level from scratch to final product. 99% programmers prefer to have a certain slack while developing. > 2. In embedded applications, we always can switch to assembler. If not, don't complain on Forth performance. > 3. Main and very important feature of Forth is an ability to create your own code as fast as possible. We may ask for money saving (less actual with a lot of freeware development tools) or for our own toolchain with better system integration. This may be summarized as 'we need our own tool and can accept misfeatures of this approach'. > A guess on my part but I will attribute your answer to language issues, because you are responding as I was making claims that I did not make. I did not state that performance by Forth is superior to anything else, or that performance is necessary in all cases but that it "can be important" in some cases. One can't always change the CPU on a project as an example modifying the firmware on an existing product to add more features, this could be a product bought from someone else so changing the hardware is too much trouble and not worth the effort. Switching to assembler could be avoided if the Forth compiler is efficient, not everyone is making a project that involves making a lot of units, in my case most projects are one of a kind not to be duplicated. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-12-01 05:35 -0800 |
| Message-ID | <f4ee68e8-e201-4dff-85a7-07ff0a96bd58@googlegroups.com> |
| In reply to | #52882 |
> A guess on my part but I will attribute your answer to language issues, > because you are responding as I was making claims that I did not make. > > I did not state that performance by Forth is superior to anything else, > or that performance is necessary in all cases but that it "can be > important" in some cases. If you think I'm typing randomly or evil siberian bear forcing me to drink vodka you are probably wrong. I can copy your previous message: > >> A desktop computer is not the only place where Forth is used, on small > >> embedded CPUs, performance can be important. This is a very tricky move to point to performance optimization when someone wants to freeze project. 'Why do you write compiler instead of finishing your project? - Because performance can be important!' Is it important right now? Also, estimate performance at early stage and choose tasks where Forth performance will be enough. > Switching to assembler could be avoided if the Forth compiler is > efficient, not everyone is making a project that involves making a lot > of units, in my case most projects are one of a kind not to be duplicated. Switching to assembler is not a disaster. 'Right tool for the right task'.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web