Re: [gforth] Gforth image files and shared c librarys! How to access?

[Philip Smith]

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 <address@hidden> 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