Hi Anton
Well the code is part of my hobby datalogger
https://github.com/harrypower/datalogger . In the directory called
collection and the file called pipetesting.fs. This will only work on a
Raspberry pi running debian wheezy i believe as there is a shared c library
from another repository of mine. Anyways the speed test does not really
test the efficiency or inefficiency of gforth but rather my methods for
doing some gpio pin access. I already knew my stuff was slow i just wanted
to play with other methods and see how i could change the speed. So
clearly directly compiled gforth code accessing a c library is always
faster then calling a gforth program via a shell command and receiving the
messages via a pipe or a file. I was surprized that i could get 100 to 200
times speed increase but i think most of that is the shell use and access
to a pipe and or file and the time the gforth code took to load and compile
and such.
I am just a hobbyist learning linux and gforth so i am trying methods
out for accessing gpio on the raspberry pi. I have decided now to just do
it directly in gforth and not use a c shared library at all.
Yes your idea of breaking the program up in some different way is a
good idea but as Bernd says "this is usually not very practicable" may also
be true. At this moment i am just getting familiar with the different
options and techniques to do this stuff in gforth and also the options
linux offers for IPC. Also i am trying to keep it simple so others could
possibly gain knowledge and use of the code for Raspberry Pi GPIO.
The test code pipetesting.fs has dotime-test, dotime-test1,
dotime-test2, dotime-test3, dotime-test4 and each one will produce a two
numbers. But again i am not perfectly compairing apples to apples so the
200 times speed difference is just comparing my worst method with my
fastest method. I believe once i simply rewrite the GPIO stuff in Gforth
it will even be faster yet.
PKS
On Tue, Sep 3, 2013 at 9:14 AM, Anton Ertl <[email protected]
> wrote:
> On Mon, Sep 02, 2013 at 05:16:57PM -0600, Philip Smith wrote:
> > I have done some testing to see the speed benefit of precompiled
> images
> > and i find that there is up to 200 times speed benefit for some of my
> > testing code.
>
> Could you make that testing code available. I find this difference
> amazing. The basic difference is that with an image you don't need to
> compile from source to threaded code, everything else is pretty much
> the same; and unless you have huge programs, the compile time is
> short; it may be noticable if you call the same script many times in a
> row, and it is very fast at executing.
>
> Ok, you can always slow it down by doing some execution during
> loading, but otherwise, I would be surprised if this is a problem.
>
> In any case, you can work around this limitation by dividing the
> program in a part that goes into the image and a part the does not;
> you do the slow parts during image generation and do the shared
> library linking in the non-image part. I think after the first time
> the shared library linking is not slow.
>
> - anton
>
--
\|||/
-----0oo---( o o )---oo0------
(_)
>From the hand of PKS
