This stems directly from the fact that, in most practical applications of non-trivial size, the vast majority of execution time is spent in a relatively small proportion of the code. The trick is to identify those performance-critical sections of code and optimise them, specifically. The rest of the application can sensibly be written in a way that is more space-efficient and easier to debug.

It depends on what you're claiming is the 90% performance of assembly. I don't think anyone is saying Forth is outright 90% the performance of assembly. More like you can get 90% the performance of assembly if you chose the proper code to assembly-ize. For instance, in a video game the low level graphics routines better be written in assembly (on a 6502). The 6502 is a really great 8 bit CPU, but not so much when it comes to 16 bit operations. Not that it can't, it just gets tedious and the code size tends to grow quite fast.

I was actually playing around with a 6809 Forth on the Color Computer a of months ago. Its claimed strength was having some CoCo specific libraries for plotting pixels and such. So I added some FORTH79 words that eased stack access and wrote some simple words to draw horizontal and vertical lines and fill in rectangles using the pixel plot word. All in Forth. Not very impressive, even with my new clever stack manipulation words.

On the other hand, I've spent considerable time writing some hires graphics libraries for PLASMA. These routines aren't all that big, but are fairly optimized (I don't like saying highly optimized because someone will come in and speed up my code considerably ) to provide capabilities that PLASMA isn't well suited for - moving lots of images to a complicated screen format. All game logic, 16 bit math and pointer manipulations are *much* easier in PLASMA. Is it 90% of what it would be if it was written in assembly? I don't have an exact number (I'd have to write it in assembly for that) but it is fast enough to be a video game. And I wrote it in a few days instead of a few months. But had I written it in assembly, I would have had to make many of the 16 bit math and pointer manipulations into subroutines as space was getting tight with all the graphics assets. Inlining all those 16 bit operations would bloat the code space too much, something benchmarks don't take into account. Turning those 16 bit operations into calls adds overhead. Note that PLASMA is a byte code interpreter - although its dispatch *is* highly optimized (I'll take that one), but even then it's 15 cycles per byte-code. Still as good or better than most Forths, but you can do a lot in 15 cycles. The idea is to provide enough functionality per bytecode (or word in Forth) to amortize that overhead and provide enough benefit to make it worth while. Otherwise you have a good candidate for assembly.

To use another example from PLASMA involves the major feature added to 2.0: the Just In Time native compiler. It takes the guess work out of choosing which routines should be written in assembly by actually profiling them at runtime. With just a 4K buffer dedicated to JIT compiled routines, the time to compile a significant source module using PLASM, the PLASMA source->bytecode compiler, can be halved. Talking about JIT compiling the AOT compiler gets a little recursive, pun intended. Ok, so not 90%, but the point is a small percentage of routines can impact performance a great deal.

Even Woz used an interpreter for 16 bit operations. Mostly to save space, but he was also careful where he used it so as to not impact performance too much. IIRC, he said Sweet16 ran 10% the speed of his hand optimized code but made minimal impact on overall performance.

How much of that 23K is code, vs how much is graphics or other assets?

A little over 13 kB is graphics and other data for the assembly and C versions. The Forth version will take up a good bit more space because each piece of data has a dictionary entry that adds 13-14 more bytes.

Are there any other places that could be rewritten for performance? It would be interesting to optimize Tali Forth 2 then rerun the tests.

If by 'data' you mean the data from your game, that just means your Forth programming is 10% the performance. As you said in another subforum:

If you haven't already read it, I'd recommend "Thinking Forth" by Leo Brodie.
You mentioned in your game summary that you considered Forth to be unreadable.

And how the translation to C would be written does not matter. Forth is NOT C with reverse polish notation. Forth seems quite readable to me.
Not knowing if a word is a colon definition ( a function ) or a variable, constant, or some other type of Forth word is not a disadvantage. On the contrary, it is an advantage. Consider some actual code from my Forth for the C64:

FREE returns the amount of free memory between PAD and the start of the block buffer table. MRU is a word that returns the address of the start of the buffer table. The address can be changed by changing the number of buffers on the fly like so:

SAVE-BUFFERS and EMPTY-BUFFERS also use MRU . Is MRU a VALUE that only CONFIGURE can alter? Is it a colon definition? It does not matter. All that matters is that it returns the address of the start of the buffer table. I can make MRU a colon definition or a VALUE. As long as it returns the correct address, the colon definitions that use it do not need altered. If Forth had C like calling conventions, how I defined MRU would affect everything that uses it and that would be annoying, to put it mildly.

Another example: Some of the words in my Forth that seem to be constants ( 0 , 1 , TRUE , FALSE for example ) are not actually constants. They are words with a code field and no body. Each one's code field points to the correct code to execute ( in another code word ). The colon definitions that use these 'constants' don't need to be any different because these four words are not really constants.

