Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Question about checking the stack Date: Wed, 25 Nov 2015 23:05:45 -0800 Organization: A noiseless patient Spider Lines: 67 Message-ID: <87y4dldyuu.fsf@nightsong.com> References: <87io4qh7fm.fsf@nightsong.com> <87k2p5g4n0.fsf@nightsong.com> <8737vtfrk9.fsf@nightsong.com> <47ydnYNjvc2dHcvLnZ2dnUU7-Yv46u6z@supernews.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="d09d25b6b873a1567c8bb21cd9fda25b"; logging-data="28388"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Rb/CgJ6kpCvC11DBn4Na3" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:gZG4JKAr01Ich8fJjr04iGBhkxo= sha1:nNL1TVBVdLUK7nsJkUdEXVUVZRg= Xref: csiph.com comp.lang.forth:43803 "Elizabeth D. Rather" writes: > I certainly don't plan to be developing on a system that is different > from the one the program is running on. So I'm thinking about the > finished program's timing. Interesting. I always prefer to develop on a workstation if possible. Some machine dependent things of course have to be deveoped on the target, but even with those, workstation-side emulators can help. > I don't know what kinds of programs you write, but a lot of the > applications we work on have performance targets Even for such programs though, there are usually a few tight loops where the performance critical stuff is. The initializations, terminal i/o, etc. can be quite unoptimized and still be fine. > Because I'll find it in the length of time it takes you to respond to > that error message. Eh? First you have to see there was an error, then you have to find there was an underflow at the dup, then you have to figure out what caused the underflow. With an error check at the dup, I get to skip the first two steps and then we're in exactly the same place. It's even worse if you use a word like ?dup where you think there might be a legitimate zero on the stack, but the stack is actually empty. The ?dup puts a zero there and the program keeps going. Even with that very fine grained testing it still sounds likely to create confusion. > Well, I like everything to run fast all the time. We've heard too many > times, "Oh, you can't use Forth for that, it's too slow!" I just did some timings on a Scaleway arm7, simple loops counting to 1e8. Gforth 0.7.2 (non-fast, from Debian 8 repo) took 4.4 seconds Gforth-fast took 3.4 seconds Mecrisp 2.1.6 took less than 1 second Python, the language I use all day, took 1 minute 16 seconds. So Forth is beating Python by 15x to maybe 100x. Despite this, the slow speed of Python is usually not a problem for my apps. They spend most of their time waiting for network i/o, or call libraries (generally written in C) for their computation intensive parts. If the program is still too slow (that happens sometimes) I can write the slow parts in C++ or some other language while keeping the non-speed-critical control and coordination parts in Python, which is much more convenient to code in. It's a good trade. I'm sure that any reasonable Forth even with those stack checks will still be much faster than Python. I also know the relative market size of the two languages, so Python must be doing something right, or else people usually don't care that much about the interpreter speed. > It's nice to be able to show people it's performing as well as > whatever they're familiar with. Sure, so compile in optimized mode that turns off the checks. > I also hate simulation, because simulators are never perfect, and it's > an extra step to have to figure out what's different when you get on > the real hardware. I generally find simulators to be worth the bother, because you then don't have to muck with the actual hardware--which can be hard to get your hands on, requires messy setup, needs manual operations so it's hard to automate testing, etc. But I guess it depends on what you're doing.