Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42901 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-10-28 09:04 -0700 |
| Last post | 2015-12-12 18:52 -0800 |
| Articles | 20 on this page of 174 — 27 participants |
Back to article view | Back to comp.lang.forth
Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:04 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:18 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 12:35 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:54 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-28 10:35 -0700
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 11:21 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 14:24 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:12 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 16:31 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 14:55 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 01:36 -0400
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 06:01 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:22 -0400
Re: Stoked Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-07 17:50 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 13:04 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 10:19 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:29 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-07 13:28 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 13:33 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 14:25 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 18:03 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 15:22 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:13 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 22:35 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:58 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 23:17 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 02:49 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-08 00:06 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:40 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 15:18 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 13:31 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 17:19 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 20:49 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 00:57 -0500
Re: Stoked hughaguilar96@gmail.com - 2015-11-11 22:24 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 23:34 -0800
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-12 00:03 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 19:37 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 15:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 13:18 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 20:59 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-13 01:50 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 23:11 -0800
Re: Stoked forthisit@gmail.com - 2015-11-12 13:47 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 16:27 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-12 12:18 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-13 00:28 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-11 22:37 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-12 23:37 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:19 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 07:47 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-23 11:27 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 13:43 +0100
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 12:49 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 19:20 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:44 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:23 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:45 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:53 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 21:25 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 14:09 -0800
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-09 05:32 -0500
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:58 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:42 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:11 -0800
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-15 12:50 +0100
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-07 23:56 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 03:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:31 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:57 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 02:18 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 08:33 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:07 -0500
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:49 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:06 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:20 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 22:51 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 02:22 -0500
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-11-10 04:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-10 13:48 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-10 16:17 -0500
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-10 17:26 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:50 -1000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-09 12:15 +0000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:09 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 09:47 +0100
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-24 12:54 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 15:03 +0100
Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 13:18 +0100
Re: Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 14:08 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:30 +0000
Re: Stoked Bernd Linsel <bl1@gmx.com> - 2015-11-09 18:27 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-10 00:50 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:52 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:16 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:07 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:58 +0000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 12:00 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:49 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:24 +0000
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 17:30 -0700
Re: Stoked Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-10-29 02:40 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:11 +0000
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:07 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 21:16 -0700
Re: Stoked franck.bensusan@gmail.com - 2015-10-29 01:35 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:16 +0000
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:35 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:48 -0700
Re: Stoked mhx@iae.nl - 2015-10-29 11:31 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-29 12:01 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:26 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 15:29 -0400
Re: Stoked mhx@iae.nl - 2015-10-29 13:27 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 16:48 -0400
Re: Stoked josv@planet.nl - 2015-10-29 14:58 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:36 -0400
Re: Stoked josv@planet.nl - 2015-10-30 04:34 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:28 -0400
Re: Stoked josv@planet.nl - 2015-10-30 12:05 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:32 -0400
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 18:53 -1000
Re: Stoked josv@planet.nl - 2015-11-01 04:28 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-11-03 22:27 -0800
Re: Stoked mhx@iae.nl - 2015-10-29 16:47 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:33 -0400
Re: Stoked mhx@iae.nl - 2015-10-31 00:55 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:52 +0000
Re: Stoked josv@planet.nl - 2015-10-29 14:49 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:50 +0000
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 18:39 +0100
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 11:11 -0700
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 20:01 +0100
Re: Stoked hughaguilar96@gmail.com - 2015-10-28 12:34 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:09 -0700
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:25 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:01 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-29 01:58 -0400
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-28 23:34 -0700
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-29 08:56 +0100
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-28 18:41 -0400
Re: Stoked josv@planet.nl - 2015-10-29 05:28 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-12-12 11:25 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-12-12 08:43 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-12-16 13:45 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-12-17 10:26 -0800
Re: Stoked Rob Sciuk <rob@controlq.com> - 2015-12-13 23:29 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-13 22:31 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 15:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:57 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:36 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 14:57 +0000
Re: Stoked Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 20:25 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-03 20:39 -0800
Re: Stoked Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-28 16:27 -0700
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 05:57 -0700
Re: Stoked "HAA" <someone@microsoft.com> - 2015-11-02 13:15 +1100
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-02 02:08 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 09:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:37 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 10:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 10:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-28 18:14 +0000
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:20 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:16 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-30 12:13 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:34 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-11-07 13:57 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 17:19 -0500
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-09 00:10 -0800
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-12-12 18:52 -0800
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | josv@planet.nl |
|---|---|
| Date | 2015-10-30 04:34 -0700 |
| Message-ID | <e99188e4-3a12-4788-a79e-8ceaa4928e1a@googlegroups.com> |
| In reply to | #42989 |
Hi Rick,
Win32Forth is ITC and it produces high level Forth and not assembler.
That is not great for speed, but it makes it easy to understand.
The code is:
see test5
: INNER
BEGIN 1- DUP 0=
UNTIL ; ok
Jos
On 30 oktober 2015 06:36:26 UTC+1 rickman wrote:
> On 10/29/2015 5:58 PM, j...@planet.nl wrote:
> > Indeed:
> > : inner begin 1- dup 0= until ;
> > : test5 dup if inner then drop ;
> > cr 100000000 time-reset test5 .elapsed
> > \s Elapsed time: 00:00:00.296 ok
> > Jos
> >
> > On 29 oktober 2015 21:49:02 UTC+1 rickman wrote:
> >> I guess it all depends on what code the tools generate, but this might
> >> be shorter yet since it should only have one branch in the loop.
> >>
> >> : inner begin 1- dup 0= until ;
> >>
> >> : test dup if inner then drop ;
> >>
> >> --
> >>
> >> Rick
>
> Interesting. The speedup was not as large as Marcel's system produced.
> In his case this code was about twice as fast. Here the speedup was
> about 10%. Can you show the code produced?
>
> --
>
> Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-30 13:28 -0400 |
| Message-ID | <n1098l$tmi$1@dont-email.me> |
| In reply to | #42992 |
On 10/30/2015 7:34 AM, josv@planet.nl wrote: > On 30 oktober 2015 06:36:26 UTC+1 rickman wrote: >> On 10/29/2015 5:58 PM, j...@planet.nl wrote: >>> Indeed: >>> >>> On 29 oktober 2015 21:49:02 UTC+1 rickman wrote: >>>> I guess it all depends on what code the tools generate, but this might >>>> be shorter yet since it should only have one branch in the loop. >>>> >>>> : inner begin 1- dup 0= until ; >>>> >>>> : test dup if inner then drop ; >>>> >>>> -- >>>> >>>> Rick >> >> Interesting. The speedup was not as large as Marcel's system produced. >> In his case this code was about twice as fast. Here the speedup was >> about 10%. Can you show the code produced? It gets hard to compare when the results are in different posts so I am copying all the info here. > Hi Rick, > Win32Forth is ITC and it produces high level Forth and not assembler. > That is not great for speed, but it makes it easy to understand. > The code is: > > see test5 > : INNER > BEGIN 1- DUP 0= > UNTIL ; ok > Jos > > : test4 begin dup 0= if drop exit then 1- again ; > cr 100000000 time-reset test4 .elapsed > \ Elapsed time: 00:00:00.328 > \ Was 00:00:00.500 In Win32Forth > Jos >>> : inner begin 1- dup 0= until ; >>> : test5 dup if inner then drop ; >>> cr 100000000 time-reset test5 .elapsed >>> \s Elapsed time: 00:00:00.296 ok Ok, so I guess the overhead of executing each word swamps out the savings of eliminating a jump. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2015-10-30 12:05 -0700 |
| Message-ID | <10b3eb7c-f94e-4952-ae78-1270f3480ba4@googlegroups.com> |
| In reply to | #43002 |
Hi Rick, There will be a small advantage. But it is not as big as in optimized assembler. Jos On 30 oktober 2015 18:28:58 UTC+1 rickman wrote: > On 10/30/2015 7:34 AM, j...@planet.nl wrote: > > On 30 oktober 2015 06:36:26 UTC+1 rickman wrote: > >> On 10/29/2015 5:58 PM, j...@planet.nl wrote: > >>> Indeed: > >>> > >>> On 29 oktober 2015 21:49:02 UTC+1 rickman wrote: > >>>> I guess it all depends on what code the tools generate, but this might > >>>> be shorter yet since it should only have one branch in the loop. > >>>> > >>>> : inner begin 1- dup 0= until ; > >>>> > >>>> : test dup if inner then drop ; > >>>> > >>>> -- > >>>> > >>>> Rick > >> > >> Interesting. The speedup was not as large as Marcel's system produced. > >> In his case this code was about twice as fast. Here the speedup was > >> about 10%. Can you show the code produced? > > It gets hard to compare when the results are in different posts so I am > copying all the info here. > > > Hi Rick, > > Win32Forth is ITC and it produces high level Forth and not assembler. > > That is not great for speed, but it makes it easy to understand. > > The code is: > > > > see test5 > > : INNER > > BEGIN 1- DUP 0= > > UNTIL ; ok > > Jos > > > > : test4 begin dup 0= if drop exit then 1- again ; > > cr 100000000 time-reset test4 .elapsed > > \ Elapsed time: 00:00:00.328 > > \ Was 00:00:00.500 In Win32Forth > > Jos > >>> : inner begin 1- dup 0= until ; > >>> : test5 dup if inner then drop ; > >>> cr 100000000 time-reset test5 .elapsed > >>> \s Elapsed time: 00:00:00.296 ok > > Ok, so I guess the overhead of executing each word swamps out the > savings of eliminating a jump. > > -- > > Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-30 15:32 -0400 |
| Message-ID | <n10ggh$e9c$2@dont-email.me> |
| In reply to | #43003 |
On 10/30/2015 3:05 PM, josv@planet.nl wrote: > Hi Rick, > > There will be a small advantage. > But it is not as big as in optimized assembler. > > Jos > > On 30 oktober 2015 18:28:58 UTC+1 rickman wrote: >> On 10/30/2015 7:34 AM, j...@planet.nl wrote: >>> On 30 oktober 2015 06:36:26 UTC+1 rickman wrote: >>>> On 10/29/2015 5:58 PM, j...@planet.nl wrote: >>>>> Indeed: >>>>> >>>>> On 29 oktober 2015 21:49:02 UTC+1 rickman wrote: >>>>>> I guess it all depends on what code the tools generate, but this might >>>>>> be shorter yet since it should only have one branch in the loop. >>>>>> >>>>>> : inner begin 1- dup 0= until ; >>>>>> >>>>>> : test dup if inner then drop ; >>>>>> >>>>>> -- >>>>>> >>>>>> Rick >>>> >>>> Interesting. The speedup was not as large as Marcel's system produced. >>>> In his case this code was about twice as fast. Here the speedup was >>>> about 10%. Can you show the code produced? >> >> It gets hard to compare when the results are in different posts so I am >> copying all the info here. >> >>> Hi Rick, >>> Win32Forth is ITC and it produces high level Forth and not assembler. >>> That is not great for speed, but it makes it easy to understand. >>> The code is: >>> >>> see test5 >>> : INNER >>> BEGIN 1- DUP 0= >>> UNTIL ; ok >>> Jos >>> >>> : test4 begin dup 0= if drop exit then 1- again ; >>> cr 100000000 time-reset test4 .elapsed >>> \ Elapsed time: 00:00:00.328 >>> \ Was 00:00:00.500 In Win32Forth >>> Jos >>>>> : inner begin 1- dup 0= until ; >>>>> : test5 dup if inner then drop ; >>>>> cr 100000000 time-reset test5 .elapsed >>>>> \s Elapsed time: 00:00:00.296 ok >> >> Ok, so I guess the overhead of executing each word swamps out the >> savings of eliminating a jump. Yes, it seems with ITC code it is more important to optimize the number of words rather than worrying about what is being done within primitive words. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-30 18:53 -1000 |
| Message-ID | <JpSdnarE7Iau1KnLnZ2dnUU7-QGdnZ2d@supernews.com> |
| In reply to | #43005 |
On 10/30/15 9:32 AM, rickman wrote: > On 10/30/2015 3:05 PM, josv@planet.nl wrote: >> Hi Rick, >> >> There will be a small advantage. >> But it is not as big as in optimized assembler. >> >> Jos >> >> On 30 oktober 2015 18:28:58 UTC+1 rickman wrote: >>> On 10/30/2015 7:34 AM, j...@planet.nl wrote: >>>> On 30 oktober 2015 06:36:26 UTC+1 rickman wrote: >>>>> On 10/29/2015 5:58 PM, j...@planet.nl wrote: >>>>>> Indeed: >>>>>> >>>>>> On 29 oktober 2015 21:49:02 UTC+1 rickman wrote: >>>>>>> I guess it all depends on what code the tools generate, but this >>>>>>> might >>>>>>> be shorter yet since it should only have one branch in the loop. >>>>>>> >>>>>>> : inner begin 1- dup 0= until ; >>>>>>> >>>>>>> : test dup if inner then drop ; >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Rick >>>>> >>>>> Interesting. The speedup was not as large as Marcel's system >>>>> produced. >>>>> In his case this code was about twice as fast. Here the >>>>> speedup was >>>>> about 10%. Can you show the code produced? >>> >>> It gets hard to compare when the results are in different posts so I am >>> copying all the info here. >>> >>>> Hi Rick, >>>> Win32Forth is ITC and it produces high level Forth and not assembler. >>>> That is not great for speed, but it makes it easy to understand. >>>> The code is: >>>> >>>> see test5 >>>> : INNER >>>> BEGIN 1- DUP 0= >>>> UNTIL ; ok >>>> Jos >>>> >>>> : test4 begin dup 0= if drop exit then 1- again ; >>>> cr 100000000 time-reset test4 .elapsed >>>> \ Elapsed time: 00:00:00.328 >>>> \ Was 00:00:00.500 In Win32Forth >>>> Jos >>>>>> : inner begin 1- dup 0= until ; >>>>>> : test5 dup if inner then drop ; >>>>>> cr 100000000 time-reset test5 .elapsed >>>>>> \s Elapsed time: 00:00:00.296 ok >>> >>> Ok, so I guess the overhead of executing each word swamps out the >>> savings of eliminating a jump. > > Yes, it seems with ITC code it is more important to optimize the number > of words rather than worrying about what is being done within primitive > words. > I completely disagree. With good design, ITC Forth can be quite efficient, and the cost of more words is negligible. Of course, in the days when FORTH, Inc. was using ITC, we optimized our implementation considerably for the host processor. We made stable register assignments with the data and return stack pointers in registers as well as a pointer to the next word to be executed and a register dedicated to the multiprogrammer (pointing to the currently executing task). Several registers (at least two, and more depending on the CPU) were always scratch, so there was no saving/restoring of registers when words were invoked. Entering and exiting from a word took typically 2 instructions each, and on some processors it was faster than CALL/RET. Primitives were highly optimized. Our applications typically benchmarked somewhat slower that C, but were less than a quarter the size, and were developed much more quickly. And it was always possible to optimize critical functions to perform as fast as they needed to. The "number of words" impacts performance only at compile time. We also optimized dictionary structure and searches to minimize this, with techniques such as multiple dictionary chains, and as a result we could compile even the largest applications in a few seconds. I would never, never advocate limiting the number of words in an application! There is no doubt that the modern optimizing compilers made possible by Forth94 are faster than ITC, but with care an ITC implementation can deliver excellent performance. 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 | josv@planet.nl |
|---|---|
| Date | 2015-11-01 04:28 -0800 |
| Message-ID | <e40967eb-9342-4355-bbee-782c0c97f371@googlegroups.com> |
| In reply to | #43016 |
A faster ITC system for Win32Forth would be nice. Perhaps that will happen in the future. It would be great if there is anyone willing to provide some code. Jos. On 31 oktober 2015 05:53:09 UTC+1 Elizabeth D. Rather wrote: > On 10/30/15 9:32 AM, rickman wrote: > > On 10/30/2015 3:05 PM, j....@planet.nl wrote: > >> Hi Rick, > >> > >> There will be a small advantage. > >> But it is not as big as in optimized assembler. > >> > >> Jos > >> > >> On 30 oktober 2015 18:28:58 UTC+1 rickman wrote: > >>> On 10/30/2015 7:34 AM, j...@planet.nl wrote: > >>>> On 30 oktober 2015 06:36:26 UTC+1 rickman wrote: > >>>>> On 10/29/2015 5:58 PM, j...@planet.nl wrote: > >>>>>> Indeed: > >>>>>> > >>>>>> On 29 oktober 2015 21:49:02 UTC+1 rickman wrote: > >>>>>>> I guess it all depends on what code the tools generate, but this > >>>>>>> might > >>>>>>> be shorter yet since it should only have one branch in the loop. > >>>>>>> > >>>>>>> : inner begin 1- dup 0= until ; > >>>>>>> > >>>>>>> : test dup if inner then drop ; > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Rick > >>>>> > >>>>> Interesting. The speedup was not as large as Marcel's system > >>>>> produced. > >>>>> In his case this code was about twice as fast. Here the > >>>>> speedup was > >>>>> about 10%. Can you show the code produced? > >>> > >>> It gets hard to compare when the results are in different posts so I am > >>> copying all the info here. > >>> > >>>> Hi Rick, > >>>> Win32Forth is ITC and it produces high level Forth and not assembler. > >>>> That is not great for speed, but it makes it easy to understand. > >>>> The code is: > >>>> > >>>> see test5 > >>>> : INNER > >>>> BEGIN 1- DUP 0= > >>>> UNTIL ; ok > >>>> Jos > >>>> > >>>> : test4 begin dup 0= if drop exit then 1- again ; > >>>> cr 100000000 time-reset test4 .elapsed > >>>> \ Elapsed time: 00:00:00.328 > >>>> \ Was 00:00:00.500 In Win32Forth > >>>> Jos > >>>>>> : inner begin 1- dup 0= until ; > >>>>>> : test5 dup if inner then drop ; > >>>>>> cr 100000000 time-reset test5 .elapsed > >>>>>> \s Elapsed time: 00:00:00.296 ok > >>> > >>> Ok, so I guess the overhead of executing each word swamps out the > >>> savings of eliminating a jump. > > > > Yes, it seems with ITC code it is more important to optimize the number > > of words rather than worrying about what is being done within primitive > > words. > > > > I completely disagree. With good design, ITC Forth can be quite > efficient, and the cost of more words is negligible. Of course, in the > days when FORTH, Inc. was using ITC, we optimized our implementation > considerably for the host processor. We made stable register assignments > with the data and return stack pointers in registers as well as a > pointer to the next word to be executed and a register dedicated to the > multiprogrammer (pointing to the currently executing task). Several > registers (at least two, and more depending on the CPU) were always > scratch, so there was no saving/restoring of registers when words were > invoked. Entering and exiting from a word took typically 2 instructions > each, and on some processors it was faster than CALL/RET. Primitives > were highly optimized. Our applications typically benchmarked somewhat > slower that C, but were less than a quarter the size, and were developed > much more quickly. And it was always possible to optimize critical > functions to perform as fast as they needed to. > > The "number of words" impacts performance only at compile time. We also > optimized dictionary structure and searches to minimize this, with > techniques such as multiple dictionary chains, and as a result we could > compile even the largest applications in a few seconds. I would never, > never advocate limiting the number of words in an application! > > There is no doubt that the modern optimizing compilers made possible by > Forth94 are faster than ITC, but with care an ITC implementation can > deliver excellent performance. > > 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-03 22:27 -0800 |
| Message-ID | <e9dfa686-5321-48c7-ab97-1c90e635b31b@googlegroups.com> |
| In reply to | #43016 |
On Friday, October 30, 2015 at 9:53:09 PM UTC-7, Elizabeth D. Rather wrote: > Our [PolyForth] applications typically benchmarked somewhat > slower that C, but were less than a quarter the size, and were developed > much more quickly. And it was always possible to optimize critical > functions to perform as fast as they needed to. I benchmarked UR/Forth and found the speed to be essentially the same as Turbo-C generating code for the small memory-model. PolyForth wasn't "somewhat slower" than C --- PolyForth was somewhat slower than QBASIC --- not even in the same ballpark as C. > There is no doubt that the modern optimizing compilers made possible by > Forth94 are faster than ITC, but with care an ITC implementation can > deliver excellent performance. > > Cheers, > Elizabeth To say that ANS-Forth made optimizing compilers possible is a gross lie. ANS-Forth is a purely negative contribution to Forth. Tom Almy's CMP-Forth and Tom Zimmer's TCOM both provided better optimization for Forth-83 20 years ago than SwiftForth does for ANS-Forth today. This is what Jeff Fox told me in a private email: --------------------------------------------------------------------- For many years Rather posted tons of garbage about Chuck and would argue with me about simple facts over and over, always claiming to have forgotten the facts every couple of years. She never heard of Chuck after he left Forth Inc. She never heard about things like cmForth and continued to make claims that she never heard of optimzing native code Forth compilers that were published a decade before ANS. She preferred to pretend to be ingnorant and have a bad memory. For years I did not think that there was any way to prevent Elizabeth from posting garbage about Chuck and his work. All I could do was correct her year after year and put up the abuse. It almost seemed like she was trying to blackmail Chuck. Then IntellaSys paid her some obscene amount of money to write a little (poorly written) documenation on SEAforth. Then she had no excuse to claim complete ignorance. That's when I realized that it had been blackmail. The way to get her to stop posting lies was simply to pay her off. Once IntellaSys quit paying her she began posting garbage again. --------------------------------------------------------------------- You are a liar --- you think that with Jeff Fox dead you can post gross lies and get away with it --- but your lies will always be obvious.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-10-29 16:47 -0700 |
| Message-ID | <6cc25a67-4328-42c2-a282-a8f31434d3f7@googlegroups.com> |
| In reply to | #42981 |
On Thursday, October 29, 2015 at 9:49:02 PM UTC+1, rickman wrote: > On 10/29/2015 4:27 PM, mhx@iae.nl wrote: > > On Thursday, October 29, 2015 at 8:29:54 PM UTC+1, rickman wrote: > >> On 10/29/2015 2:31 PM, mhx@iae.nl wrote: [..] > > I guess it all depends on what code the tools generate, but this might > be shorter yet since it should only have one branch in the loop. > > : inner begin 1- dup 0= until ; > > : test dup if inner then drop ; FORTH> : inner begin 1- dup 0= until ; ok FORTH> : test dup if inner then drop ; ok FORTH> timer-reset 1e8 f>s test .elapsed 0.026 seconds elapsed. ok FORTH> ' test idis $01220B80 : test $01220B8A pop rbx $01220B8B cmp rbx, 0 b# $01220B8F je $01220BA9 offset NEAR $01220B95 mov rax, rax $01220B98 lea rdi, [rbx -1 +] qword $01220B9C cmp rdi, 0 b# $01220BA0 mov rbx, rdi $01220BA3 jne $01220B98 offset NEAR $01220BA9 ; Indeed, I doubt that can be improved. -marcel
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-30 01:33 -0400 |
| Message-ID | <n0uvb7$17n$1@dont-email.me> |
| In reply to | #42985 |
On 10/29/2015 7:47 PM, mhx@iae.nl wrote: > On Thursday, October 29, 2015 at 9:49:02 PM UTC+1, rickman wrote: >> On 10/29/2015 4:27 PM, mhx@iae.nl wrote: >>> On Thursday, October 29, 2015 at 8:29:54 PM UTC+1, rickman wrote: >>>> On 10/29/2015 2:31 PM, mhx@iae.nl wrote: > [..] >> >> I guess it all depends on what code the tools generate, but this might >> be shorter yet since it should only have one branch in the loop. >> >> : inner begin 1- dup 0= until ; >> >> : test dup if inner then drop ; > > FORTH> : inner begin 1- dup 0= until ; ok > FORTH> : test dup if inner then drop ; ok > FORTH> timer-reset 1e8 f>s test .elapsed 0.026 seconds elapsed. ok > FORTH> ' test idis > $01220B80 : test > $01220B8A pop rbx > $01220B8B cmp rbx, 0 b# > $01220B8F je $01220BA9 offset NEAR > $01220B95 mov rax, rax > $01220B98 lea rdi, [rbx -1 +] qword > $01220B9C cmp rdi, 0 b# > $01220BA0 mov rbx, rdi > $01220BA3 jne $01220B98 offset NEAR > $01220BA9 ; > > Indeed, I doubt that can be improved. Wow, I'm surprised it was so much faster. Looks like the code was inlined with inner being inserted into test rather than called. That call was not of great consequence since it would only be executed once. Still that's pretty nice. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-10-31 00:55 -0700 |
| Message-ID | <f0849c22-4bd9-4984-b933-fb2024b75e2f@googlegroups.com> |
| In reply to | #42985 |
On Friday, October 30, 2015 at 12:47:18 AM UTC+1, m...@iae.nl wrote: > On Thursday, October 29, 2015 at 9:49:02 PM UTC+1, rickman wrote: > > On 10/29/2015 4:27 PM, mhx@iae.nl wrote: > > > On Thursday, October 29, 2015 at 8:29:54 PM UTC+1, rickman wrote: > > >> On 10/29/2015 2:31 PM, mhx@iae.nl wrote: > [..] > > > > I guess it all depends on what code the tools generate, but this might > > be shorter yet since it should only have one branch in the loop. > > > > : inner begin 1- dup 0= until ; > > > > : test dup if inner then drop ; > > FORTH> : inner begin 1- dup 0= until ; ok > FORTH> : test dup if inner then drop ; ok > FORTH> timer-reset 1e8 f>s test .elapsed 0.026 seconds elapsed. ok > FORTH> ' test idis > $01220B80 : test > $01220B8A pop rbx > $01220B8B cmp rbx, 0 b# > $01220B8F je $01220BA9 offset NEAR > $01220B95 mov rax, rax > $01220B98 lea rdi, [rbx -1 +] qword > $01220B9C cmp rdi, 0 b# > $01220BA0 mov rbx, rdi > $01220BA3 jne $01220B98 offset NEAR > $01220BA9 ; > > Indeed, I doubt that can be improved. > > -marcel > Indeed, I doubt that can be improved. Why do I think so? I use a 3.4GHz processor -> 1 clock tick is 294.1 ps. 26ms divided by 100,000,000 iterations is 260 ps. That should therefore have been 294.1 ps, 1 clock tick, too. Apparently the instructions of the main loop: lea rdi, [rbx -1 +] qword cmp rdi, 0 b# mov rbx, rdi jne $01220B98 offset NEAR are all done in parallel. Removing instructions or using alternative ones can not make it faster, only shorter. Nice to have a program that is really finished and cannot be improved speedwise. There is a possibility to make it shorter of course, because it currently takes more than 1 byte. That was not the question, though. -marcel
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-30 11:52 +0000 |
| Message-ID | <563359a4.53338941@news.eternal-september.org> |
| In reply to | #42980 |
Oops, the VFX tokeniser ... TEST ( 004CABE0 85DB ) TEST EBX, EBX ( 004CABE2 0F8405000000 ) JZ/E 004CABED ( 004CABE8 4B ) DEC EBX ( 004CABE9 85DB ) TEST EBX, EBX ( 004CABEB 75FB ) JNZ/NE 004CABE8 ( 004CABED 8B5D00 ) MOV EBX, [EBP] ( 004CABF0 8D6D04 ) LEA EBP, [EBP+04] ( 004CABF3 C3 ) NEXT, ( 20 bytes, 8 instructions ) ok 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 | josv@planet.nl |
|---|---|
| Date | 2015-10-29 14:49 -0700 |
| Message-ID | <dbe75bce-2e58-4d10-9b3f-ed7eb8f67564@googlegroups.com> |
| In reply to | #42978 |
: test4 begin dup 0= if drop exit then 1- again ; cr 100000000 time-reset test4 .elapsed \ Elapsed time: 00:00:00.328 \ Was 00:00:00.500 In Win32Forth Jos On 29 oktober 2015 20:29:54 UTC+1 rickman wrote: > On 10/29/2015 2:31 PM, m...@iae.nl wrote: > > On Thursday, October 29, 2015 at 12:24:43 AM UTC+1, Stephen Pelc wrote: > > [..] > >> : test begin ?dup if 1 - else exit then again ; ok > > [..] > >> ticks 100000000 test ticks swap - . 125 > >> > >> That's 0.125 seconds. > > [..]
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-30 11:50 +0000 |
| Message-ID | <5633590f.53190100@news.eternal-september.org> |
| In reply to | #42978 |
On Thu, 29 Oct 2015 15:29:51 -0400, rickman <gnuarm@gmail.com> wrote: >How does this version compare to the while version? > >: test begin dup 0= if drop exit then 1- again ; : inner begin 1- dup 0= until ; ok ok : test dup if inner then drop ; ok ticks 100000000 test ticks swap - . 47 ok That's 0.047 seconds. dis inner INNER ( 004CABB0 4B ) DEC EBX ( 004CABB1 85DB ) TEST EBX, EBX ( 004CABB3 75FB ) JNZ/NE 004CABB0 INNER ( 004CABB5 C3 ) NEXT, ( 6 bytes, 4 instructions ) ok 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 | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-10-28 18:39 +0100 |
| Message-ID | <563107e5$0$23721$e4fe514c@news.xs4all.nl> |
| In reply to | #42902 |
Chris Curl wrote: > It is not very fast though ... > > : test begin ?dup if 1 - else exit then again ; > > 10000000 test \ about 6 seconds for 10 million iterations No, it isn't. Wonder how you made it so slow. Mine isn't a speed monster either (slower than gforth). It's a bytecode compiler, written in C (compiled with GCC goto extensions) and runs on top of an old P4: : test begin dup if 1- else drop exit then again ; 10000000 test \ about 6 seconds for 10 million iterations habe@linux-471m:~/4th.dev> time pp4th -x tt2.4th real 0m0.267s user 0m0.196s sys 0m0.004s habe@linux-471m:~/4th.dev> Sorry, mate. :-( At least you're showing it to the right audience ;-) There are people here who can help you. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-10-28 11:11 -0700 |
| Message-ID | <7d286476-084f-4e82-8f29-24e382e8040b@googlegroups.com> |
| In reply to | #42913 |
On Wednesday, October 28, 2015 at 1:37:42 PM UTC-4, The Beez wrote: > No, it isn't. Wonder how you made it so slow. Mine isn't a speed monster > either (slower than gforth). It's a bytecode compiler, written in C > (compiled with GCC goto extensions) and runs on top of an old P4: > > : test begin dup if 1- else drop exit then again ; > > 10000000 test \ about 6 seconds for 10 million iterations > > habe@linux-471m:~/4th.dev> time pp4th -x tt2.4th > > real 0m0.267s > user 0m0.196s > sys 0m0.004s > habe@linux-471m:~/4th.dev> > > Sorry, mate. :-( At least you're showing it to the right audience ;-) > There are people here who can help you. > > Hans Bezemer FWIW, I misspoke ... it is 6 seconds for 100 million iterations, not 10 million. And my C++ implementation was admittedly very crude ... I was not even thinking at all about efficiency.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-10-28 20:01 +0100 |
| Message-ID | <56311b26$0$23859$e4fe514c@news.xs4all.nl> |
| In reply to | #42915 |
Chris Curl wrote: > On Wednesday, October 28, 2015 at 1:37:42 PM UTC-4, The Beez wrote: >> No, it isn't. Wonder how you made it so slow. Mine isn't a speed monster >> either (slower than gforth). It's a bytecode compiler, written in C >> (compiled with GCC goto extensions) and runs on top of an old P4: >> real 0m0.267s >> user 0m0.196s >> sys 0m0.004s >> habe@linux-471m:~/4th.dev> > FWIW, I misspoke ... it is 6 seconds for 100 million iterations, not 10 > million. And my C++ implementation was admittedly very crude ... I was not > even thinking at all about efficiency. <some snipping done> habe@linux-471m:~/4th.dev> time pp4th -x tt2.4th real 0m1.682s user 0m1.576s sys 0m0.008s habe@linux-471m:~/4th.dev> I don't know what your platform is, but yes, still room for improvement. Doing the VM as a switch() helped FICL. Here are a few pointers: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html https://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Labels-as-Values.html What helps significantly is NOT to push/pop values all the time, but change the stack directly - preferably using inlining. Maybe this is of some inspiration. Saved me about 50%. #define DFREE(a) if((ToRS-ToS)<(a))throw(M4SOVFLW) #define RFREE(a) if((ToRS-ToS)<(a))throw(M4ROVFLW) #define DSIZE(a) if(ToS<(a))throw(M4SEMPTY) #define RSIZE(a) if(ToRS>(Rp0-(a)))throw(M4REMPTY) #define DPOP (Stack[--ToS]) #define DPUSH(a) (Stack[ToS++]=(a)) #define RPOP (Stack[++ToRS]) #define RPUSH(a) (Stack[ToRS--]=(a)) #define DDROP ToS-- #define RDROP ToRS++ #define RS(a) (Stack[ToRS+(a)]) #define DS(a) (Stack[ToS-(a)]) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-28 12:34 -0700 |
| Message-ID | <de074cf1-7e7f-4ab3-a424-8215c9449125@googlegroups.com> |
| In reply to | #42915 |
On Wednesday, October 28, 2015 at 11:11:44 AM UTC-7, Chris Curl wrote: > On Wednesday, October 28, 2015 at 1:37:42 PM UTC-4, The Beez wrote: > > No, it isn't. Wonder how you made it so slow. Mine isn't a speed monster > > either (slower than gforth). It's a bytecode compiler, written in C > > (compiled with GCC goto extensions) and runs on top of an old P4: > > > > : test begin dup if 1- else drop exit then again ; > > > > 10000000 test \ about 6 seconds for 10 million iterations > > > > habe@linux-471m:~/4th.dev> time pp4th -x tt2.4th > > > > real 0m0.267s > > user 0m0.196s > > sys 0m0.004s > > habe@linux-471m:~/4th.dev> > > > > Sorry, mate. :-( At least you're showing it to the right audience ;-) > > There are people here who can help you. > > > > Hans Bezemer > FWIW, I misspoke ... it is 6 seconds for 100 million iterations, not 10 million. And my C++ implementation was admittedly very crude ... I was not even thinking at all about efficiency. Is it written in assembly-language or C++? If you have a Forth written in assembly-language, can you give us a link so we can download it? I would be interested in seeing what you have.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-10-28 13:09 -0700 |
| Message-ID | <7a2c8c94-4ebd-44bb-860f-4d91b379e48c@googlegroups.com> |
| In reply to | #42924 |
On Wednesday, October 28, 2015 at 3:34:48 PM UTC-4, hughag...@gmail.com wrote: > On Wednesday, October 28, 2015 at 11:11:44 AM UTC-7, Chris Curl wrote: > > On Wednesday, October 28, 2015 at 1:37:42 PM UTC-4, The Beez wrote: > > > No, it isn't. Wonder how you made it so slow. Mine isn't a speed monster > > > either (slower than gforth). It's a bytecode compiler, written in C > > > (compiled with GCC goto extensions) and runs on top of an old P4: > > > > > > : test begin dup if 1- else drop exit then again ; > > > > > > 10000000 test \ about 6 seconds for 10 million iterations > > > > > > habe@linux-471m:~/4th.dev> time pp4th -x tt2.4th > > > > > > real 0m0.267s > > > user 0m0.196s > > > sys 0m0.004s > > > habe@linux-471m:~/4th.dev> > > > > > > Sorry, mate. :-( At least you're showing it to the right audience ;-) > > > There are people here who can help you. > > > > > > Hans Bezemer > > FWIW, I misspoke ... it is 6 seconds for 100 million iterations, not 10 million. And my C++ implementation was admittedly very crude ... I was not even thinking at all about efficiency. > > Is it written in assembly-language or C++? > > If you have a Forth written in assembly-language, can you give us a link so we can download it? I would be interested in seeing what you have. I have one written in C++ and another one written in x86 assembly. I am planning to upload the assembly language one to GitHub tonight. Be easy on me when looking at it ... it is a first pass and still pretty dang rough around the edges.
[toc] | [prev] | [next] | [standalone]
| From | François <francois.ganza@wanadoo.fr> |
|---|---|
| Date | 2015-10-28 15:25 -0700 |
| Message-ID | <c3352914-d08f-4470-bdee-8f3e287c5204@googlegroups.com> |
| In reply to | #42902 |
Le mercredi 28 octobre 2015 17:18:09 UTC+1, Chris Curl a écrit : > It is not very fast though ... > > : test begin ?dup if 1 - else exit then again ; > > 10000000 test \ about 6 seconds for 10 million iterations what OS ? what processor ?
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-10-28 21:01 -0700 |
| Message-ID | <86eaf2c7-4d6b-4a8a-93cb-6778f9e24de5@googlegroups.com> |
| In reply to | #42932 |
On Wednesday, October 28, 2015 at 6:25:38 PM UTC-4, François wrote: > Le mercredi 28 octobre 2015 17:18:09 UTC+1, Chris Curl a écrit : > > It is not very fast though ... > > > > : test begin ?dup if 1 - else exit then again ; > > > > 10000000 test \ about 6 seconds for 100 million iterations > > what OS ? > what processor ? i misspoke ... it's 6 seconds for 100 million, not 10 million windows 10 amd fx-8350
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web