Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!137.226.231.214.MISMATCH!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)
Date: Thu, 21 Mar 2013 00:42:31 -0700
Organization: Nightsong/Fort GNOX
Lines: 15
Message-ID: <7xboad19nc.fsf@ruckus.brouhaha.com>
References: <b70a9248-3dd3-4f6a-ac04-52300b7a7ac0@googlegroups.com> <920a596a-9d56-43cc-ac6d-6f1758058710@googlegroups.com> <98eb98de-b24c-47bd-9480-37f6bde941d8@googlegroups.com> <ki967o$kc7$1@speranza.aioe.org> <5148759d.489569357@news.demon.co.uk> <b1ec4e9c-da7d-403d-b2f7-692e0d71efc1@googlegroups.com> <5148cdc6.512138193@news.demon.co.uk> <af2804a7-cbc0-4f39-b751-84da1b379026@googlegroups.com> <5149ff2c.590320497@news.demon.co.uk> <c8a105c1-56c5-42cc-9ac0-554484afb98b@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx05.eternal-september.org; posting-host="d94d289a4df6ae47ea4d4f8b2ae808e7"; logging-data="14643"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX183cz6rauUtwFcjwDUeD5QS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:ARTUDbFtiANm+tzdZb/Xk7a3tcg= sha1:PAHIsHCr66VYs5iV168ClpNxr+A=
Xref: csiph.com comp.lang.forth:20946

AKE <assadebrahim2000@gmail.com> writes:
>      x30 speedup vs. a Forth program targeted to a 68HC12 processor
> While x30 speedup is not bad, I guess I was expecting greater gains
> vs. any software algorithm compiled to run on a generic register based
> processor.

As I understand it, Forth processors probably take more instructions (or
at least about the same number) as reasonably good compiled Forth code
running on a register processor.  The main reason the Forth processor is
so much faster is that the simplified hardware allows running at much
higher clock frequencies for a given amount of silicon and a given
process technology.  That 30x speedup is probably compared to an
interpreter on an older cpu, so maybe there's a combination of newer
process tech, avoiding interpretation overhead, and the clock speedup
mentioned above.