As we all know, all VMs regardless of the language can impose huge run-
time performance penalties, compared to native coding in native compiled
languages.

An STC-based Forth with optimal hand-coded assembler primitives can evade
this cost to a large degree, so I won't be talking about that here. I'm
thinking more of DTC, ITC and TTC-based forths.

What I am interested in is: when is it better to sweat over the coding of
forth words, squeezing every last ounce of speed out of them at the very
likely cost of readability/maintainability, as opposed to just taking the
time critical stuff and coding it as C and/or assembler primitives?

Cheers
Dave

On Aug 3, 6:45 pm, DavidM nowhere.com> wrote:

I'd say ... you shouldn't sweat over Forth code at all. Do what's
necessary and no more. You want to finish your application (if you're
writing one), not torture yourself.

DavidM nowhere.com> wrote:

If your code is already fast enough running on your particular Forth on
your particular hardware, then you don't need to do either one, you're
done.

So, you have your Forth code that works but it isn't fast enough. Step
back and notice whether you see some other method that would run
faster. You can try out new methods faster in Forth. See which one looks
like it's actually doing the least work. If you find a better algorithm
and it's fast enough, then you're done.

DavidM wrote:

Elizabeth D Rather wrote:

...

On Aug 3, 6:45 pm, DavidM nowhere.com> wrote:

The key word is "can." The slowest VM can still outperform the
fastest native code if the algorithms used are superior. What matters
is the performance of the system as a whole, not the VM. That's a
trap that you see endlessly here in comp.lang.forth-- a preoccupation
with speed. But not speed of some concrete real-world application,
but the speed of some small primitive in the system. The theory, I
guess, is that by focusing on speeding up all the primitives, the
performance of the overall system is improved. To which I say,
nonsense-- if I choose a superior algorithm, that is going to give me
a far better pay-off in terms of performance than if I manage to
reduce a routine I hardly ever call by a few cycles.

Jerry Avins wrote:

According to DavidM nowhere.com>:

It can but it is not necessarily doomed to. A VM is a "virtual machine":
it emulates a hardware system which does not actually exist, but for
which the code was written. The VM thus converts the code for the
virtual hardware into something that the real processor can process,
through a mixture of static (translation before execution) and dynamic
(during execution) operations. For instance, if using an ITC-based
Forth, then the static part is the conversion of word names (which are
strings) into addresses (pointers to CFA) cunningly layed out for proper
execution. The dynamic part entails the double-indirections and jumps
(the famous NEXT code snippet).

Traditional Forth implementations rely on threaded code (they are all
some kind of *TC) in which the translation transforms the virtual
machine code into a sequence of addresses (or subroutine calls or...

John Passaniti wrote:

You don't see the forrest in the trees. When we argue here, we are quite
often concerned about speed. You then step in and say "there's no
requirement to be performant here". That's sloppy thinking - there's no
requirement for performance here and there, so you implement CPU hogs here
and there and then wonder why your application is dog slow.

You forget that a fast, low-memory solution is often straight-forward and
clean design, too. It's easy to maintain, as well. That's the goal. If your
performance improvements are a burden for a small, clean implementation,
forget it.

Bernd Paysan wrote: