Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #43724 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-11-24 22:31 -0800 |
| Last post | 2015-12-03 03:40 +0000 |
| Articles | 20 on this page of 61 — 19 participants |
Back to article view | Back to comp.lang.forth
Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-24 22:31 -0800
Re: Question about checking the stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 07:46 +0100
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-24 23:09 -0800
Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-25 09:16 +0200
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-24 23:19 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-24 22:05 -1000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 13:17 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 13:58 -1000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 18:00 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 17:44 -1000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:05 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 21:38 -1000
Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-26 09:49 +0200
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 22:42 -1000
Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 14:51 +0000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-30 13:00 -0800
Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-30 21:54 -0800
Re: Question about checking the stack Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 04:24 -0800
Re: Question about checking the stack Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-01 05:07 -0800
Re: Question about checking the stack Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 06:02 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:30 -1000
Re: Question about checking the stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-01 14:47 +0000
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-01 11:56 -0800
Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-12-03 05:48 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-03 09:24 -1000
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-03 21:10 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-03 20:52 -1000
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-04 06:08 -0800
Re: Question about checking the stack Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 20:32 +0000
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:32 -1000
Re: Question about checking the stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-12-01 08:18 +0100
Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-27 06:25 -0800
Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-28 17:55 +0200
Re: Question about checking the stack mhx@iae.nl - 2015-11-28 08:24 -0800
Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-28 20:54 +0200
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-28 11:32 -1000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-28 19:17 -0800
Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-29 07:30 +0200
Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-29 09:41 -0800
Re: Question about checking the stack minforth@arcor.de - 2015-11-30 01:48 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 08:03 -1000
Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-28 19:09 -0800
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-26 00:03 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 22:49 -1000
Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-26 10:59 -0800
Re: Question about checking the stack franck.bensusan@gmail.com - 2015-11-25 21:03 -0800
Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-27 06:14 -0800
Re: Question about checking the stack "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-25 04:54 -0500
Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-11-25 03:09 -0800
Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 12:53 +0000
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 09:02 -0800
Re: Question about checking the stack Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:53 +0100
Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 12:01 -0800
Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 17:26 +0000
Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-11-25 13:51 -0800
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-28 09:29 -0800
Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-28 12:03 -0800
Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-12-01 06:15 -0800
Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-01 14:05 -0800
Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:35 -1000
Re: Question about checking the stack dunno <dunno@dunno.dunno> - 2015-12-03 03:40 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-01 19:30 -1000 |
| Message-ID | <hOGdnW6da_WXH8PLnZ2dnUU7-XednZ2d@supernews.com> |
| In reply to | #44009 |
On 12/1/15 3:07 AM, Raimond Dragomir wrote: > marți, 1 decembrie 2015, 14:24:38 UTC+2, Julian Fondren a scris: >> On Monday, November 30, 2015 at 11:54:58 PM UTC-6, hughag...@gmail.com wrote: >>> This whole thread is getting dumb. Obviously, error checking is >>> good. No programmer would argue against it. Indeed not. We only disagree about when and who does the checking :-) >> If a long-running process has a slightly unbalanced stack, then >> without stack checking it will eventually crash. With stack checking >> it'll crash more reliably. My webserver had a couple of bugs that >> left an extra item on the stack, and this caused a crash after 90k >> requests or so. If your process is *not* long-running, then it may >> end satisfactorily without ever crashing, with or without stack >> checking, and you would only notice that something's wrong if you >> checked the stack at the end. The critical element is unit testing during development. There are many ways to do this, ranging from checking each word in a new section of code being tried for the first time (really, you should individually test any word over a couple of lines long) to putting in temporary diagnostics in a few critical points. In your example, could you have checked after every request? Once around a major control loop? Since you understand the overall structure of your program, you should be able to identify the points at which you always expect a certain state (not just stack size, but also maybe the state of the database or values in certain variables, etc). The author of a program should know how most efficiently to instrument it. >> So this 'error checking' is almost worthless. If it were at all >> expensive to implement, would no programmer argue against it? Rather >> than ask for a feature that slightly changes how my buggy program >> eventually misbehaves, I'd rather have a debugging mode that helped >> me expensively remove the bug, and then some tests to be sure that I >> had no need to worry about the stack on deployment. >> >> That is, I'd rather have a good way to check the stack everywhere >> along the stack, to check a word's usage of the stack, rather than >> only check one extreme end or the other. In general, every significant component of your program should be tested before being combined with the rest of it. For example, the contents of a loop must not change the stack. That is not hard to test. Cheers, Elizabeth >> -- Julian > > What do you mean? Checking the stack programatically in the application? > For example, save the depth before a request, get the depth after it and > make the difference. If it not as expected, bingo! > It is interesting, but may be or may be not practical, depending on the > application. > -- ================================================== 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-01 14:47 +0000 |
| Message-ID | <565db2f3$0$23771$e4fe514c@news.xs4all.nl> |
| In reply to | #44006 |
Julian Fondren <julian.fondren@gmail.com> writes: <SNIP> >That is, I'd rather have a good way to check the stack everywhere >along the stack, to check a word's usage of the stack, rather than >only check one extreme end or the other. Lately I grew fond of regression tests. The idea is that after each word a test is added. If you introduced an error include doesn't get past the test. It serves also as an example of usage. If you check both path's through a word, successful loading means there are no stack errors. I'm from the refactor-not-rewrite school and it fits that school better that "retest during rewrite" >-- Julian Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-01 11:56 -0800 |
| Message-ID | <0ffc1779-04e8-4407-8b97-f540a5229ba2@googlegroups.com> |
| In reply to | #44015 |
On Tuesday, December 1, 2015 at 9:47:56 AM UTC-5, Albert van der Horst wrote: > Lately I grew fond of regression tests. The idea is that after each > word a test is added. If you introduced an error include doesn't > get past the test. It serves also as an example of usage. > If you check both path's through a word, successful loading means > there are no stack errors. > I'm from the refactor-not-rewrite school and it fits that school > better that "retest during rewrite" > > Groetjes Albert I have started getting into test driven development. I write the code that tests the function (or word) first and reports if it did what it should have done. Then I write the function to make it do what the test was looking for. Writing all the tests for all the different scenarios can be very time consuming. But in the long run, it is a good thing because you know immediately if that change you just broke something somewhere. I have not gotten far enough in my little home-grown Forth system to be able to put in such tests yet.
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-12-03 05:48 -0800 |
| Message-ID | <bf9fb53e-3389-4136-90bf-d20a9b625db6@googlegroups.com> |
| In reply to | #44022 |
On Tuesday, December 1, 2015 at 2:56:26 PM UTC-5, Chris Curl wrote: > I have started getting into test driven development. I write the > code that tests the function (or word) first and reports if it > did what it should have done. Then I write the function to make it > do what the test was looking for. Conversely, if your code fails, you're missing a test.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-03 09:24 -1000 |
| Message-ID | <H-OdncBHSN1rC_3LnZ2dnUU7-RGdnZ2d@supernews.com> |
| In reply to | #44022 |
On 12/1/15 9:56 AM, Chris Curl wrote: > On Tuesday, December 1, 2015 at 9:47:56 AM UTC-5, Albert van der Horst wrote: >> Lately I grew fond of regression tests. The idea is that after each >> word a test is added. If you introduced an error include doesn't >> get past the test. It serves also as an example of usage. >> If you check both path's through a word, successful loading means >> there are no stack errors. >> I'm from the refactor-not-rewrite school and it fits that school >> better that "retest during rewrite" >> >> Groetjes Albert > I have started getting into test driven development. I write the > code that tests the function (or word) first and reports if it > did what it should have done. Then I write the function to make it > do what the test was looking for. > > Writing all the tests for all the different scenarios can be very > time consuming. But in the long run, it is a good thing because you > know immediately if that change you just broke something somewhere. > > I have not gotten far enough in my little home-grown Forth system > to be able to put in such tests yet. There are some simple procedural things you can do. When you load a file, always type . or .S to see if anything was left on the stack. There should be nothing. If there is some big number, it's probably an address, which means there's an incomplete structure somewhere. Assuming your programs are file-based, organize your source so that each file contains a particular related set of words, and then have a Make or Load file that loads them in a clearly-documented way. For example (from SwiftForth): INCLUDE config \ Kernel configuration INCLUDE ../nucleus \ SwiftForth nucleus INCLUDE ../data \ User variable and system data INCLUDE ../core \ Forth core wordset INCLUDE ../double \ Double numbers INCLUDE except \ Catch and throw INCLUDE ../patterns As your program grows, you may have separate load files for major sections. In our products, we rigorously segregate files containing features that are platform-dependent and those that are fully portable. In our SwiftX cross-compiler, for example, the great majority of files are completely portable over the dozen or so targets we support. In early stages of development, you can put a .S after each one. As things become stable, remove the .S, or maybe leave one after any section of code that's still being tested. Always follow a practice of bottom-up testing, trying individual definitions with reasonable stack arguments (as well as variables and other environmental details) before incorporating them in higher-level definitions. If a definition is "misbehaving" you can type your way through it (simulating loops and conditionals as necessary). Forth, Inc. systems always show you the current state of the stack, and SwiftForth has features that let you monitor individual variables or regions of memory. 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 | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-03 21:10 -0800 |
| Message-ID | <420bb284-7090-49e4-9170-d8b29bc97953@googlegroups.com> |
| In reply to | #44055 |
Elizabeth, I have been programming for over 30 years now. I am pretty sure I know how to write, organize, and debug my code, thanks.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-03 20:52 -1000 |
| Message-ID | <ndednRyxlfWjpfzLnZ2dnUU7-IGdnZ2d@supernews.com> |
| In reply to | #44067 |
On 12/3/15 7:10 PM, Chris Curl wrote: > Elizabeth, I have been programming for over 30 years now. > I am pretty sure I know how to write, organize, and debug > my code, thanks. > I apologize if I offended you. You'd be surprised how many people come here that don't have that understanding! 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 | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-04 06:08 -0800 |
| Message-ID | <63e7b98b-a7d1-47e6-bbbe-4c0d8e6000c2@googlegroups.com> |
| In reply to | #44069 |
On Friday, December 4, 2015 at 1:52:47 AM UTC-5, Elizabeth D. Rather wrote: > I apologize if I offended you. You'd be surprised how many people come > here that don't have that understanding! > > Cheers, > Elizabeth > No problem, thanks
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-12-01 20:32 +0000 |
| Message-ID | <n3kvvg$rqq$1@dont-email.me> |
| In reply to | #44015 |
On 01/12/2015 14:47, Albert van der Horst wrote: > Julian Fondren <julian.fondren@gmail.com> writes: > > <SNIP> > >> That is, I'd rather have a good way to check the stack everywhere >> along the stack, to check a word's usage of the stack, rather than >> only check one extreme end or the other. > > Lately I grew fond of regression tests. The idea is that after each > word a test is added. If you introduced an error include doesn't > get past the test. It serves also as an example of usage. > If you check both path's through a word, successful loading means > there are no stack errors. > I'm from the refactor-not-rewrite school and it fits that school > better that "retest during rewrite" > I agree with Albert. I use the Hayes tester, or an extension to it by David Williams and Josh Grams, when developing a program. These testers check stack results both values and depth of the stack. Once set up in an IDE it takes no more effort to write some code, write whatever simple tests are needed, save the files. A double mouse click to launch the Forth and include the test files, look at the result, then curse, correct and repeat or move on to the next bit of code. This takes little more typing than testing manually at the Forth console. And at the end of it you have a regression test for future use. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-01 19:32 -1000 |
| Message-ID | <hOGdnWmda_XKH8PLnZ2dnUU7-XednZ2d@supernews.com> |
| In reply to | #44015 |
On 12/1/15 4:47 AM, Albert van der Horst wrote: > Julian Fondren <julian.fondren@gmail.com> writes: > > <SNIP> > >> That is, I'd rather have a good way to check the stack everywhere >> along the stack, to check a word's usage of the stack, rather than >> only check one extreme end or the other. > > Lately I grew fond of regression tests. The idea is that after each > word a test is added. If you introduced an error include doesn't > get past the test. It serves also as an example of usage. > If you check both path's through a word, successful loading means > there are no stack errors. > I'm from the refactor-not-rewrite school and it fits that school > better that "retest during rewrite" Yes, that's very good practice. 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-12-01 08:18 +0100 |
| Message-ID | <86poyqocw3.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43981 |
Paul Rubin writes: > RMS used to say that when he automated some task with software and > then lost the ability to do it manually, that told him that the task > must have been a significant cognitive load, so automating it improved > his productivity by freeing up that much of his mental capacity for > other things. He's told this story multiple times regarding the > automatic parenthesis balancing in Emacs. He apparently lost the > ability to count parentheses while coding Lisp, once he programmed > Emacs to do it. I wonder if it would be like if there were similar editor support for Forth? E.g. there might be a continuous display of the stack picture for the current definition, and/or the word under the cursor. I think such a feature would actually have made me a worse Forth programmer.
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-11-27 06:25 -0800 |
| Message-ID | <39c6cda5-fd60-4d19-85a3-c732e102a02b@googlegroups.com> |
| In reply to | #43811 |
On Thursday, November 26, 2015 at 2:49:07 AM UTC-5, Ron Aaron wrote: > > My experience is that even the very best make mistakes. And what's > worse, the better one is the more subtle the mistake... The guy who knows our system the best is a literal genius who's been a programmer for forty years and has an acute grasp of the nuances of small changes to our huge product. Even so, he's known for forgetting to change the sense of compares after copying and pasting code. Why? Because he is unfortunately a human being saddled with a human brain, and is therefore prone to make the kind of mistakes that we make. Allow, but don't force, the computer to do the kind of checking that it's good at. In this situation, maybe do stack checking if a debug flag is on, and not if not. Never assume that users of your product, or your programmers, can't and won't make rookie errors. If you do, you will be committing a rookie error yourself. You will suffer Consequences, and I will have no sympathy.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-11-28 17:55 +0200 |
| Message-ID | <n3cilj$k3$1@dont-email.me> |
| In reply to | #43863 |
On 27/11/2015 16:25, Alfred Singlestone wrote: > The guy who knows our system the best is a literal genius who's been a programmer for forty years and has an acute grasp of the nuances of small changes to our huge product. Even so, he's known for forgetting to change the sense of compares after copying and pasting code. Why? Because he is unfortunately a human being saddled with a human brain, and is therefore prone to make the kind of mistakes that we make. Exactly my point. > Allow, but don't force, the computer to do the kind of checking that it's good at. In this situation, maybe do stack checking if a debug flag is on, and not if not. Never assume that users of your product, or your programmers, can't and won't make rookie errors. If you do, you will be committing a rookie error yourself. You will suffer Consequences, and I will have no sympathy. In my system (8th), I keep the stack check on always. First of all, the user does have the option to allow "foreign code" to be interpreted. It would be bad if such code could subvert the system. Second, as I mentioned in an earlier reply, the checking code only takes a few nanoseconds on modern hardware, perhaps a few microseconds on mobile devices. Yes, that contributes to overall latency, but I feel it's a small price to pay for a more stable system. The discussion around "efficiency" is misplaced in end-user-oriented software. The only important metric in terms of speed is, "is it fast enough?", in which case the miniscule time taken to check the stack is immaterial. If you're software is doing 10^9 loops before giving an answer, then yes, you'll notice the difference. Hopefully your SW isn't doing that...
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-11-28 08:24 -0800 |
| Message-ID | <e20284d2-0051-451b-8bdd-560ec0501e3a@googlegroups.com> |
| In reply to | #43900 |
On Saturday, November 28, 2015 at 4:55:48 PM UTC+1, Ron Aaron wrote: > On 27/11/2015 16:25, Alfred Singlestone wrote: > [..] > the checking code only takes [..] a few microseconds on mobile devices. [..] > The discussion around "efficiency" is misplaced in end-user-oriented > software. The only important metric in terms of speed is, "is it fast > enough?", in which case the miniscule time taken to check the stack is > immaterial. If you're software is doing 10^9 loops before giving an > answer, then yes, you'll notice the difference. Hopefully your SW isn't > doing that... Good to know that on 8th the below takes n * 1e9 * 1e-6 or a few thousand seconds. It might well be the first (and last) program a typical user may try :-) : test timer-reset 1 1000 dup dup * * 0 ?do dup drop loop . .elapsed ; ok test 1 1.636 seconds elapsed. ok -marcel
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-11-28 20:54 +0200 |
| Message-ID | <n3ct5a$aev$1@dont-email.me> |
| In reply to | #43902 |
On 28/11/2015 18:24, mhx@iae.nl wrote: > Good to know that on 8th the below takes n * 1e9 * 1e-6 > or a few thousand seconds. It might well be the first > (and last) program a typical user may try :-) > > : test timer-reset 1 1000 dup dup * * 0 ?do dup drop loop . .elapsed ; ok > test 1 1.636 seconds elapsed. ok > Actually it takes 5.9 seconds on the hardware I checked, but really why do you want to do 10^9 loops? :o
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-28 11:32 -1000 |
| Message-ID | <e9ednXpMQvzhgMfLnZ2dnUU7-Y_46u6z@supernews.com> |
| In reply to | #43900 |
On 11/28/15 5:55 AM, Ron Aaron wrote: > Second, as I mentioned in an earlier reply, the checking code only takes > a few nanoseconds on modern hardware, perhaps a few microseconds on > mobile devices. Yes, that contributes to overall latency, but I feel > it's a small price to pay for a more stable system. Yes, but those "few microseconds" become attached to virtually everything you do, at which point they add up to a measurable overhead. 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 | 2015-11-28 19:17 -0800 |
| Message-ID | <87poyteboz.fsf@jester.gateway.pace.com> |
| In reply to | #43916 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Yes, but those "few microseconds" become attached to virtually > everything you do, at which point they add up to a measurable > overhead. It seems to me that a serious compiler can track the stack picture and eliminate the checks most of the time. A naive interpreter might take a noticable slowdown from the checks, but if you're using such an interpreter, you're not too worried about speed anyway.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-11-29 07:30 +0200 |
| Message-ID | <n3e2d0$1av$1@dont-email.me> |
| In reply to | #43916 |
On 28/11/2015 23:32, Elizabeth D. Rather wrote: > Yes, but those "few microseconds" become attached to virtually > everything you do, at which point they add up to a measurable overhead. That depends to a great extent on what exactly you're doing. FWIW, none of my users has so far complained that 8th is slow, even though it is provably slower than C or most Forths (including my own Reva Forth). In a GUI application, a delay of less than a few microseconds is not noticeable in terms of UX. It could become noticeable if you were to engage in some kind of "heavy lifting" due to some GUI event, but that's not the right way to do an interactive kind of application in any case. As it happens, the real slowdown in 8th (at least) comes from checking the types of items being passed to the built-in words, and not from checking the stack for over/underflow... and removing type-checking would absolutely be contraindicated.
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-11-29 09:41 -0800 |
| Message-ID | <0b35b7bd-911b-4c0c-aeba-57fb34da5740@googlegroups.com> |
| In reply to | #43916 |
On Saturday, November 28, 2015 at 4:32:46 PM UTC-5, Elizabeth D. Rather wrote: > On 11/28/15 5:55 AM, Ron Aaron wrote: > > Second, as I mentioned in an earlier reply, the checking code only takes > > a few nanoseconds on modern hardware, perhaps a few microseconds on > > mobile devices. Yes, that contributes to overall latency, but I feel > > it's a small price to pay for a more stable system. > > Yes, but those "few microseconds" become attached to virtually > everything you do, at which point they add up to a measurable overhead. This is where user testing comes in handy. If you're in business to make money, you find out the minimum that will make your users truly happy, then you do that. There's little point in optimizing code when the users don't notice either way. That said, it's of course also true that readability and maintainability is also very important. It's hard to go wrong "optimizing" them.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2015-11-30 01:48 -0800 |
| Message-ID | <0abfa515-a46f-4ddf-8944-3f78334f2eb1@googlegroups.com> |
| In reply to | #43937 |
> This is where user testing comes in handy. If you're in business to make money, you find out the minimum that will make your users truly happy, then you do that. There's little point in optimizing code when the users don't notice either way. > > That said, it's of course also true that readability and maintainability is also very important. It's hard to go wrong "optimizing" them. In most cases I leaft full runtime checking ON. The overhead was mostly negligible. Why? You lose customer confidence and money with every bug that appears in the production system. And the longer it takes to isolate and repair it, the worse it gets. This outweighs practically any performance maximization, of which so many Forthers seem to be fond.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web