Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #44782 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2016-01-12 07:47 -0800 |
| Last post | 2016-02-11 07:39 -0800 |
| Articles | 20 on this page of 127 — 28 participants |
Back to article view | Back to comp.lang.forth
Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 07:47 -0800
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-12 16:25 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-12 10:45 -0600
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 08:46 -0800
Re: Ruby/Forth challenge for WJ rickman <gnuarm@gmail.com> - 2016-01-12 11:57 -0500
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 09:22 -0800
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-01-12 21:04 -0800
Re: Ruby/Forth challenge for WJ Ron Aaron <rambamist@gmail.com> - 2016-01-13 07:59 +0200
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-12 19:42 +0000
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-12 12:53 -0800
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-13 15:45 +0000
Re: Ruby/Forth challenge for WJ rickman <gnuarm@gmail.com> - 2016-01-13 13:44 -0500
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-13 11:39 -0800
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-14 05:01 +0100
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-14 12:28 +0000
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 09:50 -0800
Re: Ruby/Forth challenge for WJ Pablo Hugo Reda <pabloreda@gmail.com> - 2016-01-12 11:50 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 12:30 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 12:43 -0800
Re: Ruby/Forth challenge for WJ stephen@mpeforth.com (Stephen Pelc) - 2016-01-12 21:01 +0000
Re: Ruby/Forth challenge for WJ peter.m.falth@gmail.com - 2016-01-12 15:00 -0800
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-12 16:13 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-12 16:22 -0800
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-12 16:24 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-12 17:46 -0800
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-12 18:39 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-13 13:05 -0800
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-14 04:33 +0100
Re: Ruby/Forth challenge for WJ m.a.m.hendrix@tue.nl - 2016-01-14 03:27 -0800
Re: Ruby/Forth challenge for WJ peter.m.falth@gmail.com - 2016-01-14 04:42 -0800
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-14 13:03 +0000
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-13 21:17 -0800
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-01-13 21:44 -0800
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-14 10:57 +0000
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-14 12:20 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-14 13:57 -0800
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-14 14:22 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-14 16:14 -0800
Re: Ruby/Forth challenge for WJ Melzzzzz <mel@zzzzz.com> - 2016-01-15 03:05 +0100
Re: Ruby/Forth challenge for WJ Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2016-01-15 00:41 +0000
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-15 16:22 +0000
Re: Ruby/Forth challenge for WJ mhx@iae.nl (Marcel Hendrix) - 2016-01-16 11:44 +0200
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-16 04:49 -0800
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-16 15:05 +0000
Re: Ruby/Forth challenge for WJ m.a.m.hendrix@tue.nl - 2016-01-18 03:26 -0800
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-18 12:48 +0000
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-19 22:26 +0100
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-20 03:05 -0800
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-20 21:00 +0100
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-20 15:57 -0800
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-21 23:02 +0100
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-22 01:25 +0000
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-01-21 18:05 -0800
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-21 22:03 -0800
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-20 13:40 +0000
Re: Ruby/Forth challenge for WJ m.a.m.hendrix@tue.nl - 2016-01-18 03:55 -0800
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-23 15:13 -0600
Re: Ruby/Forth challenge for WJ mhx@iae.nl - 2016-01-24 00:55 -0800
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-25 04:48 -0600
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-25 12:39 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-25 08:05 -0600
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-25 16:40 +0000
Re: Ruby/Forth challenge for WJ Mark Wills <markwills1970@gmail.com> - 2016-01-25 04:44 -0800
Re: Ruby/Forth challenge for WJ stephen@mpeforth.com (Stephen Pelc) - 2016-01-25 14:01 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-25 08:08 -0600
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-25 11:56 -0600
Re: Ruby/Forth challenge for WJ "Elizabeth D. Rather" <erather@forth.com> - 2016-01-25 11:12 -1000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-26 03:33 -0600
Re: Ruby/Forth challenge for WJ stephen@mpeforth.com (Stephen Pelc) - 2016-01-26 11:09 +0000
Re: Ruby/Forth challenge for WJ stephen@mpeforth.com (Stephen Pelc) - 2016-01-26 11:06 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-26 07:45 -0600
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-26 16:46 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-26 11:16 -0600
Object-oriented Forth (was: Ruby/Forth challenge for WJ) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-27 14:13 +0000
Re: Object-oriented Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-27 10:33 -0600
Re: Object-oriented Forth hughaguilar96@gmail.com - 2016-01-27 08:45 -0800
Re: Object-oriented Forth Chris Curl <ccurl609@gmail.com> - 2016-01-27 09:14 -0800
Re: Object-oriented Forth hughaguilar96@gmail.com - 2016-01-29 21:57 -0800
Re: Object-oriented Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-30 10:58 +0000
Re: Object-oriented Forth Chris Curl <ccurl609@gmail.com> - 2016-01-30 09:38 -0800
Re: Object-oriented Forth Coos Haak <chforth@hccnet.nl> - 2016-01-30 20:39 +0100
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-26 15:56 +0100
Re: Ruby/Forth challenge for WJ stephen@mpeforth.com (Stephen Pelc) - 2016-01-26 20:46 +0000
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-25 22:27 +0100
Re: Ruby/Forth challenge for WJ Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2016-01-28 14:20 +0100
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-28 08:06 -0600
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-28 16:14 +0100
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-28 10:32 -0600
Re: Ruby/Forth challenge for WJ anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-28 17:26 +0000
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-28 12:13 -0600
Re: Ruby/Forth challenge for WJ Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-29 11:07 +0000
Re: Ruby/Forth challenge for WJ Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-29 21:18 +0100
Re: Ruby/Forth challenge for WJ Tessa Bonting <tessa.bonting@gmail.com> - 2016-01-16 06:24 -0800
Re: Ruby/Forth challenge for WJ Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-13 05:21 -0500
Re: Ruby/Forth challenge for WJ Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-13 05:36 -0500
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-13 10:33 -0800
Re: Ruby/Forth challenge for WJ Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-14 01:37 -0500
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 13:45 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 13:55 -0800
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-12 14:34 -0800
Re: Ruby/Forth challenge for WJ rickman <gnuarm@gmail.com> - 2016-01-12 19:00 -0500
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 16:49 -0800
Re: Ruby/Forth challenge for WJ rickman <gnuarm@gmail.com> - 2016-01-12 22:18 -0500
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-01-12 14:31 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-12 16:05 -0800
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-01-13 07:58 +0000
Re: Ruby/Forth challenge for WJ Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-13 05:17 -0500
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-13 12:36 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-13 12:53 -0800
Re: Ruby/Forth challenge for WJ Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-14 06:50 -0600
Re: Ruby/Forth challenge for WJ Julian Fondren <julian.fondren@gmail.com> - 2016-01-13 05:36 -0800
Re: Ruby/Forth challenge for WJ lehs <skydda.barnen@gmail.com> - 2016-01-13 11:59 -0800
Re: Ruby/Forth challenge for WJ Chris Curl <ccurl609@gmail.com> - 2016-01-21 21:08 -0800
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-09 13:36 +0000
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-09 13:48 +0000
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-02-09 12:02 -0800
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-09 13:58 +0000
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-09 14:30 +0000
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-14 15:35 +0000
Re: Ruby/Forth challenge for WJ franck.bensusan@gmail.com - 2016-02-14 08:50 -0800
Re: Ruby/Forth challenge for WJ Julian Fondren <julian.fondren@gmail.com> - 2016-02-14 20:09 -0800
Re: Ruby/Forth challenge for WJ hughaguilar96@gmail.com - 2016-02-15 08:52 -0800
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-02-14 21:31 +0000
Re: Ruby/Forth challenge for WJ "WJ" <w_a_x_man@yahoo.com> - 2016-01-14 22:49 +0000
Re: Ruby/Forth challenge for WJ Paul Rubin <no.email@nospam.invalid> - 2016-01-14 15:31 -0800
Re: Ruby/Forth challenge for WJ Melzzzzz <mel@zzzzz.com> - 2016-01-15 06:55 +0100
Re: Ruby/Forth challenge for WJ djc <ciesinger@gmx.net> - 2016-02-11 07:39 -0800
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 07:47 -0800 |
| Subject | Ruby/Forth challenge for WJ |
| Message-ID | <35f4686c-f2c4-4ed8-9c46-2238645b9b97@googlegroups.com> |
So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: 1. Allocate 256MB ram and fill it with random binary data. 2. Collect and print out the distribution of byte values in all 256MB bytes from #1. Forthers, how fast can your Forth do it? Any bets on which will be faster?
[toc] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-12 16:25 +0000 |
| Message-ID | <569528f5$0$23800$e4fe514c@news.xs4all.nl> |
| In reply to | #44782 |
Chris Curl <ccurl609@gmail.com> writes: >So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: >1. Allocate 256MB ram and fill it with random binary data. >2. Collect and print out the distribution of byte values in all 256MB bytes from #1. >Forthers, how fast can your Forth do it? >Any bets on which will be faster? This depends entirely on the quality of the random generator. An excellent random generator would be to wait for a fixed time a radioactive sample has generated about a million counts, then take the result modulo 256. The counts must not fall over each other so one random byte takes approximately one second. I don't know Ruby but I guess it can keep up. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-01-12 10:45 -0600 |
| Message-ID | <fuKdnVVjvJ5dsAjLnZ2dnUU78K-dnZ2d@supernews.com> |
| In reply to | #44783 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > Chris Curl <ccurl609@gmail.com> writes: > >>So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: > >>1. Allocate 256MB ram and fill it with random binary data. >>2. Collect and print out the distribution of byte values in all >>256MB bytes from #1. > >>Forthers, how fast can your Forth do it? > >>Any bets on which will be faster? > > This depends entirely on the quality of the random generator. > An excellent random generator would be to wait for a fixed time a > radioactive sample has generated about a million counts, then take the > result modulo 256. The counts must not fall over each other so > one random byte takes approximately one second. > > I don't know Ruby but I guess it can keep up. Very droll. However, an ID Quantique generator can do 16 Mbis/s. I think Ruby might be able to keep up with that. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 08:46 -0800 |
| Message-ID | <fbef16ef-7390-495e-9393-7e42cb59bcac@googlegroups.com> |
| In reply to | #44783 |
On Tuesday, January 12, 2016 at 11:25:28 AM UTC-5, Albert van der Horst wrote: > Chris Curl <cc...@gmail.com> writes: > > >So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: > > >1. Allocate 256MB ram and fill it with random binary data. > >2. Collect and print out the distribution of byte values in all 256MB bytes from #1. > > >Forthers, how fast can your Forth do it? > > >Any bets on which will be faster? > > This depends entirely on the quality of the random generator. > An excellent random generator would be to wait for a fixed time a > radioactive sample has generated about a million counts, then take the > result modulo 256. The counts must not fall over each other so > one random byte takes approximately one second. > > I don't know Ruby but I guess it can keep up. > > 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 a performance test, not a "how truly random a number generator can you create?" test. For this test, pseudo-random values are fine, and since the stats are BYTE based, there are really only 256 possibilities for the random number. The real test is the performance of accessing of the 256 million individual bytes and the collection of the statistics.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-01-12 11:57 -0500 |
| Message-ID | <n73b4m$cav$1@dont-email.me> |
| In reply to | #44785 |
On 1/12/2016 11:46 AM, Chris Curl wrote: > On Tuesday, January 12, 2016 at 11:25:28 AM UTC-5, Albert van der Horst wrote: >> Chris Curl <cc...@gmail.com> writes: >> >>> So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: >> >>> 1. Allocate 256MB ram and fill it with random binary data. >>> 2. Collect and print out the distribution of byte values in all 256MB bytes from #1. >> >>> Forthers, how fast can your Forth do it? >> >>> Any bets on which will be faster? >> >> This depends entirely on the quality of the random generator. >> An excellent random generator would be to wait for a fixed time a >> radioactive sample has generated about a million counts, then take the >> result modulo 256. The counts must not fall over each other so >> one random byte takes approximately one second. >> >> I don't know Ruby but I guess it can keep up. >> >> 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 a performance test, not a "how truly random a number generator can you create?" test. > > For this test, pseudo-random values are fine, and since the stats are BYTE based, there are > really only 256 possibilities for the random number. The real test is the performance of > accessing of the 256 million individual bytes and the collection of the statistics. Maybe I'm missing something, but if you have to generate 256 million random values, I think the execution time will be dominated by that, not the analysis of the results, which would be rather trivial. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 09:22 -0800 |
| Message-ID | <405d572a-3a74-49fe-9d5f-50a6dcf6102f@googlegroups.com> |
| In reply to | #44786 |
On Tuesday, January 12, 2016 at 11:57:30 AM UTC-5, rickman wrote: > On 1/12/2016 11:46 AM, Chris Curl wrote: > > On Tuesday, January 12, 2016 at 11:25:28 AM UTC-5, Albert van der Horst wrote: > >> Chris Curl <cc...@gmail.com> writes: > >> > >>> So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: > >> > >>> 1. Allocate 256MB ram and fill it with random binary data. > >>> 2. Collect and print out the distribution of byte values in all 256MB bytes from #1. > >> > >>> Forthers, how fast can your Forth do it? > >> > >>> Any bets on which will be faster? > >> > >> This depends entirely on the quality of the random generator. > >> An excellent random generator would be to wait for a fixed time a > >> radioactive sample has generated about a million counts, then take the > >> result modulo 256. The counts must not fall over each other so > >> one random byte takes approximately one second. > >> > >> I don't know Ruby but I guess it can keep up. > >> > >> 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 a performance test, not a "how truly random a number generator can you create?" test. > > > > For this test, pseudo-random values are fine, and since the stats are BYTE based, there are > > really only 256 possibilities for the random number. The real test is the performance of > > accessing of the 256 million individual bytes and the collection of the statistics. > > Maybe I'm missing something, but if you have to generate 256 million > random values, I think the execution time will be dominated by that, not > the analysis of the results, which would be rather trivial. > > -- > > Rick I understand your point. The goal of the "challenge" was to compare the performance of accessing the memory and collection the stats. The generation of the random values was simply to provide the data so the stats could be collected. So how about this to re-state the challenge? Given a 256MB buffer of binary data in memory, generate a table of counts of the byte values for all the bytes in the 256MB buffer as fast as possible. How the 256MB buffer is created is left to the discretion of the programmer, and the time to create it is not included in the timing of the test.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-12 21:04 -0800 |
| Message-ID | <63096005-00f1-4369-94fa-999f69c1bbe8@googlegroups.com> |
| In reply to | #44787 |
On Tuesday, January 12, 2016 at 10:22:36 AM UTC-7, Chris Curl wrote: > So how about this to re-state the challenge? > > Given a 256MB buffer of binary data in memory, generate a table of counts of the byte values > for all the bytes in the 256MB buffer as fast as possible. How the 256MB buffer is created > is left to the discretion of the programmer, and the time to create it is not included > in the timing of the test. Okay Chris, I found your restated challenge. In a language with quotations, this could be pretty fast. There would be a HOF that is written in the underlying language (either C or assembly-language) and it would execute the quotation for every element in the data-structure (the array). So, the iteration code is fast (C or assembly-language) but the quotation is slow (user-written Ruby code, or whatever scripting language we are testing). In this case, the quotation is pretty short and simple, so you aren't testing the language very thoroughly. In a language with JIT (such as Racket or most Scheme implementations), our quotation is going to get JITed so it should be pretty fast. I don't know if Ruby has JIT or not. For the most part, I don't put much stock in benchmarks such as this. I am reminded of how, back in the late 1980s people were always benchmarking compilers (comparing Turbo-C, Microsoft-C and Watcom-C to decide which one to buy) --- for the most part, this was all baloney --- those benchmarks didn't really tell you anything about how the compiler was going to generate code for real world programs. Benchmarks are even less useful now. If your benchmark program is short (they usually are), then even if the code is bloated it will still all fit within the 32KB of code-cache and you will get good speed --- but if the code is bloated a full-size program will waste a lot of time with code-cache thrashing and your speed will be lost. I still say that the best way to benchmark a compiler is to write a non-trivial program in it. I think my LowDraw program is a good choice because it doesn't rely on any functions that are going to be found in code libraries that may or may not be available --- it is numeric, but it doesn't do any transcendental functions (SQRT, SIN, etc.), nor does it use random numbers --- it does a lot of floating-point addition and multiplication, so it is a good benchmark for people interested in numeric programming. I'll be interested in finding out if my FloatForth performs better with fixed-point (64-bit, with a unity of 2^32) or performs better with IEEE-754 double-precision as its representation of a "number." The program is recursive, so that may be interesting to people who write a lot of recursive traversal programs. The program is large enough that code bloat may or may not push the program over the 32KB code-cache size.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-01-13 07:59 +0200 |
| Message-ID | <n74ovo$606$1@dont-email.me> |
| In reply to | #44814 |
On 13/01/2016 07:04, hughaguilar96@gmail.com wrote: > Benchmarks are even less useful now. If your benchmark program is > short (they usually are), then even if the code is bloated it will > still all fit within the 32KB of code-cache and you will get good > speed --- but if the code is bloated a full-size program will waste > a lot of time with code-cache thrashing and your speed will be lost. True. Benchmarks also don't take into consideration the amount of time and effort the programmer had to put in, in order to get the result. Some languages are more productive than others, for a given task. More to the point: what matters at the end of the day is whether the resultant program is fast enough. The difference between 100ms and 10ms response time is immaterial in a GUI application, even though the program is nominally 10X faster. If it took the programmer longer to write the optimized code than the non-optimized, it was simply a waste of time and money. That same difference between 100 and 10ms could be the difference between success and failure in an algorithmic trading application, however. Context is everything; raw benchmarks are not much.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-12 19:42 +0000 |
| Message-ID | <56955743$0$23724$e4fe514c@news.xs4all.nl> |
| In reply to | #44785 |
Chris Curl <ccurl609@gmail.com> writes: >On Tuesday, January 12, 2016 at 11:25:28 AM UTC-5, Albert van der Horst wrote: >> Chris Curl <cc...@gmail.com> writes: >> >> >So, Ruby is so powerful, and Forth is a toy language. Let's see how fast Ruby can do this: >> >> >1. Allocate 256MB ram and fill it with random binary data. >> >2. Collect and print out the distribution of byte values in all 256MB bytes from #1. >> >> >Forthers, how fast can your Forth do it? >> >> >Any bets on which will be faster? >> >> This depends entirely on the quality of the random generator. >> An excellent random generator would be to wait for a fixed time a >> radioactive sample has generated about a million counts, then take the >> result modulo 256. The counts must not fall over each other so >> one random byte takes approximately one second. >> >> I don't know Ruby but I guess it can keep up. >> >> 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 a performance test, not a "how truly random a number generator can you create?" test. >For this test, pseudo-random values are fine, and since the stats are BYTE based, there are >really only 256 possibilities for the random number. The real test is the performance of >accessing of the 256 million individual bytes and the collection of the statistics. In fact the content of the buffer random or not, has nothing to do with it. So leave it out of the test. You could have read that between my lines. 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 | 2016-01-12 12:53 -0800 |
| Message-ID | <87h9iiv7ry.fsf@nightsong.com> |
| In reply to | #44789 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > In fact the content of the buffer random or not, has nothing to do with it. > So leave it out of the test. You could have read that between my lines. Nah, the randomness makes it faster, since in Forth you're allowed to redefine the problem. If the buffer is random then you're basically sampling the multinomial distribution on 256 million trials and 256 categories. There are very fast numerical ways to do that, with results indistinguishable from actually generating the 256MB buffer and counting it up.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-13 15:45 +0000 |
| Message-ID | <2016Jan13.164504@mips.complang.tuwien.ac.at> |
| In reply to | #44783 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>An excellent random generator would be to wait for a fixed time a
>radioactive sample has generated about a million counts, then take the
>result modulo 256. The counts must not fall over each other so
>one random byte takes approximately one second.
A true random number generator of this kind is a digital camera with
raw output. Just illuminate its sensor with white light (best without
lens or unfocused to get uniform illumination), and each pixel gives
you a count of photons that fell onto it during the exposure time;
this count varies due to quantum mechanical effects randomly by on the
order of sqrt(photons)
<https://en.wikipedia.org/wiki/Shot_noise#Optics>, resulting in image
noise that is so unloved by photographers; and while the SNR is worst
at low brightness (and other noise sources dominate there), the
absolute noise is highest at brightness just below the saturation (and
. With a 20 Megapixel camera, if you only assume 4 bits of randomness
per pixel, you can get 10MB of randomness per shot, and some cameras
are quite fast at shooting raw pictures, and can feed the result
directly to a computer. You need to post-condition the data so that,
e.g., dead pixels or dust on the sensor don't compromise your random
number generator.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-01-13 13:44 -0500 |
| Message-ID | <n765pi$5e1$1@dont-email.me> |
| In reply to | #44828 |
On 1/13/2016 10:45 AM, Anton Ertl wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> An excellent random generator would be to wait for a fixed time a >> radioactive sample has generated about a million counts, then take the >> result modulo 256. The counts must not fall over each other so >> one random byte takes approximately one second. > > A true random number generator of this kind is a digital camera with > raw output. Just illuminate its sensor with white light (best without > lens or unfocused to get uniform illumination), and each pixel gives > you a count of photons that fell onto it during the exposure time; > this count varies due to quantum mechanical effects randomly by on the > order of sqrt(photons) > <https://en.wikipedia.org/wiki/Shot_noise#Optics>, resulting in image > noise that is so unloved by photographers; and while the SNR is worst > at low brightness (and other noise sources dominate there), the > absolute noise is highest at brightness just below the saturation (and > . With a 20 Megapixel camera, if you only assume 4 bits of randomness > per pixel, you can get 10MB of randomness per shot, and some cameras > are quite fast at shooting raw pictures, and can feed the result > directly to a computer. You need to post-condition the data so that, > e.g., dead pixels or dust on the sensor don't compromise your random > number generator. Has anyone tried this? I can see huge issues relating to variations among the pixels which would need to be averaged out some way. It wouldn't just be gross effects like dead pixels that compromise your results. Likewise, variations in the light would produce artifacts in the results. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-01-13 11:39 -0800 |
| Message-ID | <871t9luv44.fsf@nightsong.com> |
| In reply to | #44832 |
rickman <gnuarm@gmail.com> writes:
>> With a 20 Megapixel camera, if you only assume 4 bits of randomness
>> per pixel, you can get 10MB of randomness per shot... You need to
>> post-condition the data so that, e.g., dead pixels or dust on the
>> sensor don't compromise your random number generator.
> Has anyone tried this? I can see huge issues relating to variations
> among the pixels which would need to be averaged out some way.
That digicam performance is limited by shot noise is well known, though
I'm skeptical of getting 4 bits of physical randomness per pixel,
especially with small-sensor consumer digicams where only few thousand
photons are enough to saturate a pixel.[1] Yes of course you have to
massage the output: there's a bunch of mathematical theory ("randomness
extraction") about how to do it with guaranteed minimal loss of
information, but in practice most people just run the data through a
cryptographic hash function.
In practice again, if you can get a few hundred bits of physical
entropy, that's enough to seed a CSPRNG and get unlimited output that
doesn't seem feasible to distinguish from actual random bits.
[1] http://clarkvision.com/articles/does.pixel.size.matter/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-14 05:01 +0100 |
| Message-ID | <n776dv$kod$1@dont-email.me> |
| In reply to | #44834 |
Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>>> With a 20 Megapixel camera, if you only assume 4 bits of randomness
>>> per pixel, you can get 10MB of randomness per shot... You need to
>>> post-condition the data so that, e.g., dead pixels or dust on the
>>> sensor don't compromise your random number generator.
>> Has anyone tried this? I can see huge issues relating to variations
>> among the pixels which would need to be averaged out some way.
>
> That digicam performance is limited by shot noise is well known, though
> I'm skeptical of getting 4 bits of physical randomness per pixel,
> especially with small-sensor consumer digicams where only few thousand
> photons are enough to saturate a pixel.[1] Yes of course you have to
> massage the output: there's a bunch of mathematical theory ("randomness
> extraction") about how to do it with guaranteed minimal loss of
> information, but in practice most people just run the data through a
> cryptographic hash function.
Phyiscal entropie is usually biased; if you take the lowest bits out of a
digicam, the bits are suspects of DNL and INL problems of the ADC (usually
more than enough to be found by randomness test benches, but not enough to
actually be a problem for the image quality - e.g. if your LSB is 45% 0 and
55% 1 due to DNL, you wouldn't see it as artefact in the image).
> In practice again, if you can get a few hundred bits of physical
> entropy, that's enough to seed a CSPRNG and get unlimited output that
> doesn't seem feasible to distinguish from actual random bits.
Indeed. The only problem with CSPRNGs in the past was NSA-induced backdoors
as with the (anyways awful) Dual_EC_DRBG, and possible easy backdooring of
the Intel RDRAND instruction by changing the writeable microcode into doing
AES(key=prefix|counter,data=entropy) instead of the secure
AES(key=entropy,data=prefix|counter). You can't distinguish the two outputs
from a randomness perspective, it's both equally good, but an attacker
knowing the backdoor prefix only needs a bit of guesswork to get at the
entropy.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-14 12:28 +0000 |
| Message-ID | <2016Jan14.132847@mips.complang.tuwien.ac.at> |
| In reply to | #44834 |
Paul Rubin <no.email@nospam.invalid> writes:
>rickman <gnuarm@gmail.com> writes:
>>> With a 20 Megapixel camera, if you only assume 4 bits of randomness
>>> per pixel, you can get 10MB of randomness per shot... You need to
>>> post-condition the data so that, e.g., dead pixels or dust on the
>>> sensor don't compromise your random number generator.
>> Has anyone tried this? I can see huge issues relating to variations
>> among the pixels which would need to be averaged out some way.
>
>That digicam performance is limited by shot noise is well known, though
>I'm skeptical of getting 4 bits of physical randomness per pixel,
>especially with small-sensor consumer digicams where only few thousand
>photons are enough to saturate a pixel.[1]
Actually it should be better with small-pixel cameras than with
big-pixel cameras. E.g., if your pixel overflows when the well size
is 1.1M photons, so you target for 1M photons, and get on the order of
1000 photons noise (is there a constant factor that I would have to
factor in?); with a 12-bit A/D-converter the noise affects only the
lower 2 bits, with a 14-bit A/D converter the low 4 bits, but barely).
By contrast, if the pixel has a well size of, say, 5000 photons, and
we target 4096 photons, we get 64 photons of noise; with a 12-bit A/D
converter, that's close to 6 bits of noise.
So if you want lots of noise, a camera with lots of small pixels is
good; and for the precise reason why lots of mexapixels are not that
popular among photographers.
>In practice again, if you can get a few hundred bits of physical
>entropy, that's enough to seed a CSPRNG and get unlimited output that
>doesn't seem feasible to distinguish from actual random bits.
With real entropy, you should be safer against weaknesses in your PRNG
that may be found in the future.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 09:50 -0800 |
| Message-ID | <4bcadd15-9934-4a71-a3c3-d0a2b12ed81b@googlegroups.com> |
| In reply to | #44782 |
In my own little Forth (it REALLY is a toy Forth at this point), it takes about 29 seconds:
variable stats 255 cells allot
: clr-stats stats 256 cells 0 fill ;
: gen-stats
stats cell (memory) @ dup mem_size @ 1- + swap
do over over i c@ * + .inc. loop
2drop ;
: .stats 256 0 do stats i dup . cells + @ . cr loop ;
clr-stats
gen-stats
My Forth is a home-grown PCode based implementation that I recently put together. I have
spent very little time working on optimizing it.
I have not performed the test on a well-esatblished Forth that people have been working
on for years.
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2016-01-12 11:50 -0800 |
| Message-ID | <862dcb54-6f85-452f-9731-fbe49dbdd4ba@googlegroups.com> |
| In reply to | #44782 |
My aproach full program in ugly mode ------------------------------------------ ^r4/lib/gui.txt #size $fffffff | 256MB #data :randata data >r size 2 >> ( 1? )( rand r!+ 1- ) drop rdrop ; #statd )( 1024 :stat 'statd >r 1024 ( 1? )( 1- 0 r+ ) drop rdrop data size ( 1? )( swap c@+ 1 swap $ff and 2 << 'statd + +! swap 1- ) 2drop ; #lapse :printstat show clrscr verde lapse "%d msec" print cr 'statd >r 256 ( 1? )( r@+ "%d " allowcr print 1- ) drop rdrop 'exit >esc< ; :main msec 'lapse ! mem 'data ! | free mem randata stat msec lapse - 'lapse ! printstat ; : main ; |------------------------------------------ rand is xorshift... Interpreter mode:22035 msec Compiler mode:1607 msec
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 12:30 -0800 |
| Message-ID | <81f8c0d2-27bd-49c0-aa71-9c11040ba9dd@googlegroups.com> |
| In reply to | #44782 |
It is about 3 seconds in GForth.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-12 12:43 -0800 |
| Message-ID | <bc6bdd0a-7fb5-4e09-9cb4-ec98a805ac82@googlegroups.com> |
| In reply to | #44782 |
The same code in SP-Forth takes under 2 seconds:
: .inc. DUP @ 1+ SWAP ! ;
1024 DUP * 256 * CONSTANT memSz
VARIABLE (memory)
memSz ALLOCATE DROP (memory) !
CREATE stats 256 CELLS ALLOT
: clr-stats stats 256 CELLS 0 FILL ;
: all-stats
stats CELL (memory) @ DUP memSz 1- + SWAP
DO OVER OVER I C@ * + .inc. LOOP
2DROP ;
: .stats 256 0 DO stats I DUP . CELLS + @ . CR LOOP ;
: do-test all-stats .stats ;
clr-stats
do-test
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-01-12 21:01 +0000 |
| Message-ID | <569568dc.2338555077@news.eternal-september.org> |
| In reply to | #44792 |
On Tue, 12 Jan 2016 12:43:52 -0800 (PST), Chris Curl <ccurl609@gmail.com> wrote: >The same code in SP-Forth takes under 2 seconds: > >: .inc. DUP @ 1+ SWAP ! ; >1024 DUP * 256 * CONSTANT memSz >VARIABLE (memory) >memSz ALLOCATE DROP (memory) ! > >CREATE stats 256 CELLS ALLOT >: clr-stats stats 256 CELLS 0 FILL ; >: all-stats > stats CELL (memory) @ DUP memSz 1- + SWAP > DO OVER OVER I C@ * + .inc. LOOP > 2DROP ; >: .stats 256 0 DO stats I DUP . CELLS + @ . CR LOOP ; >: do-test all-stats .stats ; >clr-stats >do-test It takes about 600 ms on VFX 4.72. Remarkably, the I/O routine .STATS does not contribute much to this. This may be because of the buffering in the VFX console. The machine is a 3.4 GHz i7 with 8Gb of RAM. 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]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web