This is because stack machine is not well suited for modern architectures with large pipelines.
Forth is just don't use pipeline length - Forth works with extremely short commands chains, and makes pipeline reload on every word of data.
Pipelines prefer to work with long command chains and these chains should not contain jumps (yes, pipeline hate goto's, and prefer vectors of fundamental machine type).
Other minor issue, that Forth uses only one index register for any single step (good optimized C compiler use absolute access, and sure could use registers for variables, and even could vectorize programs automatically).
So typical Fort on old CPU (before pipelined) is magnitude slower than C, and on modern architectures may be 2 magnitudes.
Good thing, Forth may be the best, when need to make some assembler includes (better than C). So if fast mean, that you could make assembler includes - Forth is best choice.
Example of asm optimize could be something like compare two vectors of 32-bit integers with vector commands - this is at least 4 times faster than classic C. But it is not well suited for Unicode data (because need conversion or some sort of one-symbol per step work). To be honest, I have not looked under the hood of Unicode processing, may be things better.
For scalable, the main issue with Forth is that it is tightly coupled to fundamental machine types (not Scala types).
But as I hear, exists few groups, which used some sort of functional programming with Forth. And they said, Forth is very well suited for functional :) So may be new people could make things much better.
no subject
Date: 2017-02-06 03:46 am (UTC)This is because stack machine is not well suited for modern architectures with large pipelines.
Forth is just don't use pipeline length - Forth works with extremely short commands chains, and makes pipeline reload on every word of data.
Pipelines prefer to work with long command chains and these chains should not contain jumps (yes, pipeline hate goto's, and prefer vectors of fundamental machine type).
Other minor issue, that Forth uses only one index register for any single step (good optimized C compiler use absolute access, and sure could use registers for variables, and even could vectorize programs automatically).
So typical Fort on old CPU (before pipelined) is magnitude slower than C, and on modern architectures may be 2 magnitudes.
Good thing, Forth may be the best, when need to make some assembler includes (better than C).
So if fast mean, that you could make assembler includes - Forth is best choice.
Example of asm optimize could be something like compare two vectors of 32-bit integers with vector commands - this is at least 4 times faster than classic C.
But it is not well suited for Unicode data (because need conversion or some sort of one-symbol per step work).
To be honest, I have not looked under the hood of Unicode processing, may be things better.
For scalable, the main issue with Forth is that it is tightly coupled to fundamental machine types (not Scala types).
But as I hear, exists few groups, which used some sort of functional programming with Forth. And they said, Forth is very well suited for functional :)
So may be new people could make things much better.