Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37940 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2015-04-04 12:02 -0700 |
| Last post | 2015-04-10 04:50 -0700 |
| Articles | 20 on this page of 92 — 12 participants |
Back to article view | Back to comp.lang.forth
Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-04 12:02 -0700
Re: Compiled Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-04 14:43 -1000
Re: Compiled Forth hughaguilar96@gmail.com - 2015-04-04 18:16 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 10:58 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 10:52 -0700
Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 15:35 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 08:51 -0700
Re: Compiled Forth mhx@iae.nl - 2015-04-06 15:32 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 16:28 -0700
Re: Compiled Forth mhx@iae.nl - 2015-04-08 13:58 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-08 14:41 -0700
Re: Compiled Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-08 14:01 -1000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 00:06 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:48 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 10:23 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 18:04 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 10:31 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-09 17:57 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 11:06 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-22 09:17 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 09:01 -0700
Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-05 09:32 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 11:02 -0700
Re: Compiled Forth "HAA" <someone@microsoft.com> - 2015-04-06 18:35 +1000
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-05 09:52 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 11:20 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 11:57 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 12:05 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 12:47 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 13:36 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 13:57 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 14:37 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 15:10 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 15:23 -0700
Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 08:52 +0300
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 23:09 -0700
Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 10:12 +0300
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 00:15 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 01:05 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 01:27 -0700
Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 12:20 +0000
Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 12:10 +0000
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 11:45 -0700
Re: Compiled Forth Melzzzzz <mel@zzzzz.com> - 2015-04-06 21:16 +0200
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 12:55 -0700
Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 09:01 +0100
Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 11:27 +0300
Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 08:06 +0100
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-06 14:15 +0000
Re: Compiled Forth stephen@mpeforth.com (Stephen Pelc) - 2015-04-06 11:32 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 08:01 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 12:04 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 12:58 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 13:29 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 16:44 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 19:59 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 01:31 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 01:36 -0700
Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-07 12:00 +0100
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 04:25 -0700
Proposal for ALLOCATEd bignum's Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-07 12:41 +0000
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-08 21:40 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 00:18 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-09 23:43 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:07 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:37 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:45 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 12:02 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 07:21 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 07:53 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 09:43 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:43 +0000
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 11:03 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 18:26 +0000
Re: Compiled Forth mhx@iae.nl - 2015-04-10 11:27 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 11:36 -0700
Re: Compiled Forth mhx@iae.nl - 2015-04-10 11:56 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 12:20 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 13:00 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 13:14 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 13:29 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 16:08 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 23:08 -0700
Re: Compiled Forth mhx@iae.nl - 2015-04-11 01:59 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 02:20 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 02:44 -0700
Re: Compiled Forth mhx@iae.nl - 2015-04-11 11:21 -0700
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-11 11:43 -0700
Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-11 19:44 +0000
Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-11 12:51 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 15:26 -0700
Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:50 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-07 12:41 +0000 |
| Subject | Proposal for ALLOCATEd bignum's Re: Compiled Forth |
| Message-ID | <5523d05d$0$21342$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38041 |
In article <b681ac8f-9b54-448f-b14f-3584492b4c92@googlegroups.com>, lehs <skydda.barnen@gmail.com> wrote: >Den tisdag 7 april 2015 kl. 13:00:23 UTC+2 skrev Jan Coombs: >> On Tue, 7 Apr 2015 01:31:11 -0700 (PDT) >> lehs <skydda.barnen@gmail.com> wrote: >> >> > My goal is to make a simple and efficient system, as much >> > as possible in Forth-style. I think some minor deviations >> > from the norm is necessary, like B= and B. BDROP is just >> > a change of references, but BOVER BOVER (to make temporary >> > copies to be eaten by a comparison routine) does two CMOVE. >> >> With some extra tagging you can just copy the pointer to do >> BOVER. The tag (reference count +?) lets you know when the >> bignum storage is free, and warns you to not over-write it >> if it has more than one reference. >> >> Interesingly, increment-in-place should work for loop counters >> where the loop termination detection is sign change, because >> the number size is only reducing. >> >> If you really need B= ( b1 b2 -- b1 b2 flag ) then, to keep >> sympathy, call it 2DUP_B= or something similar. >> >> If you do just copy pointers, and manage data refs, then the >> code >> >> B2DUP B= >> >> is quick to execute, no data copying, and looks standard. >> >> Jan Coombs. >> -- >> email valid, else fix dots and hyphen >> jan4clf2014@murrayhyphenmicroftdotcodotuk > >Yes, you are right, I should point out when comparing don't eat numbers >somehow, perhaps B|= or B^= This is not to my liking. let's have something different. Because it is different I call it great numbers. The following proposal has a one cell handle for great numbers. So the previous example becomes: 2DUP G= Because the great numbers reside on the regular stack while handled, it is much more Forth like and intuitive. \ ------------------------------------------------------------- INTRODUCTION The greatnums have hassle free allocation and garbage collection. They are called great numbers, because B is taken for binary and other bignum packages. In fact, if used as a calculator, one never has to worry about allocating and freeing. As a compensation for the code expended, the code for handling doubles and floating point numbers is simplified, further extension of the precision of floating point numbers come for almost free. DATA STRUCTURE A G-constant (handle) occupies one cell on the stack. This is an allocation pointer that can be FREE -ed. Because this is one cell DUP OVER @ ! can be used as usual. GLOSSARY G+ G- G* G/ GMOD g** ( g g' -- g'') G/MOD ( g g' -- g'' g''') These are the usual operations. (The inputs g and g' are not affected but they are no longer on the stack. If they are also otherwise inaccessible, they can be FREE-ed) A new area is ALLOCATEd to store any results. G+:= G-:= G*:= ( g n -- g' ) G<<:= G>>:= G/MOD:= ( g u -- u' g' ) These mixed mode operations are in place if possible, so g' may be the same handle as g, hence the := Special use/ special care/internal.. GDUP a (deep) copy of the g-word using ALLOCATE GDUP NIP is an idiom to prevent corrupting constant g-numbers. g0= ( g -- f) g< ( g1 g2 -- f) @ ! GVARIABLE This works the same as VARIABLE Great numbers must be stored in GVARIABLE 's only or in GVARIABLE compatible fields in a struct/class created by BUILD-G For things like numerical calculation we also have: The same but modulo the g-number in G-VARIABLE `` _m_ ''. G+m G-m G*m g**m ( g g' -- g'') The garbage collection is then automatic. G-NUMBER DENOTATION A word with at least one &' starting with a digit or sign and containing only digits &. &, and &' and is interpreted is interpreted as a great number. The g-constant is calculated and allocated and remains on the stack or is compiled. . BASE is observed. \ ------------------------------------------------------------- Implementation details (need not be followed) G-numbers have a pointer past its content in the preceding cell. They start with the least significant cell. This is compatible with some (ciforth's) ALLOCATE package. The last cell is either zero (pos) or -1 (neg). They are to be normalized when last and previous cells differ. In this way single precision operations can always be performed, then normalized later on. (permission, not forgiveness.) Handles are linked, or on the stack. This way they can be freed if need be. Compiled g-numbers are of course likewise protected from freeing. GVARIABLE are linked among themselves, and BUILD-G must be used in ARRAYS, and FIELDS of structs or classes. Garbage collection: The allocation package must allow to identify whether a pointer is in the G-area. A list is made of handles from GVARIABLE's and from the numbers on both stacks that point in the allocation area. The allocation space is scanned and all great numbers that are not pointed to or into are freed. This may benefit from an allocate that is an object, i.e. different allocation area's can be selected. The ciforth allocation fits the bill, and its 20 lines would not burden the package much. To get rid of an area with G-numbers, either compiled or in G-VARIABLE's a provision must be added to MARKER. Note Handles that are dropped from the stack are not freed. So you can do ( Return both the square and the cube) ( g -- g*g g*g*g ) : test >R R@ R@ G* DUP R> G* ; The handle to the original g and the one to g^2 just remain valid. The tight connection with the allocation may allow inlining and optimisation to a greater extend than external c-packages would. Example : pi 355' 113' ; : *p pi >R G* R> G/ ; (NUMBER) is modified as follows: [ (NUMBER) is the word executed by e.g. $ to parse the remaining word.] The Forth philosophy has always been to parse for the worst case (doubles) then trim. With great numbers integrated, (NUMBER) has to parse for great numbers. Assuming we replace the E in the exponent of f.p. numbers by _ 1] (NUMBER) would leave 1 or 2 great numbers and information whether we have a float, single, double or great. 2] This results in a (NUMBER) that is a straightforward generalisation of the current (NUMBER). > >Since I do believe that copying isn't that bad I will finish what I'm >doing and then perhaps try to make a fourth reorganization with pointers >and GC - and compare. > >To make it possible to write faster code when needed, I will try to make >some words that acts on given addresses, as a complement. That would be great, to have the calculation words work on a defined data structure, separating out all the memory hassle. Groetjes Albert 1] E is a design fault, as E is also a hex digit, blocking hex f.p. numbers forever. 2] I detest the ad hoc "recognizers" Look what happens if intel decides to increase the precision of floating point numbers once more. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-08 21:40 -0700 |
| Message-ID | <87oamxewx3.fsf@jester.gateway.sonic.net> |
| In reply to | #38041 |
lehs <skydda.barnen@gmail.com> writes: > Since I do believe that copying isn't that bad I will finish what I'm > doing and then perhaps try to make a fourth reorganization with > pointers and GC - and compare. Copying might be ok with your stack scheme, but there's still the issue of dealing with numbers that aren't on a stack, e.g. in variables. Maybe you get a situation where the application pushes all its stuff on the stack and then uses BPICK a lot. That sounds ugly.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-09 00:18 -0700 |
| Message-ID | <d6dab7ad-08ea-45d0-8bf3-e865a64b2dcb@googlegroups.com> |
| In reply to | #38062 |
Den torsdag 9 april 2015 kl. 06:40:58 UTC+2 skrev Paul Rubin: > lehs <skydda.barnen@gmail.com> writes: > > Since I do believe that copying isn't that bad I will finish what I'm > > doing and then perhaps try to make a fourth reorganization with > > pointers and GC - and compare. > > Copying might be ok with your stack scheme, but there's still the issue > of dealing with numbers that aren't on a stack, e.g. in variables. > Maybe you get a situation where the application pushes all its stuff > on the stack and then uses BPICK a lot. That sounds ugly. Fast variables is a problem since I would like to avoid to have to decide the maximal number. Only the allocated memory for the big stack should be the limit. As it is, there is a special stack for references that normally refers to a stack oriented buffer of arrays. But I try to make it possible to put references on the ref stack, that refer to buffers outside the array buffer. As it is now, I use an extra big stack in which the top numbers can be accessed by X, Y and Z. I don't have BPICK and rarely use PICK.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-09 23:43 -0700 |
| Message-ID | <87pp7ccwk8.fsf@jester.gateway.sonic.net> |
| In reply to | #38037 |
lehs <skydda.barnen@gmail.com> writes: > B 16357961957638769631974563151376597136591375613975613 B**MOD > instantly (with my system in 4/100 second) gives > 6639276191969705355236646500004312964523609080804143 I'd be interested to know the speed of B**MOD when all 3 args are 308 decimal digits (1024 bits), if you feel like giving that a try.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 04:07 -0700 |
| Message-ID | <0d06f1ae-1002-483f-a9ac-5874dec4f839@googlegroups.com> |
| In reply to | #38074 |
Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > lehs <skydda.barnen@gmail.com> writes: > > B 16357961957638769631974563151376597136591375613975613 B**MOD > > instantly (with my system in 4/100 second) gives > > 6639276191969705355236646500004312964523609080804143 > > I'd be interested to know the speed of B**MOD when all 3 args are 308 > decimal digits (1024 bits), if you feel like giving that a try. Using these numbers 2635978399155107087196520197908033325403874364674615837958219203805584279114683350674597866630967871023874626232566540744804711285861422118412002377472885092770174578207797994316543435577699344780915516350630428794948478622904300719336909786568144564372000438734587280000895050231248226812216070815516032856443 3932737519146704864752101884173034899859865152237270815867069189242006053189065553399146139855069632472235192561744832434408314148466195139282080047994768504279154974874356426808195808024613272317458123296906266199055697217686179234190542525238256269768612741325920190414486748227955276062439474204059085560271 1630667563093978462650280716142561221234013110993246032223857659061097654923543250376416659033855708665130269244620493705388605795400303281480164823066889475386315010802957096633769693956056510131281527380354755561902932558381556576716884183614351123751200602363035259054014063862083809434458321584089326555047 B**MOD was executed on 2808 milliseconds with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 04:37 -0700 |
| Message-ID | <78894795-abdd-4d14-9f93-c20e5f0f3d44@googlegroups.com> |
| In reply to | #38076 |
Den fredag 10 april 2015 kl. 13:07:59 UTC+2 skrev lehs: > Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > > lehs <skydda.barnen@gmail.com> writes: > > > B 16357961957638769631974563151376597136591375613975613 B**MOD > > > instantly (with my system in 4/100 second) gives > > > 6639276191969705355236646500004312964523609080804143 > > > > I'd be interested to know the speed of B**MOD when all 3 args are 308 > > decimal digits (1024 bits), if you feel like giving that a try. > > Using these numbers > > 2635978399155107087196520197908033325403874364674615837958219203805584279114683350674597866630967871023874626232566540744804711285861422118412002377472885092770174578207797994316543435577699344780915516350630428794948478622904300719336909786568144564372000438734587280000895050231248226812216070815516032856443 > > 3932737519146704864752101884173034899859865152237270815867069189242006053189065553399146139855069632472235192561744832434408314148466195139282080047994768504279154974874356426808195808024613272317458123296906266199055697217686179234190542525238256269768612741325920190414486748227955276062439474204059085560271 > > 1630667563093978462650280716142561221234013110993246032223857659061097654923543250376416659033855708665130269244620493705388605795400303281480164823066889475386315010802957096633769693956056510131281527380354755561902932558381556576716884183614351123751200602363035259054014063862083809434458321584089326555047 > > B**MOD was executed on 2808 milliseconds with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz. The 3 numbers are 310 digits long...
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 04:45 -0700 |
| Message-ID | <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com> |
| In reply to | #38074 |
Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > lehs <skydda.barnen@gmail.com> writes: > > B 16357961957638769631974563151376597136591375613975613 B**MOD > > instantly (with my system in 4/100 second) gives > > 6639276191969705355236646500004312964523609080804143 > > I'd be interested to know the speed of B**MOD when all 3 args are 308 > decimal digits (1024 bits), if you feel like giving that a try. Using these 3 308-digit numbers 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 B**MOD executes in 2408 ms with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-10 12:02 +0000 |
| Message-ID | <5527bbe7$0$23274$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #38079 |
In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, lehs <skydda.barnen@gmail.com> wrote: >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: >> lehs <skydda.barnen@gmail.com> writes: >> > B 16357961957638769631974563151376597136591375613975613 B**MOD >> > instantly (with my system in 4/100 second) gives >> > 6639276191969705355236646500004312964523609080804143 >> >> I'd be interested to know the speed of B**MOD when all 3 args are 308 >> decimal digits (1024 bits), if you feel like giving that a try. >Using these 3 308-digit numbers > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz. I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses BD-strings (max 255 char). With NAME I get: 3453.015mS RESULT IS : 313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. 117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. 929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. 598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. 544.400.603.835.158.936.934.589.782.704.448 This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz (not the usual 2.8 Ghz) The interesting thing is of course, is the answer correct? Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 07:21 -0700 |
| Message-ID | <cf288f57-62fa-4a97-a748-d5d9c0897ffd@googlegroups.com> |
| In reply to | #38081 |
Den fredag 10 april 2015 kl. 14:02:51 UTC+2 skrev Albert van der Horst: > In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, > lehs <skydda.barnen@gmail.com> wrote: > >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > >> lehs <skydda.barnen@gmail.com> writes: > >> > B 16357961957638769631974563151376597136591375613975613 B**MOD > >> > instantly (with my system in 4/100 second) gives > >> > 6639276191969705355236646500004312964523609080804143 > >> > >> I'd be interested to know the speed of B**MOD when all 3 args are 308 > >> decimal digits (1024 bits), if you feel like giving that a try. > >Using these 3 308-digit numbers > > > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > > > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > > > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > > > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz. > > I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses BD-strings (max 255 char). > With NAME I get: > > 3453.015mS > RESULT IS : > 313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. > 117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. > 929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. > 598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. > 544.400.603.835.158.936.934.589.782.704.448 > > This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz (not the usual 2.8 Ghz) > > The interesting thing is of course, is the answer correct? > > Groetjes Albert > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- being exponential -- ultimately falters. > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst This is what I got: B 2635978399155107087196520197908033325403874364674615837958219203805584279114683 3506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 Ok B 3932737519146704864752101884173034899859865152237270815867069189242006053189065 5533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 Ok B 1630667563093978462650280716142561221234013110993246032223857659061097654923543 2503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 Ok WINAPI: GetTickCount KERNEL32.DLL Ok : ms@ GetTickCount >x ; Ok : ms-@ GetTickCount x> - ; Ok ms@ B**MOD ms-@ Ok ( 2480 ) .B 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 Ok ( 2480 )
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 07:53 -0700 |
| Message-ID | <c9ce51b1-6bda-4e42-868b-adeaa1d5726a@googlegroups.com> |
| In reply to | #38082 |
Den fredag 10 april 2015 kl. 16:21:17 UTC+2 skrev lehs: > Den fredag 10 april 2015 kl. 14:02:51 UTC+2 skrev Albert van der Horst: > > In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, > > lehs <skydda.barnen@gmail.com> wrote: > > >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > > >> lehs <skydda.barnen@gmail.com> writes: > > >> > B 16357961957638769631974563151376597136591375613975613 B**MOD > > >> > instantly (with my system in 4/100 second) gives > > >> > 6639276191969705355236646500004312964523609080804143 > > >> > > >> I'd be interested to know the speed of B**MOD when all 3 args are 308 > > >> decimal digits (1024 bits), if you feel like giving that a try. > > >Using these 3 308-digit numbers > > > > > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > > > > > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > > > > > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > > > > > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz. > > > > I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses BD-strings (max 255 char). > > With NAME I get: > > > > 3453.015mS > > RESULT IS : > > 313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. > > 117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. > > 929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. > > 598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. > > 544.400.603.835.158.936.934.589.782.704.448 > > > > This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz (not the usual 2.8 Ghz) > > > > The interesting thing is of course, is the answer correct? > > > > Groetjes Albert > > -- > > Albert van der Horst, UTRECHT,THE NETHERLANDS > > Economic growth -- being exponential -- ultimately falters. > > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst > > This is what I got: > > B 2635978399155107087196520197908033325403874364674615837958219203805584279114683 > 3506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > Ok > B 3932737519146704864752101884173034899859865152237270815867069189242006053189065 > 5533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > Ok > B 1630667563093978462650280716142561221234013110993246032223857659061097654923543 > 2503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > Ok > WINAPI: GetTickCount KERNEL32.DLL > Ok > : ms@ GetTickCount >x ; > Ok > : ms-@ GetTickCount x> - ; > Ok > ms@ B**MOD ms-@ > Ok ( 2480 ) > .B > > 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 Ok ( 2480 ) In SwiftForth I got an other result: B 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 ok B 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 ok B 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 ok .B 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 ok B**MOD ok .B 6164511614246874283751004411521304790382644718314982336317131632437547740223086593203443688686011413186557365155469772371429302516730050574311828757730690825631449505769257777247130164321675394250263022168108781200260389793260215594090691938981795234504 ok So there is some debugging left...
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 09:43 -0700 |
| Message-ID | <368e28a4-9c55-43af-87fe-46148f8c77d0@googlegroups.com> |
| In reply to | #38083 |
Den fredag 10 april 2015 kl. 16:53:18 UTC+2 skrev lehs: > Den fredag 10 april 2015 kl. 16:21:17 UTC+2 skrev lehs: > > Den fredag 10 april 2015 kl. 14:02:51 UTC+2 skrev Albert van der Horst: > > > In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, > > > lehs <skydda.barnen@gmail.com> wrote: > > > >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > > > >> lehs <skydda.barnen@gmail.com> writes: > > > >> > B 16357961957638769631974563151376597136591375613975613 B**MOD > > > >> > instantly (with my system in 4/100 second) gives > > > >> > 6639276191969705355236646500004312964523609080804143 > > > >> > > > >> I'd be interested to know the speed of B**MOD when all 3 args are 308 > > > >> decimal digits (1024 bits), if you feel like giving that a try. > > > >Using these 3 308-digit numbers > > > > > > > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > > > > > > > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > > > > > > > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > > > > > > > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop with Celeron 900 @ 2.20 GHz. > > > > > > I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses BD-strings (max 255 char). > > > With NAME I get: > > > > > > 3453.015mS > > > RESULT IS : > > > 313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. > > > 117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. > > > 929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. > > > 598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. > > > 544.400.603.835.158.936.934.589.782.704.448 > > > > > > This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz (not the usual 2.8 Ghz) > > > > > > The interesting thing is of course, is the answer correct? > > > > > > Groetjes Albert > > > -- > > > Albert van der Horst, UTRECHT,THE NETHERLANDS > > > Economic growth -- being exponential -- ultimately falters. > > > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst > > > > This is what I got: > > > > B 2635978399155107087196520197908033325403874364674615837958219203805584279114683 > > 3506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > > Ok > > B 3932737519146704864752101884173034899859865152237270815867069189242006053189065 > > 5533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > > Ok > > B 1630667563093978462650280716142561221234013110993246032223857659061097654923543 > > 2503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > > Ok > > WINAPI: GetTickCount KERNEL32.DLL > > Ok > > : ms@ GetTickCount >x ; > > Ok > > : ms-@ GetTickCount x> - ; > > Ok > > ms@ B**MOD ms-@ > > Ok ( 2480 ) > > .B > > > > 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 Ok ( 2480 ) > > In SwiftForth I got an other result: > > B 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 > ok > B 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 > ok > B 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 > ok > .B > 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 > 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 > 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 > ok > B**MOD ok > .B > 6164511614246874283751004411521304790382644718314982336317131632437547740223086593203443688686011413186557365155469772371429302516730050574311828757730690825631449505769257777247130164321675394250263022168108781200260389793260215594090691938981795234504 ok > > So there is some debugging left... The differences of the results seems to emanate only from that SwiftForth maximum takes 253 digits when using B 123... I have tested B**MOD vs B** BMOD but only with rather small exponents of course.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-10 16:43 +0000 |
| Message-ID | <5527fdc6$0$3035$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38083 |
In article <c9ce51b1-6bda-4e42-868b-adeaa1d5726a@googlegroups.com>, lehs <skydda.barnen@gmail.com> wrote: >Den fredag 10 april 2015 kl. 16:21:17 UTC+2 skrev lehs: >> Den fredag 10 april 2015 kl. 14:02:51 UTC+2 skrev Albert van der Horst: >> > In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, >> > lehs <skydda.barnen@gmail.com> wrote: >> > >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: >> > >> lehs <skydda.barnen@gmail.com> writes: >> > >> > B 16357961957638769631974563151376597136591375613975613 B**MOD >> > >> > instantly (with my system in 4/100 second) gives >> > >> > 6639276191969705355236646500004312964523609080804143 >> > >> >> > >> I'd be interested to know the speed of B**MOD when all 3 args are 308 >> > >> decimal digits (1024 bits), if you feel like giving that a try. >> > >Using these 3 308-digit numbers >> > > >> > >>26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 >> > > >> > >>39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 >> > > >> > >>16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 >> > > >> > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop >with Celeron 900 @ 2.20 GHz. >> > >> > I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses >BD-strings (max 255 char). >> > With NAME I get: >> > >> > 3453.015mS >> > RESULT IS : >> > >313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. >> > >117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. >> > >929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. >> > >598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. >> > 544.400.603.835.158.936.934.589.782.704.448 >> > >> > This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz >(not the usual 2.8 Ghz) >> > >> > The interesting thing is of course, is the answer correct? >> > >> > Groetjes Albert >> > -- >> > Albert van der Horst, UTRECHT,THE NETHERLANDS >> > Economic growth -- being exponential -- ultimately falters. >> > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst >> >> This is what I got: >> >> B >2635978399155107087196520197908033325403874364674615837958219203805584279114683 >> >3506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 >> Ok >> B >3932737519146704864752101884173034899859865152237270815867069189242006053189065 >> >5533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 >> Ok >> B >1630667563093978462650280716142561221234013110993246032223857659061097654923543 >> >2503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 >> Ok >> WINAPI: GetTickCount KERNEL32.DLL >> Ok >> : ms@ GetTickCount >x ; >> Ok >> : ms-@ GetTickCount x> - ; >> Ok >> ms@ B**MOD ms-@ >> Ok ( 2480 ) >> .B >> >> >13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 Ok >( 2480 ) > >In SwiftForth I got an other result: > >B >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 > ok >B >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 > ok >B >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 > ok >.B >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 >ok >B**MOD ok >.B >6164511614246874283751004411521304790382644718314982336317131632437547740223086593203443688686011413186557365155469772371429302516730050574311828757730690825631449505769257777247130164321675394250263022168108781200260389793260215594090691938981795234504 ok > >So there is some debugging left... I tested it against dc. This is what you input to dc: " 26... 39... 16... | p " dc lina32 and lina64 agree, so I'm pretty confident. (3 lemmings can't be wrong ;-) ) dc and lina64 are about equal in speed. lina32 is three times slower. One debugging tip. Use powers of 10. As far as the 64-bit cell arithmetic is concerned they are pretty random. If that succeeds, you can go from there. Groetjes Albert P.S. This is the output of dc 313531591570378525159683302750429832805980888047238962624106181706419\ 117597498228494994842718297832365229151023618127686311459766025230427\ 929967496348492093649454115996379235861089754170139781276166856611459\ 598949394683616460024537055883149308159311660870526121354700944460134\ 544400603835158936934589782704448 -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 11:03 -0700 |
| Message-ID | <5a4361f7-b1d6-4d31-bc15-732455d770d6@googlegroups.com> |
| In reply to | #38090 |
Den fredag 10 april 2015 kl. 18:44:06 UTC+2 skrev Albert van der Horst: > In article <c9ce51b1-6bda-4e42-868b-adeaa1d5726a@googlegroups.com>, > lehs <skydda.barnen@gmail.com> wrote: > >Den fredag 10 april 2015 kl. 16:21:17 UTC+2 skrev lehs: > >> Den fredag 10 april 2015 kl. 14:02:51 UTC+2 skrev Albert van der Horst: > >> > In article <3fa3c4ff-5839-49ca-aa96-1b84038ebfe7@googlegroups.com>, > >> > lehs <skydda.barnen@gmail.com> wrote: > >> > >Den fredag 10 april 2015 kl. 08:43:52 UTC+2 skrev Paul Rubin: > >> > >> lehs <skydda.barnen@gmail.com> writes: > >> > >> > B 16357961957638769631974563151376597136591375613975613 B**MOD > >> > >> > instantly (with my system in 4/100 second) gives > >> > >> > 6639276191969705355236646500004312964523609080804143 > >> > >> > >> > >> I'd be interested to know the speed of B**MOD when all 3 args are 308 > >> > >> decimal digits (1024 bits), if you feel like giving that a try. > >> > >Using these 3 308-digit numbers > >> > > > >> > > >>26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > >> > > > >> > > >>39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > >> > > > >> > > >>16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > >> > > > >> > >B**MOD executes in 2408 ms with optimized SP-Forth on my laptop > >with Celeron 900 @ 2.20 GHz. > >> > > >> > I couldn't use an unchanged BIGNUM.FRT because the BL WORD uses > >BD-strings (max 255 char). > >> > With NAME I get: > >> > > >> > 3453.015mS > >> > RESULT IS : > >> > > >313.531.591.570.378.525.159.683.302.750.429.832.805.980.888.047.238.962.624.106.181.706.419. > >> > > >117.597.498.228.494.994.842.718.297.832.365.229.151.023.618.127.686.311.459.766.025.230.427. > >> > > >929.967.496.348.492.093.649.454.115.996.379.235.861.089.754.170.139.781.276.166.856.611.459. > >> > > >598.949.394.683.616.460.024.537.055.883.149.308.159.311.660.870.526.121.354.700.944.460.134. > >> > 544.400.603.835.158.936.934.589.782.704.448 > >> > > >> > This is ciforth, no optimisation running on my AMD 64 bit, 1 Ghz > >(not the usual 2.8 Ghz) > >> > > >> > The interesting thing is of course, is the answer correct? > >> > > >> > Groetjes Albert > >> > -- > >> > Albert van der Horst, UTRECHT,THE NETHERLANDS > >> > Economic growth -- being exponential -- ultimately falters. > >> > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst > >> > >> This is what I got: > >> > >> B > >2635978399155107087196520197908033325403874364674615837958219203805584279114683 > >> > >3506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564 > >> Ok > >> B > >3932737519146704864752101884173034899859865152237270815867069189242006053189065 > >> > >5533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602 > >> Ok > >> B > >1630667563093978462650280716142561221234013110993246032223857659061097654923543 > >> > >2503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550 > >> Ok > >> WINAPI: GetTickCount KERNEL32.DLL > >> Ok > >> : ms@ GetTickCount >x ; > >> Ok > >> : ms-@ GetTickCount x> - ; > >> Ok > >> ms@ B**MOD ms-@ > >> Ok ( 2480 ) > >> .B > >> > >> > >13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 Ok > >( 2480 ) > > > >In SwiftForth I got an other result: > > > >B > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 > > ok > >B > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 > > ok > >B > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 > > ok > >.B > >16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512 > >39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686 > >26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720 > >ok > >B**MOD ok > >.B > >6164511614246874283751004411521304790382644718314982336317131632437547740223086593203443688686011413186557365155469772371429302516730050574311828757730690825631449505769257777247130164321675394250263022168108781200260389793260215594090691938981795234504 ok > > > >So there is some debugging left... > > I tested it against dc. > This is what you input to dc: > " > 26... > 39... > 16... > | > p > " > > dc lina32 and lina64 agree, so I'm pretty confident. > (3 lemmings can't be wrong ;-) ) > > dc and lina64 are about equal in speed. lina32 is three times slower. > > One debugging tip. Use powers of 10. As far as the 64-bit cell arithmetic > is concerned they are pretty random. If that succeeds, you can go from there. > > > Groetjes Albert > > P.S. > This is the output of dc > > 313531591570378525159683302750429832805980888047238962624106181706419\ > 117597498228494994842718297832365229151023618127686311459766025230427\ > 929967496348492093649454115996379235861089754170139781276166856611459\ > 598949394683616460024537055883149308159311660870526121354700944460134\ > 544400603835158936934589782704448 > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- being exponential -- ultimately falters. > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst It's astonishing, but the result from your test is 309 digits long, while the numbers are 308 digits long. I'm pretty sure that you used the three 310 digit numbers I published in a deleted post and then commented the post with 308 digit numbers. For those numbers my B**MOD used just above 3 seconds. Do you still have those numbers left? I would like to test them and see the result. The first 308 digits are the same because I just erased two digits.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-10 18:26 +0000 |
| Message-ID | <552815c8$0$3052$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38093 |
In article <5a4361f7-b1d6-4d31-bc15-732455d770d6@googlegroups.com>, lehs <skydda.barnen@gmail.com> wrote: <SNIP> >> >> > >> >> > The interesting thing is of course, is the answer correct? <SNIP> >It's astonishing, but the result from your test is 309 digits long, >while the numbers are 308 digits long. > >I'm pretty sure that you used the three 310 digit numbers I published in >a deleted post and then commented the post with 308 digit numbers. For >those numbers my B**MOD used just above 3 seconds. > >Do you still have those numbers left? I would like to test them and see >the result. The first 308 digits are the same because I just erased two >digits. Just add 43 71 47 With those digits erased, dc confirms one of your published results. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-04-10 11:27 -0700 |
| Message-ID | <eed254ab-aeae-4d14-b042-93fd902ef8b0@googlegroups.com> |
| In reply to | #38093 |
On Friday, April 10, 2015 at 8:03:49 PM UTC+2, lehs wrote: [..] CR S" 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564" s1 >giant S" 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602" s2 >giant S" 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550" s3 >giant TIMER-RESET s1 s2 s3 GG^MOD .ELAPSED s1 CR .GIANT 0.057 seconds elapsed. 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 ok On iForth64, with one of its three bignum packages (result may be inaccurate because the processor is normally in powersaving sleep when I visit this chat room). -marcel
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 11:36 -0700 |
| Message-ID | <4b631b6e-7064-4b34-b400-ffce928398fb@googlegroups.com> |
| In reply to | #38096 |
Den fredag 10 april 2015 kl. 20:27:16 UTC+2 skrev m...@iae.nl: > On Friday, April 10, 2015 at 8:03:49 PM UTC+2, lehs wrote: > [..] > CR > S" 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564" s1 >giant > S" 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602" s2 >giant > S" 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550" s3 >giant > TIMER-RESET s1 s2 s3 GG^MOD .ELAPSED s1 CR .GIANT > > 0.057 seconds elapsed. > 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 ok > > On iForth64, with one of its three bignum packages (result may > be inaccurate because the processor is normally in powersaving > sleep when I visit this chat room). > > -marcel It looks like all the calculations are correct. What processor did you use? How much faster is it than my Celeron 900 2.20 GHz?
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-04-10 11:56 -0700 |
| Message-ID | <7b0009cd-5f8c-41ab-855e-35e917490581@googlegroups.com> |
| In reply to | #38097 |
On Friday, April 10, 2015 at 8:36:42 PM UTC+2, lehs wrote: > Den fredag 10 april 2015 kl. 20:27:16 UTC+2 skrev m...@iae.nl: > > On Friday, April 10, 2015 at 8:03:49 PM UTC+2, lehs wrote: > > [..] > > CR > > S" 26359783991551070871965201979080333254038743646746158379582192038055842791146833506745978666309678710238746262325665407448047112858614221184120023774728850927701745782077979943165434355776993447809155163506304287949484786229043007193369097865681445643720004387345872800008950502312482268122160708155160328564" s1 >giant > > S" 39327375191467048647521018841730348998598651522372708158670691892420060531890655533991461398550696324722351925617448324344083141484661951392820800479947685042791549748743564268081958080246132723174581232969062661990556972176861792341905425252382562697686127413259201904144867482279552760624394742040590855602" s2 >giant > > S" 16306675630939784626502807161425612212340131109932460322238576590610976549235432503764166590338557086651302692446204937053886057954003032814801648230668894753863150108029570966337696939560565101312815273803547555619029325583815565767168841836143511237512006023630352590540140638620838094344583215840893265550" s3 >giant > > TIMER-RESET s1 s2 s3 GG^MOD .ELAPSED s1 CR .GIANT > > > > 0.057 seconds elapsed. > > 13589152355661418800480923196880892958242540305591911682228289531245831992616543540153046075650497423341388067834762342417455873016510076223412593080539625696104324076486611754715629613440368922879919737699812253207474005960378943204378352266794545844684513362891786202126506784931492440650088987888029494246 ok > > > > On iForth64, with one of its three bignum packages (result may > > be inaccurate because the processor is normally in powersaving > > sleep when I visit this chat room). > > > > -marcel > > It looks like all the calculations are correct. > What processor did you use? How much faster is it than my Celeron 900 2.20 GHz? i7-4930 @ 3.4 GHz. 'How much faster than' is a very difficult question. BTW, out of curiosity I switched from 'power save' to high-performance' mode and the run-time went from 57 ms to 18 ms. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-10 12:20 -0700 |
| Message-ID | <87lhhzdc3k.fsf@jester.gateway.sonic.net> |
| In reply to | #38097 |
lehs <skydda.barnen@gmail.com> writes: > It looks like all the calculations are correct. > What processor did you use? How much faster is it than my Celeron 900 > 2.20 GHz? I expect Marcel is using native-code compilation and maybe better algorithms. That will make a much bigger difference than more cpu speed. His cpu is maybe 2x faster at best (higher clock rate plus some architectural tweaks). OpenSSL on a 3.4 ghz i7-3770 takes about 0.5 msec for a 1024 bit modexp and that's probably close to optimum, short of using a GPU etc.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-10 13:00 -0700 |
| Message-ID | <70f8e0cf-61b0-4a82-a745-abfdfbd6af69@googlegroups.com> |
| In reply to | #38099 |
Den fredag 10 april 2015 kl. 21:20:32 UTC+2 skrev Paul Rubin: > lehs <skydda.barnen@gmail.com> writes: > > It looks like all the calculations are correct. > > What processor did you use? How much faster is it than my Celeron 900 > > 2.20 GHz? > > I expect Marcel is using native-code compilation and maybe better > algorithms. That will make a much bigger difference than more cpu > speed. His cpu is maybe 2x faster at best (higher clock rate plus some > architectural tweaks). OpenSSL on a 3.4 ghz i7-3770 takes about 0.5 > msec for a 1024 bit modexp and that's probably close to optimum, short > of using a GPU etc. I'm sure Marscel's is using better algorithms than mine. For example am I using "schoolbook" version of multiplication and since B**MOD mostly is built up by B* and BMOD, and BMOD mostly is built up by B* - so a faster B* could make some difference. I'm also sure that a modern multicore 64-bit system is more than twice times faster than my 32-bit single core Celeron. What really interests me is if my approach with block moving stack manipulation is comparable with professional solutions. Since my "bad" algorithms probably are responsible for the most slowness - the system might not be so bad.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-10 13:14 -0700 |
| Message-ID | <878udzd9lq.fsf@jester.gateway.sonic.net> |
| In reply to | #38102 |
lehs <skydda.barnen@gmail.com> writes: > I'm also sure that a modern multicore 64-bit system is more than twice > times faster than my 32-bit single core Celeron. I'd expect Marcel tested on a single core, so multicore isn't an issue. What is the model number of your Celeron? You can look at cpubenchmark.net for general speed comparison, though for specific operations like arithmetic the benchmark numbers may not mean much. 64 bits does make a big difference. In 32-bit mode on a 2.67GHz Xeon X5650 (older box), I get around 3 msec for that modexp. On an ARM v7 (don't know clock speed, maybe 1 ghz?) I get around 16 msec. You can visit instantcloud.io and use a dedicated quad core ARM server at no charge for 30 minutes if that's of any interest--that's what I used for that test. They rent them for 10 euro a month so the 30 minute thing is a tryout. > What really interests me is if my approach with block moving stack > manipulation is comparable with professional solutions. Since my "bad" > algorithms probably are responsible for the most slowness - the system > might not be so bad. Hard to say, there are a lot of variables. Maybe some profiling is possible. Can you get the program to work with gforth?
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web