Yes, I mean my game. Surely you don't mean that my code would be 10 times faster if someone more experienced rewrote it? That's completely unbelievable, but the source is on github if you wanna take a stab.

It's certainly not an advantage. The problem is when one of these, whatever it is technically, adds or removes an unknown number of things from the stack. I guess if you get everything right on your first draft you can get away with write only programming, but when you try to understand someone else's code or your own after enough time has gone by or you need to modify existing code, what that word does to the stack is VERY important. If you are low-level enough to care what is actually on the stack, you need to understand what every single word adds or removes, and you just don't have that information at a glance the way you do in C.

This is a good example. How am I supposed to know that MRU returns the address? How do I know it returns anything? How do I know it doesn't remove something instead of returning something? Sure, I can look up the word definition but what happens when I have 5 such unknown words on the same line? That's a lot to juggle in your head compared to C.

Fair enough. Whatever TRUE actually is internally, it has a predictable effect on the stack, so no complaints there. The problem is with user-defined words that could be doing anything. Those make the source "unreadable," at least if you're thinking on the level where you care what the stack looks like after each word.

As a total noob, I tend to put stack comments after each source line:
Forth hasn't "clicked" in my tired old brain yet, but I find it so appealing that I want to give it as many chances as I can, limited spare time permitting.

[Edit: it looks like I could have factored out the sequence @ - dup 0< 1 or swap abs dup , but I have no clue what kind of name I would give that little slice of goodness ... maybe HUH ?]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I didn't say the improvement would be tenfold.
Surely you don't mean that as a Forth beginner you can write Forth nearly as well as an experienced Forth programmer?

You don't even know all the core words in the ANSI Standard Forth you're using.

But then how would you learn to be a better Forth programmer?

A Forth word should never remove an unknown number of items from the data stack. Nor should it add an unknown number of items. When a Forth word is written, a stack comment should be written right after the name. The word should then be tested to insure it functions properly. Once the word works, make sure the stack comment is still accurate.

Your comment implies that you think the way to program in Forth is to write the entire application at once and then see if it will compile. Maybe this is normal practice with C. With Forth's interactive nature it is normal to program interactively by writing the lowest level words first and then testing a word once it is written.

I never said it wasn't.

I always care what is on the stack.

You do if you check the stack comments which you should be writing as you write your application.

You can always add stack comments anywhere in your source. The stack comments alone will not tell you what a word does any more than a C function prototype. This function:

Could do anything. All the function prototype tells me is that it takes no arguments and returns none. How do I know it doesn't call malloc() without freeing the allocated memory before it returns?

Sorry if I misunderstood you here. This is what I was going off of:
Do you mean my Forth programming is 10% the performance it would be if it were rewritten? No, I don't think I write Forth nearly as well as an experienced Forth programmer, but even if my programming is twice as slow (and I don't think it is), Forth would still lag way behind C and assembly in performance.

Fair enough. I understand why you wouldn't want to try to improve my code. How about another example you could point to then that would better reflect the performance difference than the example I've given? That would eliminate my skill as a Forth programmer from the equation.

The number of words is not unknown to the programmer in the moment they write it, but it is unknown to someone else reading what they wrote or to themselves if enough time has gone by until they hunt down the stack comment. This is what I mean by unreadable.

If you have to go somewhere else in the file or into another file to find the stack comment then that is not what I mean by "at a glance."

