Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #26523 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2013-10-14 16:18 -0400 |
| Last post | 2013-10-28 18:38 -0700 |
| Articles | 9 on this page of 69 — 16 participants |
Back to article view | Back to comp.lang.forth
Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-14 16:18 -0400
Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-14 10:34 -1000
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 15:41 -0500
Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-14 20:32 -0700
Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-15 17:14 -0400
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:22 +0000
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 15:42 -0500
Re: Floating Point : To Stack or Not To Stack Hans Bezemer <the.beez.speaks@gmail.com> - 2013-10-16 11:16 +0200
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:09 +0000
Re: Floating Point : To Stack or Not To Stack krishna.myneni@ccreweb.org - 2013-10-15 18:51 -0700
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-16 03:47 -0500
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 12:27 +0000
Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-25 14:20 -0400
Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-25 12:08 -0700
Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-26 02:34 -0400
Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-26 00:13 -0700
Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-25 21:49 -1000
Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-26 01:26 -0700
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 05:45 -0500
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-26 13:48 +0000
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 14:28 -0500
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-27 12:41 +0000
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-27 08:31 -0500
?DUP (was: Floating Point : To Stack or Not To Stack) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-28 15:19 +0000
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-28 13:54 -0500
Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-28 16:30 -0400
Re: ?DUP "Elizabeth D. Rather" <erather@forth.com> - 2013-10-28 11:11 -1000
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 11:51 +0000
Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 16:48 +0100
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 16:10 +0000
Re: ?DUP albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-29 16:24 +0000
Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 20:00 +0100
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 07:44 +0000
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-29 16:29 -0500
Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-29 18:58 -0400
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-30 03:15 -0500
Re: ?DUP albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-30 01:14 +0000
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 08:22 +0000
Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-30 08:03 -0400
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 12:24 +0000
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-30 12:44 -0500
Re: ?DUP "Alex McDonald" <blog@rivadpm.com> - 2013-10-30 22:43 +0000
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-31 12:09 +0000
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-31 12:23 -0500
Re: ?DUP (was: Floating Point : To Stack or Not To Stack) "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-28 16:30 -0400
Re: ?DUP "Elizabeth D. Rather" <erather@forth.com> - 2013-10-28 11:16 -1000
Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 01:58 +0100
Re: ?DUP Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2013-10-28 18:41 -0700
Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-29 04:37 -0500
Re: ?DUP m.a.m.hendrix@tue.nl - 2013-10-29 04:27 -0700
Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 12:51 +0000
Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-26 09:45 +0000
Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 11:30 +0000
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 08:05 -0500
Re: Floating Point : To Stack or Not To Stack mhx@iae.nl - 2013-10-26 06:09 -0700
Re: Floating Point : To Stack or Not To Stack "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-10-27 03:01 -0400
Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-26 22:23 -1000
Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 09:39 +0000
Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 09:44 +0000
Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-18 14:09 +1000
Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-17 21:21 -1000
Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-19 12:14 +1000
Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-18 17:17 -1000
Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-19 02:58 -0700
Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-27 22:33 +1100
Re: Floating Point : To Stack or Not To Stack mhx@iae.nl - 2013-10-27 06:21 -0700
Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-29 22:40 +1100
Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-27 08:23 -0500
Re: Floating Point : To Stack or Not To Stack Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2013-10-28 18:38 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-10-17 21:21 -1000 |
| Message-ID | <-OmdnYxW5ugYfP3PnZ2dnUVZ_oednZ2d@supernews.com> |
| In reply to | #26623 |
On 10/17/13 6:09 PM, Ed wrote: > rickman wrote: >> That is the question... >> >> I have read the floating point section of the DPANS document a couple of >> times and I am still unclear about the floating point stack. No, I am >> clear about the stack, I'm not clear on how to write code that does not >> *assume* the presence or absence of the floating point stack. >> >> Obviously if you keep all floating point calculations distinct from >> other stack operations it won't matter. But that is not so easy in most >> apps, no? > > The argument goes that a separate f.p stack is necessary and/or easier to use. > > I find the claim to be exaggerated if not false. > > To demonstrate to myself that a separate f.p stack is *not* required, I have > made it a point to code all my f.p apps to use the data stack. Not only is it > no harder, I find the resulting code easier to read as there is one less stack > to deal with. > > I do have versions of my forth which use a separate stack. That's to > accommodate *other peoples* separate stack code - not that there is > much forth f.p code available in any case. > > If one has an f.p chip such as an 80x87 and want maximum speed then one > might choose to implement a separate f.p stack. However this too has its > complications as f.p chip stacks are often limited. > > Just as some believe locals are necessary to Forth, so there will be those > who believe a separate f.p stack is necessary. I'm not one of them. It really depends both on the platform and the implementation. For platforms with hardware FP, there is usually a hardware FP stack, so you gain a huge performance advantage for using it. Even though the depth may be limited, our evaluation (some years ago) was that it was still a significant win. On microcontrollers and native platforms with limited memory, it's really best to avoid FP altogether, particularly if it's software FP. Other computational methods such as fixed-point fractions are faster and simpler. 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 | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2013-10-19 12:14 +1000 |
| Message-ID | <l3smg6$l0e$1@speranza.aioe.org> |
| In reply to | #26626 |
Elizabeth D. Rather wrote: > ... > On microcontrollers and native platforms with limited memory, it's > really best to avoid FP altogether, particularly if it's software FP. > Other computational methods such as fixed-point fractions are faster and > simpler. F/P has its advantages - dynamic range, ease of use etc. Software f/p can be quite compact as Brad and others have demonstated. I wouldn't be in a hurry to dismiss it. It's a tool like anything else.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-10-18 17:17 -1000 |
| Message-ID | <Wo-dnUbV6o5YZPzPnZ2dnUVZ_s-dnZ2d@supernews.com> |
| In reply to | #26642 |
On 10/18/13 4:14 PM, Ed wrote: > Elizabeth D. Rather wrote: >> ... >> On microcontrollers and native platforms with limited memory, it's >> really best to avoid FP altogether, particularly if it's software FP. >> Other computational methods such as fixed-point fractions are faster and >> simpler. > > F/P has its advantages - dynamic range, ease of use etc. Software f/p can > be quite compact as Brad and others have demonstated. I wouldn't be in > a hurry to dismiss it. It's a tool like anything else. Yes, it's a tool, and it certainly has its uses. I am all anti-FP, particularly when there is hardware support for it. My remarks above are specific to embedded systems. The dynamic range argument can be misleading. If you are taking data with, say, a 12-bit A/D, you will never have more resolution on that data, and a floating point calculation with 60-bit values will tempt you to forget that fact. Moreover, roundoff errors can eat into the accuracy you have. A reasonable suite of fixed-point fraction operators, such as the ones we provide with SwiftX, can be quite easy to use in these environments. 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 | 2013-10-19 02:58 -0700 |
| Message-ID | <7xhacd4m65.fsf@ruckus.brouhaha.com> |
| In reply to | #26643 |
"Elizabeth D. Rather" <erather@forth.com> writes: > If you are taking data with, say, a 12-bit A/D, you will never have > more resolution on that data, and a floating point calculation with > 60-bit values will tempt you to forget that fact. Moreover, roundoff > errors can eat into the accuracy you have. The idea of using high-precision intermediate results is to AVOID having roundoff error clobber what little info you start with. The x87 historically used 80 bits for all the internal calculations and was considered numerically superior to the stuff being used now. See http://cs.berkeley.edu/~wkahan for endless rants on this topic and related ones.
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2013-10-27 22:33 +1100 |
| Message-ID | <l4ito0$ldr$1@speranza.aioe.org> |
| In reply to | #26643 |
Elizabeth D. Rather wrote:
> On 10/18/13 4:14 PM, Ed wrote:
> > Elizabeth D. Rather wrote:
> >> ...
> >> On microcontrollers and native platforms with limited memory, it's
> >> really best to avoid FP altogether, particularly if it's software FP.
> >> Other computational methods such as fixed-point fractions are faster and
> >> simpler.
> >
> > F/P has its advantages - dynamic range, ease of use etc. Software f/p can
> > be quite compact as Brad and others have demonstated. I wouldn't be in
> > a hurry to dismiss it. It's a tool like anything else.
>
> Yes, it's a tool, and it certainly has its uses. I am all anti-FP,
> particularly when there is hardware support for it. My remarks above are
> specific to embedded systems. The dynamic range argument can be
> misleading. If you are taking data with, say, a 12-bit A/D, you will
> never have more resolution on that data, and a floating point
> calculation with 60-bit values will tempt you to forget that fact.
> Moreover, roundoff errors can eat into the accuracy you have.
>
> A reasonable suite of fixed-point fraction operators, such as the ones
> we provide with SwiftX, can be quite easy to use in these environments.
What if the application isn't a 12-bit A/D? What if it is an application
that involves calculations in MHz, pF and uH ... such as this one:
http://dxforth.webhop.org/track03.zip
Doing it in f/p is trivial. If someone can demonstrate how it may be
done "faster and simpler" using integers on a 16-bit Forth, please do.
Regarding the speed of hardware vs. software f/p, here are some
timings. Results are for DX-Forth 16-bit DTC, 200MHz cpu:
1. 8087 double-precision, separate stack in ram:
C:\FORTH\DX>f87ds - include fbench bye
3405 mS
2. 8087 double-precision, floats on data stack:
C:\FORTH\DX>f87d - include fbench bye
988 mS
3. Software single-precision(*), separate stack:
C:\FORTH\DX>forth-f - include fbench bye
5272 mS
4. Software single-precision(*), floats on data stack:
C:\FORTH\DX>forth-c - include fbench bye
3954 mS
(*) single-precision f/p written in 8086 assembler.
\ fbench.f
empty forth definitions decimal
1 fload doslib _timing1
: test
/timer
10 0 do
65535 0 do
pi fdup f+ fdup f* pi f/ fdrop
loop
loop
.timer ;
test
\ end
My conclusion:
- There is not a substantial speed difference between hardware
double-precision and fast software single-precision.
- floats on data stack tends to be faster than separate f/p stack
in ram (at least on benchmarks).
For many applications involving f/p, single-precision will often suffice.
I didn't test software f/p written in high-level Forth. My guess is that
these will be 3-10 times slower. Despite this, forthers have used them
for decades with few complaints AFAIK. Didn't polyForth employ such
a scheme?
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2013-10-27 06:21 -0700 |
| Message-ID | <a52f0a36-1c0a-46fd-bad7-3a23ee97c208@googlegroups.com> |
| In reply to | #26709 |
On Sunday, October 27, 2013 12:33:21 PM UTC+1, Ed wrote: > Elizabeth D. Rather wrote: > > On 10/18/13 4:14 PM, Ed wrote: > > > Elizabeth D. Rather wrote: > > >> ... [..] > Regarding the speed of hardware vs. software f/p, here are some > timings. Results are for DX-Forth 16-bit DTC, 200MHz cpu: > > 1. 8087 double-precision, separate stack in ram: > > C:\FORTH\DX>f87ds - include fbench bye > 3405 mS > > 2. 8087 double-precision, floats on data stack: > > C:\FORTH\DX>f87d - include fbench bye > 988 mS > > 3. Software single-precision(*), separate stack: > > C:\FORTH\DX>forth-f - include fbench bye > 5272 mS > > 4. Software single-precision(*), floats on data stack: > > C:\FORTH\DX>forth-c - include fbench bye > 3954 mS [..] > > My conclusion: > > - There is not a substantial speed difference between hardware > double-precision and fast software single-precision. > > - floats on data stack tends to be faster than separate f/p stack > in ram (at least on benchmarks). > > For many applications involving f/p, single-precision will often suffice. > > I didn't test software f/p written in high-level Forth. My guess is that > these will be 3-10 times slower. Despite this, forthers have used them > for decades with few complaints AFAIK. Didn't polyForth employ such > a scheme? On a 2.77 GHz CPU I'd expect 14 times faster results: FORTH> : test1 <3>[FORTH>] CR ." FP test1: " ?ms <3>[FORTH>] #1000 0 DO [3]<3>[FORTH>] #10 0 do [6]<3>[FORTH>] #65535 0 do [9]<3>[FORTH>] pi fdup f+ fdup f* pi f/ fdrop [9]<3>[FORTH>] loop [6]<3>[FORTH>] loop [3]<3>[FORTH>] LOOP <3>[FORTH>] ?ms swap - #1000 /mod 0 .R '.' EMIT . ." ms elapsed" ; ok FORTH> ok FORTH> 3141593 constant PI Redefining PI ok FORTH> ok FORTH> : test2 <3>[FORTH>] CR ." INT test2: " ?ms <3>[FORTH>] #1000 0 DO [3]<3>[FORTH>] #10 0 do [6]<3>[FORTH>] #65535 0 do [9]<3>[FORTH>] PI dup + dup #1000000 */ #1000000 PI */ drop [9]<3>[FORTH>] loop [6]<3>[FORTH>] loop [3]<3>[FORTH>] LOOP <3>[FORTH>] ?ms swap - #1000 /mod 0 .R '.' EMIT . ." ms elapsed" ; ok FORTH> ok FORTH> ok FORTH> test1 test2 FP test1: 5.249 ms elapsed INT test2: 16.945 ms elapsed ok More like 1000 times faster (and FP is faster than the integer approximation). What's happening here :-? -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2013-10-29 22:40 +1100 |
| Message-ID | <l4o6tq$hmk$1@speranza.aioe.org> |
| In reply to | #26713 |
mhx@iae.nl wrote: > ... > More like 1000 times faster > ... 1000 times faster than what? The timings I posted compared relative speed between double-precision on a FPU and single-precision software f/p; drawing the conclusion that software f/p will be more than adequate for many tasks irrespective of whether hardware f/p is available.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-10-27 08:23 -0500 |
| Message-ID | <ZcGdnYtIZfEgjvDPnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #26709 |
Ed <invalid@invalid.com> wrote: > > 1. 8087 double-precision, separate stack in ram: > > C:\FORTH\DX>f87ds - include fbench bye > 3405 mS > > 2. 8087 double-precision, floats on data stack: > > C:\FORTH\DX>f87d - include fbench bye > 988 mS There is something terribly wrong with the way that data is being handled on the floatng-point stack. Somehow it takes three times as long to handle the separate stack as it does to do the actual calculation. What can it be? Floating-point stack pointer in RAM? So what's up? Looking ... Separate stack: code F+ ( r1 r2 -- r3 ) addr fsp ) bp xchg qword 0 [bp] fld 1 floats # bp add qword 0 [bp] fadd qword 0 [bp] fstp wait addr fsp ) bp xchg next Data stack: code F+ ( r1 r2 -- r3 ) addr fsp ) bp xchg qword 0 [bp] fld 1 floats # bp add qword 0 [bp] fadd qword 0 [bp] fstp wait addr fsp ) bp xchg next end-code Aha! I think it's the XCHG BP with the floating-point stack pointer in RAM that's killing you. XCHG does a full locked read/write cycle, with or without a LOCK prefix. It's very slow. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2013-10-28 18:38 -0700 |
| Message-ID | <bcd7bfcd-ba1e-4a16-b310-dd4da7e475ee@googlegroups.com> |
| In reply to | #26523 |
Am Montag, 14. Oktober 2013 14:18:30 UTC-6 schrieb rickman: > That is the question... > > > > I have read the floating point section of the DPANS document a couple of > > times and I am still unclear about the floating point stack. No, I am > > clear about the stack, I'm not clear on how to write code that does not > > *assume* the presence or absence of the floating point stack. > > > > Obviously if you keep all floating point calculations distinct from > > other stack operations it won't matter. But that is not so easy in most > > apps, no? > > > > How do people use floating point calculations in Forth? Do they write > > with an assumption about the presence of a floating point stack? Or is > > there a way to code that does not make any assumptions about this? > > > > -- > > > > Rick
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web