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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-10-29 01:58 -0400 |
| Message-ID | <op.x686vt13yfako5@localhost> |
| In reply to | #42944 |
On Thu, 29 Oct 2015 00:01:49 -0400, Chris Curl <ccurl609@gmail.com> wrote: > 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 > A 4Ghz AMD FX-8350 using one core (of 8) should be slightly faster than 3.2Ghz AMD Phenom II X2 555 using one core (of 2). http://cpuboss.com/cpu/AMD-FX-8350 http://cpuboss.com/cpu/AMD-Phenom-II-X2-555 So, I'd guess that it's in line with what I posted for my Forth ... unless ... it's multi-threaded on Windows 10. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-10-28 23:34 -0700 |
| Message-ID | <65074ffb-f52c-4dea-8388-be9f0ac08a6c@googlegroups.com> |
| In reply to | #42949 |
My LFTForth which is kind a token threaded system, written in C entirely, the primitives are not optimized, much on the contrary, every stack access is checked for underflow and overflow: On my AMD A6-3650 at 2.6GHz: 4 seconds for 100M loop Probably using one core... The system is compiled with mingw -Os and no frame pointer, on a 32bit Win7.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-10-29 08:56 +0100 |
| Message-ID | <86twpa5cr9.fsf@vps34351.public.cloudvps.com> |
| In reply to | #42944 |
Chris Curl <ccurl609@gmail.com> writes: > : test begin ?dup if 1 - else exit then again ; > 10000000 test \ about 6 seconds for 100 million iterations My toy Forth, with only 12 primitives coded in C: 140 seconds With 32 primitives coded in assembly language: 2.3 seconds Intel Core i3 1.33GHz
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-10-28 18:41 -0400 |
| Message-ID | <op.x68mmubnyfako5@localhost> |
| In reply to | #42902 |
On Wed, 28 Oct 2015 12:18:07 -0400, Chris Curl <ccurl609@gmail.com> 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 > As you noted, that's 100M. I get 7 seconds for my interpreted Forth for 100M. That uses C's ctime() which reports with only one second of accuracy. It's a mix of C and Forth. It's mostly Forth now with just the primitives in C. It's an actual ITC Forth in C, not usual C style switch() based Forth. There is no optimization of any kind, except maybe the way some words were coded. It's run on 32-bit MS-DOS with only one core of a dual core 3.2Ghz AMD Phenom II X2 555. I haven't tested my Forth on 64-bit Linux yet. From past tests, I'm sure that at least one of the three Forth I have installed for Windows 98/SE is much faster on loops. I have gForth-ITC, bigForth, and Win32Forth. IIRC, Win32Forth is the one which is hyper-fast on loops, but is up to 50% slower on other Forth code. IIRC, gForth-ITC is about twice as slow as mine, in general. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2015-10-29 05:28 -0700 |
| Message-ID | <cb88b9f1-3ae6-41cc-b0de-9da1a9888d4f@googlegroups.com> |
| In reply to | #42934 |
October 28th, 2015 23:40:59 UTC+1 Rod Pemberton wrote: > On Wed, 28 Oct 2015 12:18:07 -0400, Chris Curl <c...@gmail.com> 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 > > > > As you noted, that's 100M. > > I get 7 seconds for my interpreted Forth for 100M. > That uses C's ctime() which reports with only one > second of accuracy. > > It's a mix of C and Forth. It's mostly Forth now > with just the primitives in C. It's an actual ITC > Forth in C, not usual C style switch() based Forth. > There is no optimization of any kind, except maybe > the way some words were coded. > > It's run on 32-bit MS-DOS with only one core of a > dual core 3.2Ghz AMD Phenom II X2 555. I haven't > tested my Forth on 64-bit Linux yet. > > From past tests, I'm sure that at least one of the > three Forth I have installed for Windows 98/SE is > much faster on loops. I have gForth-ITC, bigForth, > and Win32Forth. IIRC, Win32Forth is the one which > is hyper-fast on loops, but is up to 50% slower on > other Forth code. IIRC, gForth-ITC is about twice > as slow as mine, in general. > > > Rod Pemberton > > > -- > When El Chapo is the most beloved man in Mexico and Trump is the most hated, > it shows that Mexico is truly fouled up. >Win32Forth is the one which is hyper-fast on loops Indeed, it made me wonder if I did something wrong. At 3.3 Ghz on my I7 I get the following results: : test ( n - ) begin ?dup if 1 - else exit then again ; cr 100000000 dup dup 1 U,.R \ 100,000,000 cr time-reset test .elapsed \ Elapsed time: 00:00:00.500 : test2 ( n - ) begin dup while 1 - repeat drop ; cr time-reset dup test2 .elapsed \ Elapsed time: 00:00:00.422 needs src\lib\fmacro\fmacro.f \ Using fmacro.f for limited Forth-like statements in code: code test3 ( n - ) begin dup while 1 ass-lit - repeat drop next, end-code cr time-reset test3 .elapsed \ Elapsed time: 00:00:00.297 \s Jos
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-12-12 11:25 -0500 |
| Message-ID | <op.x9jg8ac6yfako5@localhost> |
| In reply to | #42934 |
On Wed, 28 Oct 2015 18:41:08 -0400, Rod Pemberton <boo@fasdfrewar.cdm> wrote: > On Wed, 28 Oct 2015 12:18:07 -0400, Chris Curl <ccurl609@gmail.com> 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 >> > > As you noted, that's 100M. > > I get 7 seconds for my interpreted Forth for 100M. > That uses C's ctime() which reports with only one > second of accuracy. Just for reference, I converted the test code to C code via a conversion program I wrote, and all the high-level Forth words called by the routine too right down to my primitives. Then, I patched in my Forth primitives in C, C stack code, and other necessary C code to compile it. So, the test C code is effectively the same exact code which executes when the Forth is interpreted, but without the interpreter being present. The only difference is the test C code uses C's native control-flow instead of converting the control-flow words to C, i.e., BEGIN AGAIN IF ELSE THEN are not converted into equivalent code. I timed it. It's right on the boundary between 3 and 4 four seconds. So, the interpreter is twice as slow (7 seconds) as the code without the interpreter (3.5 seconds). Of course, there is a speed improvement due to the use of C's control-flow instead of needing to interpret the Forth control-flow words. I'm not sure if the overhead is mostly due to the interpreter, or if it's the control-flow, or if it's an even balance between them, but I suspect the interpreter itself. I suspect the equivalent code coded natively in C would likely be substantially faster. Rod Pemberton -- The idea sentient beings can be suppressed by a few simple rules is a farce. Even so, Isaac Asimov posited such rules for sentient artificial intelligence.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-12 08:43 -1000 |
| Message-ID | <DvadnZ3MJORS9_HLnZ2dnUU7-e2dnZ2d@supernews.com> |
| In reply to | #44217 |
On 12/12/15 6:25 AM, Rod Pemberton wrote: > On Wed, 28 Oct 2015 18:41:08 -0400, Rod Pemberton <boo@fasdfrewar.cdm> > wrote: > >> On Wed, 28 Oct 2015 12:18:07 -0400, Chris Curl <ccurl609@gmail.com> >> 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 >>> >> >> As you noted, that's 100M. >> >> I get 7 seconds for my interpreted Forth for 100M. >> That uses C's ctime() which reports with only one >> second of accuracy. > > Just for reference, I converted the test code to C code > via a conversion program I wrote, and all the high-level > Forth words called by the routine too right down to my > primitives. Then, I patched in my Forth primitives in > C, C stack code, and other necessary C code to compile it. > > So, the test C code is effectively the same exact code > which executes when the Forth is interpreted, but without > the interpreter being present. The only difference is > the test C code uses C's native control-flow instead of > converting the control-flow words to C, i.e., BEGIN AGAIN > IF ELSE THEN are not converted into equivalent code. > > I timed it. It's right on the boundary between 3 and > 4 four seconds. So, the interpreter is twice as slow > (7 seconds) as the code without the interpreter (3.5 > seconds). > > Of course, there is a speed improvement due to the use > of C's control-flow instead of needing to interpret > the Forth control-flow words. I'm not sure if the > overhead is mostly due to the interpreter, or if it's > the control-flow, or if it's an even balance between > them, but I suspect the interpreter itself. > > I suspect the equivalent code coded natively in C would > likely be substantially faster. Interpreted Forths vary widely in performance. When FORTH, Inc. was promoting polyFORTH, we benchmarked it at ~10x faster than figFORTH implementations, for example. However, there's no doubt that optimized code compiling implementations are significantly faster. 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-12-16 13:45 -0800 |
| Message-ID | <92daa4d5-0331-45fc-954f-7b7fc113d57f@googlegroups.com> |
| In reply to | #44222 |
On Saturday, December 12, 2015 at 11:43:28 AM UTC-7, Elizabeth D. Rather wrote: > Interpreted Forths vary widely in performance. When > FORTH, Inc. was promoting polyFORTH, we benchmarked > it at ~10x faster than figFORTH implementations When you were promoting polyFORTH you were full of b.s. --- you continued to make wildly grandiose claims about ANS-Forth --- you have surrounded yourself with sycophants who cheerfully and blindly agree with all this b.s.. ANS-Forth is a cult built on a foundation of b.s.. The truth is that aren't very many ways to write NEXT --- UR/Forth had DTC and it was faster than ITC on the simple processors such as the 16-bit x86 --- DTC isn't necessarily faster than ITC on modern processors however because it results in a lot of code-cache thrashing (STC, if it is bloated like in SwiftForth, can also result in code-cache thrashing). You have to actually know assembly-language to say anything about the subject, but even still there isn't generally any magic bullet that results in a 10-fold increase in speed.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-12-17 10:26 -0800 |
| Message-ID | <36c2771c-3654-4ab0-95dc-5a8a441260d4@googlegroups.com> |
| In reply to | #44280 |
On Wednesday, December 16, 2015 at 2:45:59 PM UTC-7, hughag...@gmail.com wrote: > You have to actually know assembly-language to say anything about the subject, but even still there isn't generally any magic bullet that results in a 10-fold increase in speed. UR/Forth was the best Forth system of the MS-DOS era. It had machine-code in the CS segment. The threaded-code and the application data were in the DS segment (the dictionary headers and hash-table were in another segment accessed by ES). As programs grew, the DS segment tended to fill up, but there was usually lots of room remaining in the CS segment. The solution was to rewrite the time-critical code in assembly-language. This reduced memory usage in the DS segment and moved it over to the CS segment --- also, of course, this boosted the speed of the program. UR/Forth was DTC. Every Forth word had a small machine-code partg (the DOCOLON code for colon words) that was in the CS segment. This didn't take up memory in the DS segment --- by comparison, an ITC implementation would have a pointer in the front of every word that takes up one cell of memory in the DS segment --- so, ITC is not only faster (one less memory access in NEXT, but also takes up less memory in the DS segment where memory usage is most critical). The UR/Forth implementation was better than STC (such as used by Tom Almy's CMPforth) because it used memory more efficiently and hence allowed programs to be larger. OTOH, I think CMPforth programs were faster than UR/Forth --- CMPforth was mostly used in x86 micro-controller applications, whereas UR/Forth was for x86 desktop applications. PolyForth had everything (threaded-code, machine-code, application data, compiler, dictionary headers) all in a single 64KB segment. Because of this, only extremely small programs could be supported. Also, rewriting Forth code in assembly-language didn't move the code from DS to CS (because DS and CS were set to the same segment), and hence did not reduce memory usage --- machine-code tends to be bigger than threaded code, so doing this increased memory usage --- because of this, the PolyForth programmers were discouraged from using assembly-language and hence the programs tended to be abysmally slow. PolyForth and figForth were both derived from MicroForth that had been written by Charles Moore. When Charles Moore was working at Forth Inc., he was primarily programming for the PDP-11. His design was reasonably good given the PDP-11's constraints (a single 64KB segment and only 8 registers). So, I'm not saying that Charles Moore was a bad programmer --- it is just that his PDP-11 design shouldn't have been ported directly to the 8086 because it didn't take advantage of the 8086's multi-segment architecture --- Charles Moore can't be blamed for not predicting the x86 architecture when he was programming for the PDP-11, and I'm sure that if he had still been at Forth Inc. when the 8086 and MS-DOS were introduced he would have developed a PolyForth that was similar to UR/Forth. I think that a good Forth programmer is one who is alert to the architecture of the processor that he is programming for, and is able to adapt to that architecture --- a bad programmer is one who always takes old programs (usually written by somebody else) and modifies them slightly to do something new or to run on a new architecture. Bad programmers are known as "script kiddies" nowadays. The reason why Elizabeth Rather tirelessly promotes cut-and-paste programming is because she has never progressed beyond the script-kiddie level --- the "bulging back-pocket" that she often brags about is full of programs written by somebody else, and her plan is to modify them slightly to do something new, and then her plan is to take full credit for writing the programs and proclaim herself to be the "leading expert" on Forth programming. If Forth is going to be taken seriously as a language for commercial programming, we can't have a script-kiddie set the Standard for us, but we have to learn actual programming --- also, it is a good idea to not make wild claims about how our code is 10 times faster than the competition's, as people know immediately that this is a lie --- I wrote several programs in both UR/Forth and Turbo-C (Small memory-model) and when I timed them I found that Forth and C code was very close in speed --- just telling the truth is enough to give Forth a good reputation, and there is no need to fudge the data.
[toc] | [prev] | [next] | [standalone]
| From | Rob Sciuk <rob@controlq.com> |
|---|---|
| Date | 2015-12-13 23:29 -0500 |
| Message-ID | <alpine.BSF.2.20.1512132317370.6918@localhost> |
| In reply to | #44217 |
On Sat, 12 Dec 2015, Rod Pemberton wrote:
> Date: Sat, 12 Dec 2015 11:25:12 -0500
> From: Rod Pemberton <boo@fasdfrewar.cdm>
> Newsgroups: comp.lang.forth
> Subject: Re: Stoked
>
> On Wed, 28 Oct 2015 18:41:08 -0400, Rod Pemberton <boo@fasdfrewar.cdm> wrote:
>
>> On Wed, 28 Oct 2015 12:18:07 -0400, Chris Curl <ccurl609@gmail.com> 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
>>>
>>
>> As you noted, that's 100M.
>>
>> I get 7 seconds for my interpreted Forth for 100M.
>> That uses C's ctime() which reports with only one
>> second of accuracy.
As a second reference point:
In order to test with proper accuracy, you might wish to implement a
micro-second timer, as I have done with the OneFileForth (miniforth).
Sample code for a utime() function is below ...
Indeed I added the above test code to the test_00.rf test and found
similar performance (2.2 and 3.0 sec for the fast forth (mff) and the
version with the full run time checks (forth) respectively).
void utime(){
struct timeval tv ;
uint64_t rv = 0ULL ;
gettimeofday( &tv, NULL ) ;
push( ( tv.tv_sec * 1000000 ) + tv.tv_usec ) ;
}
git clone https://github.com/paraplegic/OneFileForth
cd OneFileForth
make test
The one file forth is offered under a quite liberal license, but without
much in the way of documentation (none). That will likely change over
time, as I get to it. The make file should just work under Linux and
FreeBSD, but may require some mods for Cygwin, MingW32 and others.
test_01.rf demonstrates the ability to load a C library, and to call C
code directly from Forth.
Cheers,
Rob.
>
> Just for reference, I converted the test code to C code
> via a conversion program I wrote, and all the high-level
> Forth words called by the routine too right down to my
> primitives. Then, I patched in my Forth primitives in
> C, C stack code, and other necessary C code to compile it.
>
> So, the test C code is effectively the same exact code
> which executes when the Forth is interpreted, but without
> the interpreter being present. The only difference is
> the test C code uses C's native control-flow instead of
> converting the control-flow words to C, i.e., BEGIN AGAIN
> IF ELSE THEN are not converted into equivalent code.
>
> I timed it. It's right on the boundary between 3 and
> 4 four seconds. So, the interpreter is twice as slow
> (7 seconds) as the code without the interpreter (3.5
> seconds).
>
> Of course, there is a speed improvement due to the use
> of C's control-flow instead of needing to interpret
> the Forth control-flow words. I'm not sure if the
> overhead is mostly due to the interpreter, or if it's
> the control-flow, or if it's an even balance between
> them, but I suspect the interpreter itself.
>
> I suspect the equivalent code coded natively in C would
> likely be substantially faster.
>
>
> Rod Pemberton
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-13 22:31 -0800 |
| Message-ID | <393696b7-da01-461b-ac14-5a52fee1dd20@googlegroups.com> |
| In reply to | #44241 |
>
> void utime(){
> struct timeval tv ;
> uint64_t rv = 0ULL ;
>
> gettimeofday( &tv, NULL ) ;
> push( ( tv.tv_sec * 1000000 ) + tv.tv_usec ) ;
> }
>
If you have a 32bit forth, you can use this:
#include <sys/time.h>
ucell_t MS;
ucell_t getms() {
struct timeval tv;
gettimeofday(&tv, NULL);
return tv.tv_sec * 1000 + tv.tv_usec / 1000;
}
void qinittime() {
MS = getms();
}
// ms ( -- u ) get the milliseconds counter
void qms() {
DPUSH(getms() - MS);
}
qinittime() must be called at system startup. After that you will have a 32bit
milliseconds counter at hand (ucell_t is uint32_t in my 32bit system).
Works very nice. The trick is the difference of two unsigned numbers which
works on overflow.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-28 15:52 -0700 |
| Message-ID | <871tcevc6m.fsf@jester.gateway.sonic.net> |
| In reply to | #42902 |
Chris Curl <ccurl609@gmail.com> writes:
> It is not very fast though ...
> : test begin ?dup if 1 - else exit then again ;
> 10000000 test \ about 6 seconds for 10 million iterations
Not bad if it's interpreting rather than generating machine code. With
: test begin ?dup if 1 - else exit then again ;
1e8 f>s test
bye
I get 0.904 cpu seconds with gforth and 0.448 cpu sec with gforth-fast,
under 64-bit Linux on i7-3770, a quite fast machine.
Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
be slightly faster. I'm not sure how much to believe the timings
though.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 16:57 +0000 |
| Message-ID | <2015Oct29.175717@mips.complang.tuwien.ac.at> |
| In reply to | #42935 |
Paul Rubin <no.email@nospam.invalid> writes:
>Chris Curl <ccurl609@gmail.com> writes:
>> It is not very fast though ...
>> : test begin ?dup if 1 - else exit then again ;
>> 10000000 test \ about 6 seconds for 10 million iterations
>
>Not bad if it's interpreting rather than generating machine code. With
>
> : test begin ?dup if 1 - else exit then again ;
> 1e8 f>s test
> bye
>
>I get 0.904 cpu seconds with gforth and 0.448 cpu sec with gforth-fast,
>under 64-bit Linux on i7-3770, a quite fast machine.
>
>Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
>be slightly faster.
What timings do you get, which Gforth version, compiled how?
> I'm not sure how much to believe the timings
>though.
Why do you doubt them?
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-29 12:36 -0700 |
| Message-ID | <87eggdtqkl.fsf@jester.gateway.sonic.net> |
| In reply to | #42971 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
>>be slightly faster.
> What timings do you get, which Gforth version, compiled how?
This is on a X5650 @ 2.67GHz, definitely a slower machine than the
i7-3770. Gforth 0.7.0 installed from Debian repo.
$ time gforth a.fs
real 0m0.740s
user 0m0.737s
sys 0m0.001s
$ time gforth-fast a.fs
real 0m0.679s
user 0m0.678s
sys 0m0.001s
>> I'm not sure how much to believe the timings though.
> Why do you doubt them?
The 32-bit timings are on a VPS shared with lots of other users, so I
think there might be some noisy neighbor interference (the i7-3770 is
not shared). But I've repeated the 32-bit measurements enough times
that I believe the effect now. The timings do vary a bit between runs.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-31 14:57 +0000 |
| Message-ID | <2015Oct31.155700@mips.complang.tuwien.ac.at> |
| In reply to | #42979 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
>>>be slightly faster.
>> What timings do you get, which Gforth version, compiled how?
>
>This is on a X5650 @ 2.67GHz, definitely a slower machine than the
>i7-3770. Gforth 0.7.0 installed from Debian repo.
You can forget about performance when running the Debian-built
versions. They tend to disable performance features on all platforms
and for all future versions when they have build problems on one
platform with one Gforth version (we tend to come across these
problems ourselves at some point and fix them, but by then the
workaround is enshrined in the Debian patch and it apparently is never
checked whether these workarounds are still needed).
> $ time gforth a.fs
> real 0m0.740s
> user 0m0.737s
> sys 0m0.001s
>
> $ time gforth-fast a.fs
> real 0m0.679s
> user 0m0.678s
> sys 0m0.001s
>
>>> I'm not sure how much to believe the timings though.
>> Why do you doubt them?
>
>The 32-bit timings are on a VPS shared with lots of other users, so I
>think there might be some noisy neighbor interference (the i7-3770 is
>not shared). But I've repeated the 32-bit measurements enough times
>that I believe the effect now. The timings do vary a bit between runs.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-10-31 20:25 +0100 |
| Message-ID | <n134eb$acv$1@dont-email.me> |
| In reply to | #43037 |
Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
>>>>be slightly faster.
>>> What timings do you get, which Gforth version, compiled how?
>>
>>This is on a X5650 @ 2.67GHz, definitely a slower machine than the
>>i7-3770. Gforth 0.7.0 installed from Debian repo.
>
> You can forget about performance when running the Debian-built
> versions. They tend to disable performance features on all platforms
> and for all future versions when they have build problems on one
> platform with one Gforth version (we tend to come across these
> problems ourselves at some point and fix them, but by then the
> workaround is enshrined in the Debian patch and it apparently is never
> checked whether these workarounds are still needed).
I also don't like the way the Debian maintainer not providing any feedback
when problems arise - we don't have that problem with other distributions,
0.7.3 was released after someone from RedHat complained about a new GCC
breaking Gforth again (oops, they did it again ;-), and then he offered even
the build farm to help us testing the fix. That's how it should work.
There's also the issue with the documentation, which is free according to
the Debian rules (GFDL, but no invariant section), but they don't distribute
it.
IMHO it's close to a copyright violation under German law ("Entstellung"
https://de.wikipedia.org/wiki/Entstellung_(Urheberrecht)). This is a
personal right, not something you give away with the GPL.
One particularly funny thing is that Gforth's makefile allows you to build a
debian package just out of the box. But we don't do it the way they want it
to be done, it seems...
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-03 20:39 -0800 |
| Message-ID | <87a8quxts4.fsf@nightsong.com> |
| In reply to | #42971 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Interestingly, on 32-bit machines, gforth (but not gforth-fast) seems to
>>be slightly faster.
> What timings do you get, which Gforth version, compiled how?
In case it's of interest, on Gforth 0.7.2 from Debian repo,
Marvell 1.3 ghz ARM7 (scaleway.com mini server):
# time gforth a.fs
real 0m8.144s
user 0m8.140s
sys 0m0.000s
# time gforth-fast a.fs
real 0m6.972s
user 0m6.950s
sys 0m0.020s
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2015-10-28 16:27 -0700 |
| Message-ID | <1087207c-3b84-40da-b567-0fc0ed843418@googlegroups.com> |
| In reply to | #42902 |
El miércoles, 28 de octubre de 2015, 13:18:09 (UTC-3), Chris Curl escribió: > It is not very fast though ... > > : test begin ?dup if 1 - else exit then again ; > > 10000000 test \ about 6 seconds for 10 million iterations with diferent machines the numbers say nothing. with my bytecode vm machine 100M iteration give me 1700 milisecond with the compiler 100 milisecond in a i3 laptop pc in win7. the code is diferent but do the same: :test | n -- ( 1? )( 1- ) drop ; #t1 #t2 :main msec 't1 ! 100000000 test msec 't2 ! show clrscr t2 t1 - "%d" print 'exit >esc< cminiflecha ; : main ; perhaps you can use ideas of my code, https://github.com/phreda4 r4vm is the C vm for :r4 reda4 is the system build on top of this vm. the compiler is made in the languaje itself. I generate .asm code and call to flatassembler to make the exe good luck
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-10-30 05:57 -0700 |
| Message-ID | <d06150b0-1609-434b-8ecf-d08af5d7ed4a@googlegroups.com> |
| In reply to | #42902 |
On Wednesday, October 28, 2015 at 12:18:09 PM UTC-4, 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 Some profiling may be in order. My own toy assembler Forth runs 100 million iterations in 0.63 to 0.65 seconds.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2015-11-02 13:15 +1100 |
| Message-ID | <n16h0b$pp8$1@speranza.aioe.org> |
| 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 Are you intending to use that in a program? If not, don't worry about it. What matters is the time your *applications* take to run and whether it's fast enough *for you*. There are plenty of [slower] languages which run fine on a fine on a fast cpu. Unless your implementation is appallingly written and you're running a slow cpu, any improvement you make isn't likely to be noticed. (Pointless benchmarks excepted.)
[toc] | [prev] | [next] | [standalone]
Page 8 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