Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43808 > unrolled thread

Mecrisp 2.1.6 ARM Linux problem

Started byPaul Rubin <no.email@nospam.invalid>
First post2015-11-25 23:40 -0800
Last post2015-12-01 20:19 -0800
Articles 6 on this page of 26 — 4 participants

Back to article view | Back to comp.lang.forth

Contents

  Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:40 -0800
    Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 09:54 +0100
      Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-26 01:08 -0800
        Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 10:37 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-26 01:52 -0800
            Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 11:22 +0100
              Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-27 12:20 -0800
                Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-12-09 15:04 +0100
                  Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-12-09 23:50 -0800
                    Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-12-10 12:00 +0100
    Re: Mecrisp 2.1.6 ARM Linux problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 09:27 +0000
      Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 01:06 +0100
        Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 18:35 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-27 10:24 -0800
            Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 23:27 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:19 +0000
            Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-28 17:44 +0100
        Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-28 22:19 -0800
          Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 20:47 +0100
            Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-29 12:13 -0800
              Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 01:37 +0100
                Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-29 19:20 -0800
                  Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 23:29 +0100
                    Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-30 18:06 -0800
                      Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-01 23:14 +0100
                        Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-12-01 20:19 -0800

Page 2 of 2 — ← Prev page 1 [2]

#43952

FromBernd Paysan <bernd.paysan@gmx.de>
Date2015-11-30 01:37 +0100
Message-ID<n3g5jc$cil$1@dont-email.me>
In reply to#43942
Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> I'm certainly more interested in getting 0.8.0 stable.  If you get the
>> same problems with the snapshot, please report.
> 
> OK I'll try.

Thanks.

>> Which benchmark did you use? onebench.fs? 4.38s for gforth onebench.fs
>> sounds reasonable.  I've 4.64s on my board, and 2.80s for gforth-fast.
> 
> No the benchmark was just the simple loop I mentioned earlier:
> 
>     1e8 f>s constant nn
>     : test nn 0 do i drop loop ;
>     test bye

That's 1.81s with gforth and 1.165s with gforth-fast on my board (novena 
board, see http://www.kosagi.com/w/index.php?title=Novena_Main_Page, it's a 
quad core Cortex A9@1.2GHz, and I got it to contribute to the cryptech.is 
effort).  As scaleway.com boasts about the performance, I'd expect better 
values than that ;-).  337ms/270ms on my 3GHz Core i7 (gforth/gforth-fast).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#43953

FromPaul Rubin <no.email@nospam.invalid>
Date2015-11-29 19:20 -0800
Message-ID<878u5gdvg5.fsf@jester.gateway.pace.com>
In reply to#43952
Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> If you get the same problems with the snapshot, please report.
>> OK I'll try.
> Thanks.

I cloned the git repo and tried building master.  There was no configure
script so I ran autoconf, which generated one after barfing on
AM_PATH_LISPDIR (did you really want that in there?  I commented it
out).  But there still seems to be some kind of problem with the paths,
and I'm not as skilful with autoconf as I'd like to be.  So before
messing with it further I thought I'd ask if I'm missing something
simple.

> That's 1.81s with gforth and 1.165s with gforth-fast on my board (novena 
> board, see http://www.kosagi.com/w/index.php?title=Novena_Main_Page,

Wow, that's a really nice board, though expensive.  It might be faster
than the Scaleway because of cpu architecture differences.  Here are
the speeds I get for "openssl speed sha256" and "openssl speed rsa2048":

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           8074.82k    20328.45k    38668.46k    50053.80k    54722.56k

                  sign    verify    sign/s verify/s
rsa 2048 bits 0.034637s 0.001072s     28.9    933.2

in case there's an interesting comparison to be made.

[toc] | [prev] | [next] | [standalone]

#43987

FromBernd Paysan <bernd.paysan@gmx.de>
Date2015-11-30 23:29 +0100
Message-ID<n3iifl$kki$1@dont-email.me>
In reply to#43953
Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>> If you get the same problems with the snapshot, please report.
>>> OK I'll try.
>> Thanks.
> 
> I cloned the git repo and tried building master.  There was no configure
> script so I ran autoconf, which generated one after barfing on
> AM_PATH_LISPDIR (did you really want that in there?  I commented it
> out).

For Emacs integration; it's certainly optional.  It's looking like it 
searches for Lisp, but that's really only Emacs Lisp ;-).

