Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #17453 > unrolled thread
| Started by | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| First post | 2012-11-20 22:32 -0800 |
| Last post | 2012-12-07 14:27 -0800 |
| Articles | 20 on this page of 79 — 14 participants |
Back to article view | Back to comp.lang.forth
ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-20 22:32 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-22 22:53 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth ritaoakford@gmail.com - 2012-11-23 00:21 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-23 14:20 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth mhx@iae.nl (Marcel Hendrix) - 2012-11-25 22:58 +0200
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-11-25 14:41 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth mhx@iae.nl (Marcel Hendrix) - 2012-11-26 00:59 +0200
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-11-25 16:10 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-26 04:18 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-26 19:17 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-26 11:57 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-26 06:17 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth mhx@iae.nl (Marcel Hendrix) - 2012-11-26 23:22 +0200
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-27 13:33 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-27 09:18 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Mark Wills <forthfreak@gmail.com> - 2012-11-27 01:08 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-27 11:18 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-27 16:32 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-28 11:59 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-28 14:11 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 16:50 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-27 13:36 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-28 14:31 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-28 14:36 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-11-30 00:08 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-11-30 13:56 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-12-01 16:02 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-01 13:54 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Josh Grams <josh@qualdan.com> - 2012-12-02 11:26 +0000
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-12 14:52 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-12 23:47 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 00:38 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-13 20:17 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 20:25 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-13 20:53 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-13 21:16 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-14 03:43 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:15 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-20 00:21 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 04:45 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Howerd <howerdo@yahoo.co.uk> - 2012-12-14 03:33 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:20 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-14 10:28 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-14 12:39 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-15 01:47 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-19 18:10 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-19 19:53 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-20 14:44 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-20 19:28 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-20 13:56 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-21 01:41 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 03:58 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-21 02:20 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 06:46 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-21 15:34 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 08:40 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-22 03:36 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-21 20:07 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 02:37 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-22 19:24 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 15:52 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-23 17:52 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-24 03:57 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-24 16:20 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-24 15:36 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-25 02:52 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-24 21:51 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-25 20:56 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Paul Rubin <no.email@nospam.invalid> - 2012-12-26 01:08 -0800
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-26 16:02 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth David Thompson <dave.thompson2@verizon.net> - 2012-12-31 02:48 -0500
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth kenney@cix.compulink.co.uk - 2012-12-24 03:20 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-22 03:24 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 01:24 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-23 04:59 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-23 17:32 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-23 11:28 -0600
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-24 00:30 +0100
Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth jzakiya@gmail.com - 2012-12-07 14:27 -0800
Page 1 of 4 [1] 2 3 4 Next page →
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2012-11-20 22:32 -0800 |
| Subject | ANN: SHA-256 Secure Hash Algorithm in ANS Forth |
| Message-ID | <e1b992f7-65c4-4115-9f80-10fb671d3763@googlegroups.com> |
Hi All, I have just posted a version of the SHA-256 algorithm, complete with a test suite. www.inventio.co.uk has links to the source at : www.inventio.co.uk\SHA-256.f and www.inventio.co.uk\SHA-256.zip SHA-256.f Secure Hash Algorithm SHA-256 Howerd Oakford 2012 Nov 21 For SwiftForth 32 bit Little Endian ANS Forth, with Round functions coded in SwiftForth x86 assembler With thanks to Jabari Zakiya and Dick van Oudheusden for providing a starting point... The timing test shows timings on a 3.06GHz Intel i3 of : High level Win32Forth 6.05H 11590 ms 1419% High level SwiftForth 3.4.4 1226 ms 150% High level VFX 4.60 967 ms 118% Assembler SwiftForth 3.4.4 817 ms 100% This shows that hand crafted assembler is still better than an optimising compiler, but not by much - well done to Stephen and all at MPE. Note that I used a very old version of Win32Forth - the latest versions should be much faster. I ported this to SwiftForth assembler en-route to colorForth, via NASM... Enjoy! Howerd
[toc] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-22 22:53 +0000 |
| Message-ID | <50aea97d.527209434@192.168.0.50> |
| In reply to | #17453 |
On Tue, 20 Nov 2012 22:32:48 -0800 (PST), Howerd <howerdo@yahoo.co.uk> wrote: >The timing test shows timings on a 3.06GHz Intel i3 of : >High level Win32Forth 6.05H 11590 ms 1419% >High level SwiftForth 3.4.4 1226 ms 150% >High level VFX 4.60 967 ms 118% >Assembler SwiftForth 3.4.4 817 ms 100% > >This shows that hand crafted assembler is still better than an >optimising compiler, but not by much - well done to Stephen and >all at MPE. It is with great smugness that I report the following result on my i7 box. High level VFX 4.60 640 ms This is Howerd's original with RROTATE corrected. There are coded VFX words. It was then recoded to use high level code only - VFX has rotate primitives ROR and ROL ( x1 n -- x2 ) : rrotate ( x1 n -- x2 ) ror ; : RROTATE2 ( x1 -- x2 ) 2 ror ; : RROTATE6 ( x1 -- x2 ) 6 ror ; : RROTATE11 ( x1 -- x2 ) 11 ror ; : RROTATE25 ( x1 -- x2 ) 25 ror ; : RROTATE7 ( x1 -- x2 ) 7 ror ; : RROTATE13 ( x1 -- x2 ) 13 ror ; : RROTATE22 ( x1 -- x2 ) 22 ror ; : RROTATE18 ( x1 -- x2 ) 18 ror ; : RROTATE17 ( x1 -- x2 ) 17 ror ; : RROTATE19 ( x1 -- x2 ) 19 ror ; High level VFX 4.60 452 ms Assembler SwiftForth 3.4.5 576 ms Hand crafted assembler is slower in this case. The code was built with 0 CONSTANT HIGH-LEVEL Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | ritaoakford@gmail.com |
|---|---|
| Date | 2012-11-23 00:21 -0800 |
| Message-ID | <66d2e91f-2100-4be3-833a-3b9cc9cf62b2@googlegroups.com> |
| In reply to | #17487 |
Hi Stephen, Even better! I will take a look at the VFX result and see where I went wrong :-) Best regards, Howerd On Thursday, November 22, 2012 11:55:03 PM UTC+1, Stephen Pelc wrote: > On Tue, 20 Nov 2012 22:32:48 -0800 (PST), Howerd <how....@yahoo.co.uk> > > wrote: > > > > >The timing test shows timings on a 3.06GHz Intel i3 of : > > >High level Win32Forth 6.05H 11590 ms 1419% > > >High level SwiftForth 3.4.4 1226 ms 150% > > >High level VFX 4.60 967 ms 118% > > >Assembler SwiftForth 3.4.4 817 ms 100% > > > > > >This shows that hand crafted assembler is still better than an > > >optimising compiler, but not by much - well done to Stephen and > > >all at MPE. > > > > It is with great smugness that I report the following result on > > my i7 box. > > > > High level VFX 4.60 640 ms > > This is Howerd's original with RROTATE corrected. There are coded > > VFX words. > > > > It was then recoded to use high level code only - VFX has rotate > > primitives ROR and ROL ( x1 n -- x2 ) > > > > : rrotate ( x1 n -- x2 ) ror ; > > : RROTATE2 ( x1 -- x2 ) 2 ror ; > > : RROTATE6 ( x1 -- x2 ) 6 ror ; > > : RROTATE11 ( x1 -- x2 ) 11 ror ; > > : RROTATE25 ( x1 -- x2 ) 25 ror ; > > : RROTATE7 ( x1 -- x2 ) 7 ror ; > > : RROTATE13 ( x1 -- x2 ) 13 ror ; > > : RROTATE22 ( x1 -- x2 ) 22 ror ; > > : RROTATE18 ( x1 -- x2 ) 18 ror ; > > : RROTATE17 ( x1 -- x2 ) 17 ror ; > > : RROTATE19 ( x1 -- x2 ) 19 ror ; > > > > High level VFX 4.60 452 ms > > Assembler SwiftForth 3.4.5 576 ms > > > > Hand crafted assembler is slower in this case. > > The code was built with > > 0 CONSTANT HIGH-LEVEL > > > > Stephen > > > > -- > > Stephen Pelc, stephenXXX@mpeforth.com > > MicroProcessor Engineering Ltd - More Real, Less Time > > 133 Hill Lane, Southampton SO15 5AF, England > > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 > > web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-23 14:20 +0000 |
| Message-ID | <50af8643$0$3150$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #17487 |
In article <50aea97d.527209434@192.168.0.50>, Stephen Pelc <stephenXXX@INVALID.mpeforth.com> wrote: >On Tue, 20 Nov 2012 22:32:48 -0800 (PST), Howerd <howerdo@yahoo.co.uk> >wrote: > >>The timing test shows timings on a 3.06GHz Intel i3 of : >>High level Win32Forth 6.05H 11590 ms 1419% >>High level SwiftForth 3.4.4 1226 ms 150% >>High level VFX 4.60 967 ms 118% >>Assembler SwiftForth 3.4.4 817 ms 100% >> >>This shows that hand crafted assembler is still better than an >>optimising compiler, but not by much - well done to Stephen and >>all at MPE. > >It is with great smugness that I report the following result on >my i7 box. > >High level VFX 4.60 640 ms >This is Howerd's original with RROTATE corrected. There are coded >VFX words. > >It was then recoded to use high level code only - VFX has rotate >primitives ROR and ROL ( x1 n -- x2 ) > >: rrotate ( x1 n -- x2 ) ror ; >: RROTATE2 ( x1 -- x2 ) 2 ror ; >: RROTATE6 ( x1 -- x2 ) 6 ror ; >: RROTATE11 ( x1 -- x2 ) 11 ror ; >: RROTATE25 ( x1 -- x2 ) 25 ror ; >: RROTATE7 ( x1 -- x2 ) 7 ror ; >: RROTATE13 ( x1 -- x2 ) 13 ror ; >: RROTATE22 ( x1 -- x2 ) 22 ror ; >: RROTATE18 ( x1 -- x2 ) 18 ror ; >: RROTATE17 ( x1 -- x2 ) 17 ror ; >: RROTATE19 ( x1 -- x2 ) 19 ror ; > >High level VFX 4.60 452 ms >Assembler SwiftForth 3.4.5 576 ms > >Hand crafted assembler is slower in this case. >The code was built with > 0 CONSTANT HIGH-LEVEL This remembers me of a text comparison routine I wrote in C, running three pages. It was carefully crafted to allow the DEC C (VAX) optimising compiler full reign. I inspected the resulting assembler code carefully. I *could* have written it (in an inordinate amount of time), but I wouldn't *dare*. > >Stephen > 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 (Marcel Hendrix) |
|---|---|
| Date | 2012-11-25 22:58 +0200 |
| Message-ID | <12771310928435@frunobulax.edu> |
| In reply to | #17487 |
stephenXXX@mpeforth.com (Stephen Pelc) writes Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth [..] > It is with great smugness that I report the following result on > my i7 box. [..] > High level VFX 4.60 452 ms > Assembler SwiftForth 3.4.5 576 ms > > Hand crafted assembler is slower in this case. [..] With even more smugness I present iForth32's result :-) [machine i7 2.66 GHz, Windows 7 Professional, 16 GB] highlevel SwiftForth 3.4.2 1239 ms (high-level = 1) VFX 4.50 983 ms (high-level = 1) assembler SwiftForth 3.4.2 860 ms (high-level = 0) VFX 4.50, native ROR 733 ms (high-level = 1) iForth32, native ROR 636 ms (high-level = 1) Unfortunately, recoding for 64bits is a mayor job. I would expect even higher speed for this particular algorithm. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-25 14:41 -0800 |
| Message-ID | <7x38zxxq3d.fsf@ruckus.brouhaha.com> |
| In reply to | #17555 |
mhx@iae.nl (Marcel Hendrix) writes: > highlevel SwiftForth 3.4.2 1239 ms (high-level = 1) > VFX 4.50 983 ms (high-level = 1) > assembler SwiftForth 3.4.2 860 ms (high-level = 0) > VFX 4.50, native ROR 733 ms (high-level = 1) > iForth32, native ROR 636 ms (high-level = 1) That's for 40 million bytes of hashing? Hmm, that's 23.6MB/s/Ghz (4e7 bytes, 0.636 sec, 2.66 ghz). On an E3-1270v2 (3.50 ghz) I get 2.54 cpu seconds for 451e6 bytes from a disk file, or about 50.7MB/s/Ghz using the Linux sha256sum command, more than double the speed scaled by clock. I haven't checked what language it's written in (might use openssl's asm implementation or something). What model of i7 cpu is that? The E3 may be a bit more efficient.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-11-26 00:59 +0200 |
| Message-ID | <19760309928435@frunobulax.edu> |
| In reply to | #17557 |
Paul Rubin <no.email@nospam.invalid> writes Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth
>mhx@iae.nl (Marcel Hendrix) writes:
>> highlevel SwiftForth 3.4.2 1239 ms (high-level = 1)
>> VFX 4.50 983 ms (high-level = 1)
>> assembler SwiftForth 3.4.2 860 ms (high-level = 0)
>> VFX 4.50, native ROR 733 ms (high-level = 1)
>> iForth32, native ROR 636 ms (high-level = 1)
> That's for 40 million bytes of hashing? Hmm, that's 23.6MB/s/Ghz (4e7
> bytes, 0.636 sec, 2.66 ghz). On an E3-1270v2 (3.50 ghz) I get 2.54 cpu
> seconds for 451e6 bytes from a disk file, or about 50.7MB/s/Ghz using
> the Linux sha256sum command, more than double the speed scaled by clock.
> I haven't checked what language it's written in (might use openssl's asm
> implementation or something).
The timer code is
Counter
10 0 do MyBigBuffer 1000000 SHA-256 loop
100 0 do MyBigBuffer 100000 SHA-256 loop
1000 0 do MyBigBuffer 10000 SHA-256 loop
10000 0 do MyBigBuffer 100 SHA-256 loop
cr ." Test time = " Timer ." ms"
where MyBigBuffer holds 1 million chars ('a'). I think that means
10e6 + 10e6 + 10e6 + 1e6 (only 31 MB) is processed. (Howerd: Is this
a bug?)
I do not claim that the Forth implementation is in any way optimal.
For a basic OS utility I'd expect 64 bit code, use of special
SSEx instructions and exploited parallellism (more than 1 core active).
From your observation it might be the case that handling 64bits
at a time (instead of 32) increases the speed twofold.
> What model of i7 cpu is that? The E3 may be a bit more efficient.
It's a 920 with very conservative BIOS settings. I can not run it on
my 64bit-only Linux box which has a more powerful CPU. However, I am
sure Stephen ran the code on the best current hardware already.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-25 16:10 -0800 |
| Message-ID | <7xlidpjkac.fsf@ruckus.brouhaha.com> |
| In reply to | #17558 |
mhx@iae.nl (Marcel Hendrix) writes: > I do not claim that the Forth implementation is in any way optimal. > For a basic OS utility I'd expect 64 bit code, use of special > SSEx instructions and exploited parallellism (more than 1 core active). Good point, the test I did was on a 32 bit OpenVZ container so I think it is 32 bit code. I don't have a 64 bit system on that hardware at the moment. >> What model of i7 cpu is that? > It's a 920 with very conservative BIOS settings. OK, yeah, according to cpubenchmark.net the E3 is quite a lot faster, like almost 2x.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2012-11-26 04:18 -0800 |
| Message-ID | <a0749a7e-5251-43d9-bc3a-d7e6aac274cb@r4g2000vbi.googlegroups.com> |
| In reply to | #17558 |
On Nov 25, 11:59 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Paul Rubin <no.em...@nospam.invalid> writes Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth
>
> >m...@iae.nl (Marcel Hendrix) writes:
> >> highlevel SwiftForth 3.4.2 1239 ms (high-level = 1)
> >> VFX 4.50 983 ms (high-level = 1)
> >> assembler SwiftForth 3.4.2 860 ms (high-level = 0)
> >> VFX 4.50, native ROR 733 ms (high-level = 1)
> >> iForth32, native ROR 636 ms (high-level = 1)
> > That's for 40 million bytes of hashing? Hmm, that's 23.6MB/s/Ghz (4e7
> > bytes, 0.636 sec, 2.66 ghz). On an E3-1270v2 (3.50 ghz) I get 2.54 cpu
> > seconds for 451e6 bytes from a disk file, or about 50.7MB/s/Ghz using
> > the Linux sha256sum command, more than double the speed scaled by clock.
> > I haven't checked what language it's written in (might use openssl's asm
> > implementation or something).
>
> The timer code is
>
> Counter
> 10 0 do MyBigBuffer 1000000 SHA-256 loop
> 100 0 do MyBigBuffer 100000 SHA-256 loop
> 1000 0 do MyBigBuffer 10000 SHA-256 loop
> 10000 0 do MyBigBuffer 100 SHA-256 loop
> cr ." Test time = " Timer ." ms"
>
> where MyBigBuffer holds 1 million chars ('a'). I think that means
> 10e6 + 10e6 + 10e6 + 1e6 (only 31 MB) is processed. (Howerd: Is this
> a bug?)
>
> I do not claim that the Forth implementation is in any way optimal.
> For a basic OS utility I'd expect 64 bit code, use of special
> SSEx instructions and exploited parallellism (more than 1 core active).
>
> From your observation it might be the case that handling 64bits
> at a time (instead of 32) increases the speed twofold.
>
> > What model of i7 cpu is that? The E3 may be a bit more efficient.
>
> It's a 920 with very conservative BIOS settings. I can not run it on
> my 64bit-only Linux box which has a more powerful CPU. However, I am
> sure Stephen ran the code on the best current hardware already.
>
> -marcel
>
>
Hi Marcel,
> The timer code is
>
> Counter
> 10 0 do MyBigBuffer 1000000 SHA-256 loop
> 100 0 do MyBigBuffer 100000 SHA-256 loop
> 1000 0 do MyBigBuffer 10000 SHA-256 loop
> 10000 0 do MyBigBuffer 100 SHA-256 loop
> cr ." Test time = " Timer ." ms"
>
> where MyBigBuffer holds 1 million chars ('a'). I think that means
> 10e6 + 10e6 + 10e6 + 1e6 (only 31 MB) is processed. (Howerd: Is this
> a bug?)
Yes, it is a bug of the sub-genre 'typo' ;-)
Best regards,
Howerd
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-26 19:17 +0100 |
| Message-ID | <2353058.3Fdhy6rgYD@sunwukong.fritz.box> |
| In reply to | #17558 |
Marcel Hendrix wrote:
> The timer code is
>
> Counter
> 10 0 do MyBigBuffer 1000000 SHA-256 loop
> 100 0 do MyBigBuffer 100000 SHA-256 loop
> 1000 0 do MyBigBuffer 10000 SHA-256 loop
> 10000 0 do MyBigBuffer 100 SHA-256 loop
> cr ." Test time = " Timer ." ms"
>
> where MyBigBuffer holds 1 million chars ('a'). I think that means
> 10e6 + 10e6 + 10e6 + 1e6 (only 31 MB) is processed. (Howerd: Is this
> a bug?)
So we have 636ms for 31MB of hash code? Seems to be that sha-256 isn't
that fast as hash.
Compare Wurstkessel as 64 bit implementation on a 2.4GHz Xeon 5620,
using the net2o crypto primitive encrypt-buffer:
32 1024 dup * * Constant 32M
32M allocate throw value foo
foo 32M dup mem-rounds# !time encrypt-buffer .time 0.097755916 s ok
foo 32M roundsh# !time encrypt-buffer .time 0.050240029 s ok
The first run is using a number of rounds suitable for encryption, the
latter one suitable for hashing only (you need less rounds for hasing,
as you expose only the final result; add a few finalizing rounds, and
you are safe). This is implemented in C, but Marcel's iForth64 did
compile Wurstkessel about as good as GCC. Wurstkessel depends on 64
bit, using a 32 bit processor with about the same oompf results in a
factor 2.5 slowdown (all operations are 64 bit operations).
sha-256 has the general problem of all Merkle-Dangard hashes; which
Wurstkessel hasn't, as it uses a variation of the sponge function
approach ("sponge function" is a term used by the Keccak winner of the
SHA3 contest).
The big advantage of a sponge function-like encryption primitive is that
you can use it in one go for both encryption and authentication, whereas
with a combination of AES+SHA, this is much more complicated.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-26 11:57 +0000 |
| Message-ID | <50b3581a.63963810@192.168.0.50> |
| In reply to | #17555 |
On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: >With even more smugness I present iForth32's result :-) Hot diggity! The code generator competitions are open again! However, the coding wars may have to wait until the new puppy has settled in. At least it is now confirmed that assembler is *not* the way to go. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-26 06:17 -0600 |
| Message-ID | <t-adnTx_NMhtwC7NnZ2dnUVZ7tGdnZ2d@supernews.com> |
| In reply to | #17567 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: > >>With even more smugness I present iForth32's result :-) > > Hot diggity! The code generator competitions are open again! > > However, the coding wars may have to wait until the new puppy has > settled in. At least it is now confirmed that assembler is *not* the > way to go. Well, it might be: we just have to find an assembler programmer who is better than your optimizer! Andrew.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-11-26 23:22 +0200 |
| Message-ID | <70131209928435@frunobulax.edu> |
| In reply to | #17567 |
stephenXXX@mpeforth.com (Stephen Pelc) writes Re: ANN: SHA-256 Secure Hash Algorithm in ANS Forth
> On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote:
>
>>With even more smugness I present iForth32's result :-)
>
>Hot diggity! The code generator competitions are open again!
>
>However, the coding wars may have to wait until the new puppy has
>settled in. At least it is now confirmed that assembler is *not* the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>way to go.
^^^^^^^^^^
No, *that* has not been proved. Almost certainly one can find a way
to improve the code generated by iForth32, simply by disassembling it
and eyeballing.
What *has* been proved is that by now naive use of assembly language
does not automatically lead to the fastest Forth code. It used to be
that the approach of finding the 'inner loop' of the algorithm and
coding that in assembler was enough. Apparently, current Forth
compilers shave off a significant amount of cycles all over the
place, making it very difficult to beat them (read: it costs an
excessive amount of invested time to rework all of the higher-level
code) unless one is using a slow implementation to begin with.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-27 13:33 +0000 |
| Message-ID | <50b4bcf4.155317684@192.168.0.50> |
| In reply to | #17582 |
On Mon, 26 Nov 2012 23:22:33 +0200, mhx@iae.nl (Marcel Hendrix) wrote: >>>With even more smugness I present iForth32's result :-) >> >>Hot diggity! The code generator competitions are open again! Code generation for return stack activity in iForth is truly excellent. >>However, the coding wars may have to wait until the new puppy has >>settled in. At least it is now confirmed that assembler is *not* the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>way to go. > ^^^^^^^^^^ > >No, *that* has not been proved. Almost certainly one can find a way >to improve the code generated by iForth32, simply by disassembling it >and eyeballing. That's always true. >What *has* been proved is that by now naive use of assembly language >does not automatically lead to the fastest Forth code. It used to be >that the approach of finding the 'inner loop' of the algorithm and >coding that in assembler was enough. That assumption, which I call the "spot assembler" assumption", is now mostly invalid. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-11-27 09:18 +0100 |
| Message-ID | <337aab2387411bdf0dd64dba69f04ccd@msgid.frell.theremailer.net> |
| In reply to | #17567 |
stephenXXX@mpeforth.com (Stephen Pelc) wrote: > On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: > > >With even more smugness I present iForth32's result :-) > > Hot diggity! The code generator competitions are open again! > > However, the coding wars may have to wait until the new puppy has > settled in. At least it is now confirmed that assembler is *not* the > way to go. That's pretty suspicious. If you're the one writing the code generator for your Forth, then why can't /you/ beat it in handwritten assembler? And if you didn't write the code generator, then whoever did should be able to beat the compiler. If not there's something seriously wrong here.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-27 01:08 -0800 |
| Message-ID | <62cdd152-bf5a-4430-b0d3-5303466729f3@u9g2000vbm.googlegroups.com> |
| In reply to | #17595 |
On Nov 27, 8:18 am, Fritz Wuehler <fr...@spamexpire-201211.rodent.frell.theremailer.net> wrote: > stephen...@mpeforth.com (Stephen Pelc) wrote: > > On Sun, 25 Nov 2012 22:58:23 +0200, m...@iae.nl (Marcel Hendrix) wrote: > > > >With even more smugness I present iForth32's result :-) > > > Hot diggity! The code generator competitions are open again! > > > However, the coding wars may have to wait until the new puppy has > > settled in. At least it is now confirmed that assembler is *not* the > > way to go. > > That's pretty suspicious. If you're the one writing the code generator for > your Forth, then why can't /you/ beat it in handwritten assembler? And if > you didn't write the code generator, then whoever did should be able to beat > the compiler. If not there's something seriously wrong here. Or maybe it's just a very good code generator?
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-27 11:18 +0000 |
| Message-ID | <50b49f67.147752665@192.168.0.50> |
| In reply to | #17595 |
On Tue, 27 Nov 2012 09:18:44 +0100, Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> wrote: >That's pretty suspicious. If you're the one writing the code generator for >your Forth, then why can't /you/ beat it in handwritten assembler? And if >you didn't write the code generator, then whoever did should be able to beat >the compiler. If not there's something seriously wrong here. The benefit of this particular piece of code is that it was *not* written by the author of a particular compiler. Howerd made a common assumption that spot use of assembler would improve performance. In this case spot use does not improve performance over a range of Forth compilers. Anyone who disassembles compiler output and is a comptent assembler programmer should be able to write code that is at least as fast as the compiler output. This not the point. What these numbers are indicating is that you have to write more assembler than you might want in order to beat good code generators. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-27 16:32 +0000 |
| Message-ID | <50b4eb2a$0$3501$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #17595 |
In article <337aab2387411bdf0dd64dba69f04ccd@msgid.frell.theremailer.net>, Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> wrote: >stephenXXX@mpeforth.com (Stephen Pelc) wrote: > >> On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: >> >> >With even more smugness I present iForth32's result :-) >> >> Hot diggity! The code generator competitions are open again! >> >> However, the coding wars may have to wait until the new puppy has >> settled in. At least it is now confirmed that assembler is *not* the >> way to go. > >That's pretty suspicious. If you're the one writing the code generator for >your Forth, then why can't /you/ beat it in handwritten assembler? And if >you didn't write the code generator, then whoever did should be able to beat >the compiler. If not there's something seriously wrong here. Please what is 173527392823623623627 37838383838762524252626 M* D. My computer gives the correct answer in a split second. You can't give the correct answer by hand, within a reasonable time. > 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 | Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-11-28 11:59 +0100 |
| Message-ID | <48d905c5c80f65fa610e9eea1f90ef0b@msgid.frell.theremailer.net> |
| In reply to | #17604 |
albert@spenarnc.xs4all.nl (Albert van der Horst) wrote: > In article <337aab2387411bdf0dd64dba69f04ccd@msgid.frell.theremailer.net>, > Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> wrote: > >stephenXXX@mpeforth.com (Stephen Pelc) wrote: > > > >> On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: > >> > >> >With even more smugness I present iForth32's result :-) > >> > >> Hot diggity! The code generator competitions are open again! > >> > >> However, the coding wars may have to wait until the new puppy has > >> settled in. At least it is now confirmed that assembler is *not* the > >> way to go. > > > >That's pretty suspicious. If you're the one writing the code generator for > >your Forth, then why can't /you/ beat it in handwritten assembler? And if > >you didn't write the code generator, then whoever did should be able to beat > >the compiler. If not there's something seriously wrong here. > > Please what is > 173527392823623623627 37838383838762524252626 M* D. > My computer gives the correct answer in a split second. > > You can't give the correct answer by hand, within a reasonable time. And how does this relate to the discussion? Did you think the issue was Stephen being able to /write/ the assembler code as fast as the compiler could output it? Hint: no.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-28 14:11 +0000 |
| Message-ID | <50b61b93$0$3186$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #17623 |
In article <48d905c5c80f65fa610e9eea1f90ef0b@msgid.frell.theremailer.net>, Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) wrote: > >> In article <337aab2387411bdf0dd64dba69f04ccd@msgid.frell.theremailer.net>, >> Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> wrote: >> >stephenXXX@mpeforth.com (Stephen Pelc) wrote: >> > >> >> On Sun, 25 Nov 2012 22:58:23 +0200, mhx@iae.nl (Marcel Hendrix) wrote: >> >> >> >> >With even more smugness I present iForth32's result :-) >> >> >> >> Hot diggity! The code generator competitions are open again! >> >> >> >> However, the coding wars may have to wait until the new puppy has >> >> settled in. At least it is now confirmed that assembler is *not* the >> >> way to go. >> > >> >That's pretty suspicious. If you're the one writing the code generator for >> >your Forth, then why can't /you/ beat it in handwritten assembler? And if >> >you didn't write the code generator, then whoever did should be able to beat >> >the compiler. If not there's something seriously wrong here. >> >> Please what is >> 173527392823623623627 37838383838762524252626 M* D. >> My computer gives the correct answer in a split second. >> >> You can't give the correct answer by hand, within a reasonable time. > >And how does this relate to the discussion? Did you think the issue was >Stephen being able to /write/ the assembler code as fast as the compiler >could output it? Hint: no. I bring in the issue that Stephen is not able to write the assembler code in his life time. > 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]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web