No, it could not be doing anything. As you noticed, it cannot return anything and it can't take any arguments. This is a promise that will never be broken. In Forth, you don't know what happens to the stack without the comment, the comment could be wrong (because you've changed the code and forgot to update the comment) or it might not exist if it's someone else's code. This never happens to the stack in C. Ever. Also, having to copy the stack comment down to where the word it relates to is used just to keep things straight is absurd enough to illustrate the point. Yes, the function could call malloc but that has nothing to do with being able to tell what goes onto and comes off of the stack. There are always things you don't instantly know. My point is that what happens to the stack is not one of them in C but it is in Forth.

FWIW, I'm fluent with Forth and have plenty of experience, but I still do that from time to time. Just sayin'! There are occasions where it can be a helpful part of the commenting.

Sure, Forth has a few peccadillos... and it doesn't bother me to hear them mentioned. Fair comment, I say. In the overall tradeoff Forth is still a big win for me!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Right

That's interesting. Do you read other people's Forth code? This happened enough times to be annoying in my game even though I only worked on it over a short period. I'll come back in a year and see how much I've forgotten.

Nope, mine doesn't show me function declarations either. I think you're still missing the point here. If you just see a function call without the declaration, you can tell how many arguments it takes and whether it's returning anything. You can't do that in Forth without the comments. There are other things that you can't tell instantly in C, and I won't argue if you point those out since my point is not that C is perfect, but when it comes to just this one point, there is at least one thing that C has and Forth doesn't. Pointing out unrelated things doesn't make that less true.

I'm not sure what your point is. Are you showing that you can pass a pointer that's used to return a value? Are you pointing out that some functions have varargs? Neither of those contradict what I said.

Ya, you can use varargs to set up this type of situation, but as you know, the great majority of C code doesn't rely on this. It's telling that you had to go to something relatively uncommon to try to make the point. Still, even with varargs we can tell how many arguments a call is taking even if it doesn't take the same number of arguments every time. Not so with Forth.

Thanks but I'm certainly not in over my head. It's a valid criticism of the design of the language.

If you're saying you prefer Forth, I'm not arguing with you. Interactively testing is useful.

The context of this was compared to writing the code out into a file then having the emulator type that in for you. It's true that it's hardly faster to type it into the console than it is to type it into a file that's instantly relayed to the Forth prompt. This makes sense anyway when you're cross compiling and not saving compiled words out of the target system back to the host. This doesn't mean I don't use the stack interactively sometimes.

Because C is simpler than Python and almost any other language you can think of. Even in a language as simple as C with very few comforts, the compiler handles a minimal amount of stack housekeeping so you don't waste brain power on stack gymnastics like you do in Forth. For example, you'll never have to reorder your stack every iteration though a loop in C so they are back in the right order.

No, I don't translate directly from C to Forth (even if I may have been inclined to six years ago), but it's a valid point that I may be doing it unintentionally without realizing it. Now we're back to the same point from previous posts that you still haven't been able to answer. I'm claiming that the performance of Forth on the 6502 is much worse than both C and assembly and your response is to blame it on my lack of knowledge and experience. I admit that this could be playing a role, which is why I offered to let you improve on my example or point to another example as evidence. You haven't done either of these. At this point, you need to either concede that Forth on the 6502 has many advantages, but performance isn't one of them, or you need to provide something other than dogma to demonstrate that well-written Forth (again admitting that my code may not qualify) runs anywhere near the speed of well-written C or assembly.

Fair point. What do you think the percentage would be if you or someone else had written it instead of me? Can you demonstrate how you know that?

Yes. Of course I've read Starting Forth. I've also read a good chunk of Thinking Forth. Again, if you're arguing that Forth performed poorly because I lack knowledge, you'll need to demonstrate that somehow.

Yikes! Maybe you shouldn't be making any claims at all then when it comes to performance if you have nothing to back them up with. Or go and run your own tests then report back with the results like I did.

Right. If you have a Forth that generates faster code, just send me a link and I'll give it a try. As I mentioned, you could cross-compile Forth and do a lot of optimizing to generate a binary that runs significantly faster. I can't port the game to that though if it doesn't exist or I don't have access to it. On the other hand, CC65 could also produce better optimized code, but we can't compare the ideal Forth implementation to the ideal C implementation if they don't exist.

I said at the beginning that I was going for speed over size, so why would I make changes that slow things down to save space as leepivonka suggests? As for the example of 2*, the game uses that extensively. I checked and 2 * appears only four times and always between [ and ] so there is no runtime penalty.

Wrong again. I see below you found a few improvements, but it's a leap to say I didn't bother familiarizing myself with the core words.

That is faster. Thanks.

I'm also not trying to convert you to not use Forth. If you are honest about it's shortcomings and still prefer to use it, there is nothing left for us to argue about. That is a matter of preference. I'm working on a project now that involves Forth because despite the disadvantages mentioned above, I still think it's a good fit. My objection is to the misinformation (or maybe even dishonesty) about the capabilities of the language that are floating around. This project is partly about trying to put those claims to the test, at least for the 6502.

It's strange that you say you're not debating the merits of the languages since that's the reason I started the thread, and you've spent pages doing just that. In any case, I think you could use a good dose of the "thinking outside the box" that you prescribe above. Like most of the Forth fans I've met online outside of this forum, you're convinced of the greatness of the language and if anything disagrees with that, then it must be wrong. Hence your suggestion that I read books I've already read and "learn" Forth despite having written thousands of lines of it. How have you determined that my Forth code is slow because I'm used to programming in C versus my Forth code being slow because Forth is slow? You don't seem to see how it could be that someone could know enough to understand the situation and still disagree with you. That's backwards. First, let's look at the data (again happy to consider alternatives if you don't like mine) then determine the language's greatness rather than taking the greatness of the language for granted and dismissing anything that doesn't agree out of hand.

Thanks for the debate. I'm enjoying the discussion and happy to continue if you have more thoughts.