> But there still seems to be some kind of problem with the paths,
> and I'm not as skilful with autoconf as I'd like to be.  So before
> messing with it further I thought I'd ask if I'm missing something
> simple.

./autogen.sh should be the first thing you do with a repo clone.

>> That's 1.81s with gforth and 1.165s with gforth-fast on my board (novena
>> board, see http://www.kosagi.com/w/index.php?title=Novena_Main_Page,
> 
> Wow, that's a really nice board, though expensive.

Yes, the cryptech.is team bought it for the FPGA on board.

> It might be faster
> than the Scaleway because of cpu architecture differences.  Here are
> the speeds I get for "openssl speed sha256" and "openssl speed rsa2048":
> 
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> sha256           8074.82k    20328.45k    38668.46k    50053.80k   
> 54722.56k

Slightly faster, especially for smaller blocks:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 
bytes
sha256           10131.65k    22834.11k    39496.62k    48180.91k    
51443.03k

Seems both use NEON's sha256 instruction.

>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.034637s 0.001072s     28.9    933.2

                  sign    verify    sign/s verify/s
rsa 2048 bits 0.027652s 0.000836s     36.2   1196.6

Looks like 20% faster for core-limited calculations.

> in case there's an interesting comparison to be made.

Just to compare that to Ed25519 (same machine):

Test keypair 514.042µs 
Test signing correct sig 563.047µs 
Test verify   1.367780ms  passed
Test forge   1.370448ms  passed
Test EdDH   1.358780ms  correct passed

Signing is a lot faster, verification a bit slower than RSA 2048.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#43991

FromPaul Rubin <no.email@nospam.invalid>
Date2015-11-30 18:06 -0800
Message-ID<87si3mdisx.fsf@jester.gateway.pace.com>
In reply to#43987
Bernd Paysan <bernd.paysan@gmx.de> writes:
> ./autogen.sh should be the first thing you do with a repo clone.

Ah thanks.  That generated a few warnings but make a configure script:

    libtoolize: copying file `./ltmain.sh'
    libtoolize: You should add the contents of the following files to `aclocal.m4':
    libtoolize:   `/usr/share/aclocal/libtool.m4'
    libtoolize:   `/usr/share/aclocal/ltoptions.m4'
    libtoolize:   `/usr/share/aclocal/ltversion.m4'
    libtoolize:   `/usr/share/aclocal/ltsugar.m4'
    libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
    libtoolize: Remember to add `LT_INIT' to configure.in.
    libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
    libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
    libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
    aclocal: warning: autoconf input should be named 'configure.ac', not 'configure\
    .in'
    configure.in:351: warning: AC_LIBOBJ(../$arm_cacheflush): you should use litera\
    ls
    ../../lib/autoconf/general.m4:2938: AC_LIBOBJ is expanded from...
    configure.in:351: the top level

The configure script generated some warnings too:

    configure: WARNING: No GNU_LIBTOOL found, skip pre-building libcc-based libraries
    configure: WARNING: No GNU_LIBTOOL found, using "libtool" as name.
    configure: WARNING: libcc.fs won't work until you have installed (GNU) libtool.
    checking ffi.h usability... yes
    ...
    checking for swig... /usr/bin/swig
    swig error : Unrecognized option -forth
    Use 'swig -help' for available options.
    configure: WARNING: *** Swig without -forth. The library bindings cannot be built.
    config.status: WARNING:  'engine/Makefile.in' seems to ignore the
    --datarootdir setting

I do remember your saying something about needing a special version of
swig, but don't see the post right now.

Finally, make failed:


    $ time make -j4
    if test -r version && test x'0.7.9_20151126' = x`cat version` ; then true ; else echo 0.7.9_20151126 > version ; fi
    GFORTH="./preforth -p ".:~+:."" ./gfgen
    GFORTH="./preforth -p ".:~+:."" ./gfgen
    GFORTH="./preforth -p ".:~+:."" ./gfgen
    GFORTH="./preforth -p ".:~+:."" ./gfgen
    Makefile:980: recipe for target 'engine/prim_lab.i' failed
    make: *** [engine/prim_lab.i] Error 1
    make: *** Waiting for unfinished jobs....
    Makefile:980: recipe for target 'engine/prim.i' failed
    make: *** [engine/prim.i] Error 1
    make: *** Deleting file 'engine/prim.i'
    Makefile:980: recipe for target 'engine/prim_superend.i' failed
    make: *** [engine/prim_superend.i] Error 1
    Makefile:980: recipe for target 'engine/prim_names.i' failed
    make: *** [engine/prim_names.i] Error 1

    real    0m0.053s
    user    0m0.010s
    sys     0m0.020s

As mentioned, if you want an account on the box I'd be happy to put one
on for you.

> Just to compare that to Ed25519 (same machine): ...
> Signing is a lot faster, verification a bit slower than RSA 2048.

That is great!

[toc] | [prev] | [next] | [standalone]

#44027

FromBernd Paysan <bernd.paysan@gmx.de>
Date2015-12-01 23:14 +0100
Message-ID<n3l5uv$l6a$1@dont-email.me>
In reply to#43991
Paul Rubin wrote:
> The configure script generated some warnings too:
> 
>     configure: WARNING: No GNU_LIBTOOL found, skip pre-building
>     libcc-based libraries configure: WARNING: No GNU_LIBTOOL found, using
>     "libtool" as name. configure: WARNING: libcc.fs won't work until you
>     have installed (GNU) libtool.

You should install libtool and libtool-bin.

>     checking ffi.h usability... yes
>     ...
>     checking for swig... /usr/bin/swig
>     swig error : Unrecognized option -forth
>     Use 'swig -help' for available options.
>     configure: WARNING: *** Swig without -forth. The library bindings
>     cannot be built.
>     config.status: WARNING:  'engine/Makefile.in' seems to ignore the
>     --datarootdir setting
> 
> I do remember your saying something about needing a special version of
> swig, but don't see the post right now.

Yes, you need Gerald's fork:

https://github.com/GeraldWodni/swig

> Finally, make failed:
> 
> 
>     $ time make -j4
>     if test -r version && test x'0.7.9_20151126' = x`cat version` ; then
>     true ; else echo 0.7.9_20151126 > version ; fi GFORTH="./preforth -p
>     ".:~+:."" ./gfgen GFORTH="./preforth -p ".:~+:."" ./gfgen
>     GFORTH="./preforth -p ".:~+:."" ./gfgen
>     GFORTH="./preforth -p ".:~+:."" ./gfgen
>     Makefile:980: recipe for target 'engine/prim_lab.i' failed
>     make: *** [engine/prim_lab.i] Error 1
>     make: *** Waiting for unfinished jobs....
>     Makefile:980: recipe for target 'engine/prim.i' failed
>     make: *** [engine/prim.i] Error 1
>     make: *** Deleting file 'engine/prim.i'
>     Makefile:980: recipe for target 'engine/prim_superend.i' failed
>     make: *** [engine/prim_superend.i] Error 1
>     Makefile:980: recipe for target 'engine/prim_names.i' failed
>     make: *** [engine/prim_names.i] Error 1
> 
>     real    0m0.053s
>     user    0m0.010s
>     sys     0m0.020s
> 
> As mentioned, if you want an account on the box I'd be happy to put one
> on for you.

Do you have the old (Debian-based) Gforth installed?  You need Gforth to 
build Gforth from source, just like you need GCC to build GCC from source.  
Any old and slow Gforth will do.  I won't suggest -j4, the make dependencies 
are non-trivial, and doing some things in parallel doesn't seem to work.

>> Just to compare that to Ed25519 (same machine): ...
>> Signing is a lot faster, verification a bit slower than RSA 2048.
> 
> That is great!

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#44031

FromPaul Rubin <no.email@nospam.invalid>
Date2015-12-01 20:19 -0800
Message-ID<877fkxcwjf.fsf@jester.gateway.pace.com>
In reply to#44027
Bernd Paysan <bernd.paysan@gmx.de> writes:
> You should install libtool and libtool-bin.

I thought I installed libtool, but will check.

> Yes, you need Gerald's fork:
> https://github.com/GeraldWodni/swig

Ah, thanks.  I'll install that.

> Do you have the old (Debian-based) Gforth installed?  

Yes :)

> I won't suggest -j4, the make dependencies are non-trivial

Yes, I tried building with a single thread and it gave up after the
first file, so I pasted the j4 output on the idea that the additional
diagnostics might have been useful.

I should be able to continue with this later tonight or tomorrow.
Thanks for the guidance!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web