You are not logged in.
I have recently started learning forth and at the moment I am using the gforth interpreter (it seems to be the most feature filled free as in freedom forth interpreter). The problem I am facing is that when using custom c functions, gforth takes a relatively long amount of time processing the c functions. I suspect this might be a problem as it might have to compile a c file consisting of the functions every time I run the program. If this is indeed the problem would it be possible to use a different compiler such as tcc that compiles significantly faster? For those who were wondering here is an example program demonstrating the problem:
\c #include <stdio.h>
\c #include <malloc.h>
c-function alloc malloc n -- a
variable string 1000 alloc string !
bye
Running time on this results in the following:
time (gforth random.fs )
real 0m0.176s
user 0m0.161s
sys 0m0.025s
Taking 0.17 seconds just to allocate 1000 bytes is far longer than it should.
Does anyone here know what the problem is, or how to solve it. (If there are any other forth interpreters that can also use C functions, please let me know).Thanks a lot!
Offline
I suspect this might be a problem as it might have to compile a c file consisting of the functions every time I run the program.
... Taking 0.17 seconds just to allocate 1000 bytes is far longer than it should.
These are contradictory assumptions. Are you concerned that it's taking too long compiling (0.17s doesn't seem that problematic), or are you concerned that it's taking too long running the compiled product (in which case 0.17s might be a lot if you assume this time will scale linearly with the number of bytes allocated).
In either case, don't assume; test. Does the time change if you allocate 10000 bytes? or 100000? If not, then it is compile time, and 0.17s doesn't sound that bad (and as it's constant, it'd be nothing to worry about). If it does change, then the problem isn't compiling at all, so another C compiler is not likely the right solution.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Huh, I tried adding allocating more bytes but the time taken did not go up, so it does indeed seem to be a compilation problem. However the main problem that I am facing is that (since gforth interprets the code every time) it is impossible to "compile" the forth program, instead every time I want to run the program, it always takes approximately 0.17 seconds to initialize, this indeed is not too much however creating some scripts with a permanent 0.17 second startup time can get annoying as time passes.
Offline
Really? 0.17 is too long? And again, that's not *just* the compilation. All you've shown is that initialization of the gforth interpreter, calling of the c compiler, compilation of the c code, and the running of the gforth script all together take 0.17s.
Have you done anythng to test which of these steps is actually taking most of that time? It'd be trivially easy to test the initialization and run time of the gforth interpreter in the absence of any c code. And based on the documentation, this is not even expected to be trivial as there are two versions of the interpreter (gforth and gforth-fast) to be used based on whether your priorities are minimizing initialization time or run time (and there are several settings and ofther factors that will also influence these).
Is this for a web server? Or why do you expect so many startups of the script that 0.17s would be a problem? If it is a web server, shouldn't you be using fastCGI?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline