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

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

Re: string-stack.4th

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 08:23 -0700
    Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 08:33 -0700
      Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:34 +0000
        Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 17:11 -0700
          Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-17 23:22 +0000
            Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 18:14 -0700
              Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-17 18:44 -0700
              Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-19 23:09 +0000
    Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 09:02 -0700
      Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 15:29 -0700
      Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-16 19:43 -0700
        Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-16 22:42 -0700
          Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-16 23:09 -0700
            Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-16 23:34 -0700
              Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 00:15 -0700
              Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-17 01:19 -0700
                Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 02:06 -0700
                  Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 02:50 -0700
                  Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-17 13:14 -0700
                    Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 15:58 -0700
                      Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-17 16:57 -0700
                        Re: string-stack.4th "Elizabeth D. Rather" <erather@forth.com> - 2017-04-17 15:07 -1000
                        Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-05-17 05:32 -0700
                      Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-17 19:49 -0700
                Re: string-stack.4th "David N. Williams" <williams@umich.edu> - 2017-04-17 20:11 -0500
                  Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-17 18:15 -0700
                  Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 19:13 -0700
                    Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-17 19:21 -0700
                      Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-18 01:25 -0700
                        Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-18 19:27 -0700
                      Re: string-stack.4th "David N. Williams" <williams@umich.edu> - 2017-04-18 11:27 -0500
                  Re: string-stack.4th mhx@iae.nl - 2017-04-18 11:53 -0700
                    Re: string-stack.4th albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:48 +0200
                      Re: string-stack.4th mhx@iae.nl - 2017-04-20 14:58 -0700
            Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-17 00:46 -0700
    Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-16 19:31 -0700

Page 1 of 2  [1] 2  Next page →

#57445 — Re: string-stack.4th

Hugh, I tested your string stack against mine in Win32Forth 6.15.03, a simple test:

\ : test 0 do over$ over$ drop$ drop$ loop ; 
\ : test 0 do sover sover sdrop sdrop loop ; 

and found that mine ran the test 6 times faster than your.

My string stack is a shitty hack without any kind of sophistication: no heaps, no error checks, no adress references just copying all strings when juggling...

I not assure how to interpret this, because I'm convinced you're a far better coder than me.

[toc] | [next] | [standalone]

#57446

Den söndag 16 april 2017 kl. 17:23:17 UTC+2 skrev lehs:
> Hugh, I tested your string stack against mine in Win32Forth 6.15.03, a simple test:
> 
> \ : test 0 do over$ over$ drop$ drop$ loop ; 
> \ : test 0 do sover sover sdrop sdrop loop ; 
> 
> and found that mine ran the test 6 times faster than your.
> 
> My string stack is a shitty hack without any kind of sophistication: no heaps, no error checks, no adress references just copying all strings when juggling...
> 
> I not assure how to interpret this, because I'm convinced you're a far better coder than me.

I THINK it's about the heap in Windows. I had the same experience for my big integers, the code was about 5 times faster with unsophisticated stack juggling than with intensiv use of allocate, free etc.

https://github.com/Lehs/ANS-Forth-libraries

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

#57465

lehs wrote:

> Den söndag 16 april 2017 kl. 17:23:17 UTC+2 skrev lehs:
> > Hugh, I tested your string stack against mine in Win32Forth
> > 6.15.03, a simple test:
> > 
> > \ : test 0 do over$ over$ drop$ drop$ loop ; 
> > \ : test 0 do sover sover sdrop sdrop loop ; 
> > 
> > and found that mine ran the test 6 times faster than your.
> > 
> > My string stack is a shitty hack without any kind of
> > sophistication: no heaps, no error checks, no adress references
> > just copying all strings when juggling...
> > 
> > I not assure how to interpret this, because I'm convinced you're a
> > far better coder than me.
> 
> I THINK it's about the heap in Windows. I had the same experience for
> my big integers, the code was about 5 times faster with
> unsophisticated stack juggling than with intensiv use of allocate,
> free etc.

In many language runtimes, allocation and freeing can be pretty slow
and hard to do. Ok, some have very sophisticated memory managers than
can do this faster, but it remains something that is not cheap.

My toy Forth is written in assembly, and that is why I don't have
implemented ALLOCATE and friends yet: I would have to write my own
memory manager.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"His ignorance is encyclopedic"
-- Abba Eban (1915-2002)

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

#57466

I don't know how ALLOCATE & Co are implemented in Win32Forth, but SP-Forth use winapi. I will test SP-Forth and GForth for Androids and see what I get.

Here is an other Abba Eban:
"History teaches us that men and nations behave wisely once they have exhausted all other alternatives."
I hope his wisdom influenced on his acting - but I doubt.

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

#57508

lehs wrote:

> I don't know how ALLOCATE & Co are implemented in Win32Forth, but
> SP-Forth use winapi. I will test SP-Forth and GForth for Androids and
> see what I get.

But I assume that SP-Forth only allocates large chunks from the WinAPI
and then sub-allocates those (using its own memory manager) into
smaller chunks when they are requested? Otherwise it could be pretty
slow, indeed.
 
-- 
Rudy Velthuis (dentist)

"For there was never yet philosopher
 That could endure the toothache patiently."
 -- William Shakespeare, Much Ado About Nothing

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

#57517

Den tisdag 18 april 2017 kl. 01:22:48 UTC+2 skrev Rudy Velthuis:
> lehs wrote:
> 
> > I don't know how ALLOCATE & Co are implemented in Win32Forth, but
> > SP-Forth use winapi. I will test SP-Forth and GForth for Androids and
> > see what I get.
> 
> But I assume that SP-Forth only allocates large chunks from the WinAPI
> and then sub-allocates those (using its own memory manager) into
> smaller chunks when they are requested? Otherwise it could be pretty
> slow, indeed.
>  
> -- 
> Rudy Velthuis (dentist)
> 
> "For there was never yet philosopher
>  That could endure the toothache patiently."
>  -- William Shakespeare, Much Ado About Nothing

I don't know if SP-Forth has a memory manager but ALLOCATE and FREE seems to be implemented bye the kernel32.dll. I wrongly supposed that Hugh had used ALLOCATE for his String-stack. His 2k rows code depends on the 3k rows on his novice package and it isn't readily accessible to me even if I have the source.

I would like faster stacks than mine, but I don't now anything of this "memory management" and what it can do for me.

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

#57520

On Monday, April 17, 2017 at 6:14:32 PM UTC-7, lehs wrote:
> Den tisdag 18 april 2017 kl. 01:22:48 UTC+2 skrev Rudy Velthuis:
> > lehs wrote:
> > 
> > > I don't know how ALLOCATE & Co are implemented in Win32Forth, but
> > > SP-Forth use winapi. I will test SP-Forth and GForth for Androids and
> > > see what I get.
> > 
> > But I assume that SP-Forth only allocates large chunks from the WinAPI
> > and then sub-allocates those (using its own memory manager) into
> > smaller chunks when they are requested? Otherwise it could be pretty
> > slow, indeed.
> >  
> > -- 
> > Rudy Velthuis (dentist)
> > 
> > "For there was never yet philosopher
> >  That could endure the toothache patiently."
> >  -- William Shakespeare, Much Ado About Nothing
> 
> I don't know if SP-Forth has a memory manager but ALLOCATE and FREE seems to be implemented bye the kernel32.dll. I wrongly supposed that Hugh had used ALLOCATE for his String-stack. His 2k rows code depends on the 3k rows on his novice package and it isn't readily accessible to me even if I have the source.
> 
> I would like faster stacks than mine, but I don't now anything of this "memory management" and what it can do for me.

I do use ALLOCATE for unique strings.

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

#57610

lehs wrote:

> I don't know if SP-Forth has a memory manager but ALLOCATE and FREE
> seems to be implemented bye the kernel32.dll.

Hmmm... That could be slow indeed.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"Benny Goodman plays the clarinet. I play music." 
 -- Artie Shaw

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

#57449

Den söndag 16 april 2017 kl. 17:23:17 UTC+2 skrev lehs:
> Hugh, I tested your string stack against mine in Win32Forth 6.15.03, a simple test:
> 
> \ : test 0 do over$ over$ drop$ drop$ loop ; 
> \ : test 0 do sover sover sdrop sdrop loop ; 
> 
> and found that mine ran the test 6 times faster than your.
> 
> My string stack is a shitty hack without any kind of sophistication: no heaps, no error checks, no adress references just copying all strings when juggling...
> 
> I not assure how to interpret this, because I'm convinced you're a far better coder than me.

With this test my code ran 4 times faster.

\ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
\ : test1 0 do sover sover sswap sdrop sdrop loop ;

The method with heaps and references is faster for SWAP.

https://forthmath.blogspot.se
https://github.com/Lehs/ANS-Forth-libraries

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

#57464

Den söndag 16 april 2017 kl. 18:02:40 UTC+2 skrev lehs:
> Den söndag 16 april 2017 kl. 17:23:17 UTC+2 skrev lehs:
> > Hugh, I tested your string stack against mine in Win32Forth 6.15.03, a simple test:
> > 
> > \ : test 0 do over$ over$ drop$ drop$ loop ; 
> > \ : test 0 do sover sover sdrop sdrop loop ; 
> > 
> > and found that mine ran the test 6 times faster than your.
> > 
> > My string stack is a shitty hack without any kind of sophistication: no heaps, no error checks, no adress references just copying all strings when juggling...
> > 
> > I not assure how to interpret this, because I'm convinced you're a far better coder than me.
> 
> With this test my code ran 4 times faster.
> 
> \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> 
> The method with heaps and references is faster for SWAP.
> 
> https://forthmath.blogspot.se
> https://github.com/Lehs/ANS-Forth-libraries

The strings on the stack where
S" Hello world" >str  ( >$ )
s" This is a very long string about nothing only created to test two different string-stack systems" >str  ( >$ )

If your code had been faster I would have reorganized mine and got a faster code, which would have been nice...

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

#57469

On Sunday, April 16, 2017 at 9:02:40 AM UTC-7, lehs wrote:
> Den söndag 16 april 2017 kl. 17:23:17 UTC+2 skrev lehs:
> > Hugh, I tested your string stack against mine in Win32Forth 6.15.03, a simple test:
> > 
> > \ : test 0 do over$ over$ drop$ drop$ loop ; 
> > \ : test 0 do sover sover sdrop sdrop loop ; 
> > 
> > and found that mine ran the test 6 times faster than your.
> > 
> > My string stack is a shitty hack without any kind of sophistication: no heaps, no error checks, no adress references just copying all strings when juggling...
> > 
> > I not assure how to interpret this, because I'm convinced you're a far better coder than me.
> 
> With this test my code ran 4 times faster.
> 
> \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> 
> The method with heaps and references is faster for SWAP.

I don't think this is true. None of those strings ever get put in the heap. ALLOCATE never gets called. No string is ever copied.

empty$  ok
s" foo" >$  s" bar" >$  .s$ 
STRING STACK:
derivative: |bar|
derivative: |foo| ok
over$ over$  .s$ 
STRING STACK:
derivative: |bar|
derivative: |foo|
derivative: |bar|
derivative: |foo| ok
swap$  .s$ 
STRING STACK:
derivative: |foo|
derivative: |bar|
derivative: |bar|
derivative: |foo| ok
drop$ drop$  .s$ 
STRING STACK:
derivative: |bar|
derivative: |foo| ok

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

#57475

On Sunday, April 16, 2017 at 7:43:49 PM UTC-7, hughag...@gmail.com wrote:
> On Sunday, April 16, 2017 at 9:02:40 AM UTC-7, lehs wrote:
> > With this test my code ran 4 times faster.
> > 
> > \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> > \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> > 
> > The method with heaps and references is faster for SWAP.
> 
> I don't think this is true. None of those strings ever get put in the heap. ALLOCATE never gets called. No string is ever copied.

It is possible that you have an old version of STRING-STACK.4TH --- for a while, I had >$ making unique strings, which was not necessary most of the time (because most strings come from S" that is non-mutable) --- now I have >$ assume that the string is non-mutable and makes a derivative on the string-stack, and I have MUT>$ that is for mutable strings (such as <CSTR ... CSTR> strings) and these get converted into unique strings. I also have HEAP>$ that is for strings that are already on the heap (typically because they came from $> and got held in a data-structure for a while).

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

#57476

On Sunday, April 16, 2017 at 10:42:48 PM UTC-7, hughag...@gmail.com wrote:
> On Sunday, April 16, 2017 at 7:43:49 PM UTC-7, hughag...@gmail.com wrote:
> > On Sunday, April 16, 2017 at 9:02:40 AM UTC-7, lehs wrote:
> > > With this test my code ran 4 times faster.
> > > 
> > > \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> > > \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> > > 
> > > The method with heaps and references is faster for SWAP.
> > 
> > I don't think this is true. None of those strings ever get put in the heap. ALLOCATE never gets called. No string is ever copied.
> 
> It is possible that you have an old version of STRING-STACK.4TH --- for a while, I had >$ making unique strings, which was not necessary most of the time (because most strings come from S" that is non-mutable) --- now I have >$ assume that the string is non-mutable and makes a derivative on the string-stack, and I have MUT>$ that is for mutable strings (such as <CSTR ... CSTR> strings) and these get converted into unique strings. I also have HEAP>$ that is for strings that are already on the heap (typically because they came from $> and got held in a data-structure for a while).

Actually, that wouldn't have much effect on the speed because >$ isn't inside of the loop. All you have inside of the loop are stack-juggling words, and these don't make unique strings (they don't call ALLOCATE and they don't copy the string); they just juggle references.

I think that you are just making up a bullshit story. There is no way that copying strings is 6 times (or 4 times) faster than copying a reference. STRING-STACK.4TH uses COW (copy-on-write) for the purpose of making it fast. 

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

#57477

Den måndag 17 april 2017 kl. 08:09:17 UTC+2 skrev hughag...@gmail.com:
> On Sunday, April 16, 2017 at 10:42:48 PM UTC-7, hughag...@gmail.com wrote:
> > On Sunday, April 16, 2017 at 7:43:49 PM UTC-7, hughag...@gmail.com wrote:
> > > On Sunday, April 16, 2017 at 9:02:40 AM UTC-7, lehs wrote:
> > > > With this test my code ran 4 times faster.
> > > > 
> > > > \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> > > > \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> > > > 
> > > > The method with heaps and references is faster for SWAP.
> > > 
> > > I don't think this is true. None of those strings ever get put in the heap. ALLOCATE never gets called. No string is ever copied.
> > 
> > It is possible that you have an old version of STRING-STACK.4TH --- for a while, I had >$ making unique strings, which was not necessary most of the time (because most strings come from S" that is non-mutable) --- now I have >$ assume that the string is non-mutable and makes a derivative on the string-stack, and I have MUT>$ that is for mutable strings (such as <CSTR ... CSTR> strings) and these get converted into unique strings. I also have HEAP>$ that is for strings that are already on the heap (typically because they came from $> and got held in a data-structure for a while).
> 
> Actually, that wouldn't have much effect on the speed because >$ isn't inside of the loop. All you have inside of the loop are stack-juggling words, and these don't make unique strings (they don't call ALLOCATE and they don't copy the string); they just juggle references.
> 
> I think that you are just making up a bullshit story. There is no way that copying strings is 6 times (or 4 times) faster than copying a reference. STRING-STACK.4TH uses COW (copy-on-write) for the purpose of making it fast.

No you might be right! I just did the same test on GForth Android and got the results:

0.230113 seconds for 1 miljon loops, your string-stack.4th
0.459716 seconds for 1 miljon loops, my stringstack.4th

There was some problem loading your novice.4th plus string-stack.4th (pasting) in Win32Forth, with 3 numbers on the stack after loaded.

This is interesting so I will go on testing. If I understand how your system works, I might be able to speed up my bigintegers.4th with that idea of yours.

Lars-Erik Svahn
https://forthmath.blogspot.se
https://github.com/Lehs/ANS-Forth-libraries

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

#57479

Den måndag 17 april 2017 kl. 08:34:29 UTC+2 skrev lehs:
> Den måndag 17 april 2017 kl. 08:09:17 UTC+2 skrev hughag...@gmail.com:
> > On Sunday, April 16, 2017 at 10:42:48 PM UTC-7, hughag...@gmail.com wrote:
> > > On Sunday, April 16, 2017 at 7:43:49 PM UTC-7, hughag...@gmail.com wrote:
> > > > On Sunday, April 16, 2017 at 9:02:40 AM UTC-7, lehs wrote:
> > > > > With this test my code ran 4 times faster.
> > > > > 
> > > > > \ : test1 0 do over$ over$ swap$ drop$ drop$ loop ; 
> > > > > \ : test1 0 do sover sover sswap sdrop sdrop loop ;
> > > > > 
> > > > > The method with heaps and references is faster for SWAP.
> > > > 
> > > > I don't think this is true. None of those strings ever get put in the heap. ALLOCATE never gets called. No string is ever copied.
> > > 
> > > It is possible that you have an old version of STRING-STACK.4TH --- for a while, I had >$ making unique strings, which was not necessary most of the time (because most strings come from S" that is non-mutable) --- now I have >$ assume that the string is non-mutable and makes a derivative on the string-stack, and I have MUT>$ that is for mutable strings (such as <CSTR ... CSTR> strings) and these get converted into unique strings. I also have HEAP>$ that is for strings that are already on the heap (typically because they came from $> and got held in a data-structure for a while).
> > 
> > Actually, that wouldn't have much effect on the speed because >$ isn't inside of the loop. All you have inside of the loop are stack-juggling words, and these don't make unique strings (they don't call ALLOCATE and they don't copy the string); they just juggle references.
> > 
> > I think that you are just making up a bullshit story. There is no way that copying strings is 6 times (or 4 times) faster than copying a reference. STRING-STACK.4TH uses COW (copy-on-write) for the purpose of making it fast.
> 
> No you might be right! I just did the same test on GForth Android and got the results:
> 
> 0.230113 seconds for 1 miljon loops, your string-stack.4th
> 0.459716 seconds for 1 miljon loops, my stringstack.4th
> 
> There was some problem loading your novice.4th plus string-stack.4th (pasting) in Win32Forth, with 3 numbers on the stack after loaded.
> 
> This is interesting so I will go on testing. If I understand how your system works, I might be able to speed up my bigintegers.4th with that idea of yours.
> 
> Lars-Erik Svahn
> https://forthmath.blogspot.se
> https://github.com/Lehs/ANS-Forth-libraries

Tests on GForth 64 bits Windows:

s" Hello world" >$  ok
s" This is a very long string about nothing created to test two different systems of string stack" >$  ok
: test 0 do over$ over$ drop$ drop$ loop ;  ok
utime 1000000 test utime d- d. -170776  ok

s" Hello world" >str  ok
s" This is a very long string about nothing created to test two different systems of string stack" >str  ok
: test 0 do sover sover sdrop sdrop loop ;  ok
utime 1000000 test utime d- d. -377323  ok

I can't load novice.4th in SP-Forth. It stops reporting an underflow.
Also loading thru Win32Forth IDE stops with an error at your first macro definition. 

It seems that your implementation is more than twice as fast as my very simple implementation. Perhaps not som much in string handling, but if big integers could use the same idea it would means a lot.

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

#57482

lehs <skydda.barnen@gmail.com> writes:
> I might be able to speed up my bigintegers.4th

I wonder if you could run a test for me: let p = 17**250 + 2704
(this number happens to be prime) and time how long it takes for
your implementation to do a Fermat test: calculate (3**p) mod p
which should be equal to 3.

My feeling is that if this takes less than a few seconds, your package
is reasonably usable for public-key cryptography.  

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

#57484

Den måndag 17 april 2017 kl. 10:19:52 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > I might be able to speed up my bigintegers.4th
> 
> I wonder if you could run a test for me: let p = 17**250 + 2704
> (this number happens to be prime) and time how long it takes for
> your implementation to do a Fermat test: calculate (3**p) mod p
> which should be equal to 3.
> 
> My feeling is that if this takes less than a few seconds, your package
> is reasonably usable for public-key cryptography.

utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod utime d- d.
-4797000  ok
utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod~ utime d- d.
-547000  ok
.b

3
3  ok

With SP-Forth: 5 sec without Barret reduction and 0.5 seconds with Barret reduction. 

With GForth Android it takes about 18 sec without and 2 seconds with.

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

#57485

Den måndag 17 april 2017 kl. 11:06:14 UTC+2 skrev lehs:
> Den måndag 17 april 2017 kl. 10:19:52 UTC+2 skrev Paul Rubin:
> > lehs <skydda.barnen@gmail.com> writes:
> > > I might be able to speed up my bigintegers.4th
> > 
> > I wonder if you could run a test for me: let p = 17**250 + 2704
> > (this number happens to be prime) and time how long it takes for
> > your implementation to do a Fermat test: calculate (3**p) mod p
> > which should be equal to 3.
> > 
> > My feeling is that if this takes less than a few seconds, your package
> > is reasonably usable for public-key cryptography.
> 
> utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod utime d- d.
> -4797000  ok
> utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod~ utime d- d.
> -547000  ok
> .b
> 
> 3
> 3  ok
> 
> With SP-Forth: 5 sec without Barret reduction and 0.5 seconds with Barret reduction. 
> 
> With GForth Android it takes about 18 sec without and 2 seconds with.

With GForth 64 bit Windows:
utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod utime d- d. -4264661  ok
utime b 17 b 250 b** b 2704 b+ bthree bswap bdup b**mod~ utime d- d. -560484  ok
.b
3
3  ok

Win32Forth (stopwatch):
48 sec without and 5 sec with Barett reduction.

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

#57500

lehs <skydda.barnen@gmail.com> writes:
> With SP-Forth: 5 sec without Barret reduction and 0.5 seconds with
> Barret reduction.
> With GForth Android it takes about 18 sec without and 2 seconds with.

Wow, that's impressive for pure Forth.  Is SP-Forth on an x86?
I mostly wanted the time for just the b**mod but I guess 17**250+2704
didn't use much of the time.

Thanks!

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

#57503

Den måndag 17 april 2017 kl. 22:14:14 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > With SP-Forth: 5 sec without Barret reduction and 0.5 seconds with
> > Barret reduction.
> > With GForth Android it takes about 18 sec without and 2 seconds with.
> 
> Wow, that's impressive for pure Forth.  Is SP-Forth on an x86?
> I mostly wanted the time for just the b**mod but I guess 17**250+2704
> didn't use much of the time.
> 
> Thanks!

GForth Android runs on 1.6 GHz Rockchip RK3066
The others on 1.6 GHz Celeron
both dual core. 

I've no idea how to code public-key cryptography or why I would need it.


Lars-Erik Svahn
https://forthmath.blogspot.se
https://github.com/Lehs/ANS-Forth-libraries

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web