[siraben]

This nicely provides empircal evidence on the slowdown of using Forth, which seems to be around 10 to 20 times slower than optimized assembly. I was initially surprised by how poorly Forth performed on all counts of speed, memory usage and development time. For something as complex as a game the lack of a type system and postfix nature make Forth quite unsuitable.

When I use Forth, it's often for high-level applications[0] with the performance critical words written in assembly. So this keeps the complexity relatively low as opposed to writing the whole thing in Forth.

[0] https://github.com/siraben/zkeme80/blob/master/src/bootstrap...

[asguy]

If you program Forth like it's C, and then use a non-optimizing compiler, you're going to have a bad time (e.g. 10/20x slowdowns).

I've written Forth compilers that generated output that was ~25% slower than optimized assembly, without putting that much work into it. There are companies that will sell you a much better compiler [0], at prices even approachable to hobbyists.

[0] - https://www.mpeforth.com/software/pc-systems/vfx-forth-for-l...

[exikyut]

FWIW: The URL is being truncated right at the "...for-linux" part. I was mildly surprised.

This particular distribution also ships with GTK+.

That being said, a simple "3 2 1 ?" (I was unsure what word would dump the stack) SIGSEGVs quite consistently.

It's also 32-bit, and the backtrace handler produces "XXXX:XXXX" style addresses (?).

[asguy]

You’re dereferencing an invalid pointer with a variable lookup; try “3 2 1 .s” ... there’re some good ANS Forth gems here [0].

[0] - https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-...

[coliveira]

I think the writer use case takes no benefit from Forth. He already has some code and is trying to translate and optimize it. In this case, none of the advantages of Forth matter because he is not doing the development interactively. He was also tied to an existing code architecture that is alien to Forth. A Forth programmer starting from scratch would certainly design things in a way that makes more sense to Forth. Instead, his design clearly benefits a C implementation and goes against the way Forth code is structured.

[druzyek]

OP here. This is a really interesting point. My strategy was to keep the highest level functions/words like DrawTile or DrawMenu while writing the underlying Forth and subwords from scratch focusing on performance. Do you have any suggestions that would make "more sense to Forth" as you say?

[asguy]

Not the GP, but I'd recommend the latest edition of _Thinking Forth_[0]; there's a PDF but the soft-cover is worth picking up. It helped change the way I think about Forth (hah), and really, programming in general.

[0] - http://thinking-forth.sourceforge.net/

[astrobe_]

Although it does not directly help, it gives the general idea:

http://www.ultratechnology.com/levels.htm

[zozbot234]

Yes, FORTH is an elegant alternative to BASIC on very small systems, not something you should expect high performance from.

[MaxBarraclough]

To mirror asguy's comment, this only tells us about the performance of this particular FORTH engine, it doesn't tell us about the performance inherit to FORTH (which of course doesn't exist, it's down to the engine).

Whether anyone has made a sophisticated optimising FORTH for 6502, I don't know.

[Dr_Jefyll]

>this only tells us about the performance of this particular FORTH engine

Yes, exactly. Whatever its other qualities may be, I suspect this particular Forth has overlooked some pretty obvious low hanging fruit, performance-wise. In this[1] post we learn that LOOP puts a 1 on the stack then falls into +LOOP. Although there's elegance (and a memory saving) to that approach, I'm startled that they didn't provide a dedicated definition for LOOP instead. AIUI, implementing LOOP as an instance of +LOOP substantially and needlessly increases the complexity of what gets executed. Yes, I know premature optimization should be viewed with suspicion, but if profiling were performed it's hard to believe LOOP wouldn't be a hot spot! So, I constructively suggest that in this respect at least (and perhaps there are others) this Forth engine could benefit from some tuning up.

[1] http://forum.6502.org/viewtopic.php?p=76849#p76849