Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52599 > unrolled thread
| Started by | polymorph self <jackvanc3@gmail.com> |
|---|---|
| First post | 2016-11-13 18:33 -0800 |
| Last post | 2016-11-29 13:58 -0500 |
| Articles | 9 on this page of 129 — 26 participants |
Back to article view | Back to comp.lang.forth
Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-13 18:33 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-13 23:02 -0500
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-14 16:59 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-14 22:27 -0500
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-17 06:26 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 08:08 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-17 10:52 -0800
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-17 09:57 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-17 15:58 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 16:29 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-18 08:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 11:17 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-18 06:37 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 15:30 +0000
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:25 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 05:08 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 15:12 -1000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-27 21:06 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 12:20 +0000
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 13:43 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 08:52 -0600
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 17:19 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 11:58 -0600
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 20:39 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 21:56 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:22 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-29 11:06 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-29 09:44 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 13:07 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:37 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:02 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 14:41 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-29 21:32 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 12:43 -0500
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 18:38 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:57 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 16:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 00:19 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-18 10:58 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-19 11:29 +1100
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-18 18:18 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-19 00:31 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-20 14:02 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-20 23:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 09:51 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-24 14:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 15:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-19 17:42 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:26 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-22 10:38 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 12:46 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-24 15:15 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 14:30 -0800
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-25 05:37 -0800
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-25 09:58 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:39 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-25 12:26 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:57 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-26 13:40 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-01 05:35 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-01 18:38 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 21:52 -0800
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 08:45 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 08:50 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:34 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-12-02 10:20 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:04 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 11:59 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:44 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 13:23 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-12-02 15:12 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-03 17:35 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 10:31 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 12:01 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 13:53 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 14:59 +0200
Re: Are stack machines inherently faster? minforth@arcor.de - 2017-01-09 08:15 -0800
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 19:33 +0100
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-12-02 21:09 -1000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-03 13:01 +0100
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 14:51 +0000
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-02 04:28 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-25 16:10 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-25 16:51 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-26 15:09 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-26 13:03 +0100
Re: Are stack machines inherently faster? franck.bensusan@gmail.com - 2016-11-27 10:11 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 16:00 +0000
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-24 22:44 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-24 23:11 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 16:38 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-25 07:28 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-25 04:24 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-25 14:37 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-26 10:54 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 10:56 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:27 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 11:42 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:35 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-22 17:43 +1100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-22 12:51 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 13:30 -0800
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-18 20:27 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:23 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-17 12:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? Manuel Rodriguez <aa5@gmx.net> - 2016-11-28 11:00 -0800
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-11-28 16:10 -0500
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 00:46 -0600
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 02:01 -0500
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-12-01 13:01 -0500
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-03 17:15 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 02:29 -0500
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-04 03:41 -0600
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 10:10 -0500
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 17:16 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-28 13:33 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:17 +0100
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 09:17 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 14:46 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:44 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 18:39 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-30 15:00 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 18:42 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:26 -1000
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-28 23:17 +0100 |
| Message-ID | <o1iadc$p26$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52931 |
In article <87eg1v8f2q.fsf@nightsong.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Manuel Rodriguez <aa5@gmx.net> writes: >> The idea is, to compare a stackmachine like the GA144 chipset with a >> normal CPU or a ASIC ... stackmachine have no significant advantage >> to ASIC mining so it makes no sense to switch to forth only for speed >> reasons. > >Of course an ASIC will be faster. Much more interesting is how GA144 >compares to a normal CPU or FPGA with a comparable fab process. http://www.greenarraychips.com/home/documents/greg/PB001-100503-GA144-1-10.pdf After 6 years, still PRELIMINARY. What was the last time, someone tried to purchase one? 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 | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-29 09:17 -0800 |
| Message-ID | <1d0f8bd6-5c05-4e71-9b35-1ac8fb84dad8@googlegroups.com> |
| In reply to | #52931 |
On Monday, November 28, 2016 at 2:33:35 PM UTC-7, Paul Rubin wrote: > Manuel Rodriguez <aa5@gmx.net> writes: > > The idea is, to compare a stackmachine like the GA144 chipset with a > > normal CPU or a ASIC ... stackmachine have no significant advantage > > to ASIC mining so it makes no sense to switch to forth only for speed > > reasons. > > Of course an ASIC will be faster. Much more interesting is how GA144 > compares to a normal CPU or FPGA with a comparable fab process. Since the GA144 is built on 180nm and CPUs and FPGAs are built on much smaller process, we may never know. Every time I've tried to justify a GA144 in a project, I could never do it. I think, though, that the GA144's claim to fame is power savings through asynchronous logic. Chips are getting so dense nowadays that you can only pack circuits so tightly because of the heat they generate. Async processing solves this. Unfortunately, making tiny little Forth machines throws away the efficiency gain by simulating the hardware you want instead of implementing it directly. OKAD should be used to design cores that people want, such as GPUs. Specialized processing, such as the GPU in your phone, is what's keeping Moore's Law alive. The cost per computation is still halving every 18 months even though process shrinks are approaching a dead end because more and more processing is done on dedicated hardware rather than general purpose CPUs. Speaking of Moore's Law, the cost per calculation curve goes back through vacuum tubes, relays, and gears to the quill pen. In the quill pen domain, it goes back through the discovery of ever more powerful mathematical methods. For all we know, it could go back to people writing tally marks on a cave wall. BTW, the Moore's Law expression of 2^1.5*y is curiously close to Phi^y. It could be that cost per computation goes down by the golden ratio Phi year after year as one of nature's Fibonacci growth spirals. If you like a little mysticism with your computing.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-29 14:46 -0500 |
| Message-ID | <o1klsg$gcd$1@dont-email.me> |
| In reply to | #52959 |
On 11/29/2016 12:17 PM, Brad Eckert wrote: > On Monday, November 28, 2016 at 2:33:35 PM UTC-7, Paul Rubin wrote: >> Manuel Rodriguez <aa5@gmx.net> writes: >>> The idea is, to compare a stackmachine like the GA144 chipset >>> with a normal CPU or a ASIC ... stackmachine have no significant >>> advantage to ASIC mining so it makes no sense to switch to forth >>> only for speed reasons. >> >> Of course an ASIC will be faster. Much more interesting is how >> GA144 compares to a normal CPU or FPGA with a comparable fab >> process. > > Since the GA144 is built on 180nm and CPUs and FPGAs are built on > much smaller process, we may never know. Every time I've tried to > justify a GA144 in a project, I could never do it. I think, though, > that the GA144's claim to fame is power savings through asynchronous > logic. I think the low power aspect of the GA144 is greatly overstated. While it looks good on paper, there are other aspects of the GA144 that reduce the benefit. For example, to communicate, any nodes that are not adjacent must use other nodes as passthroughs. Each running node uses some mA while running so the impact can be considerable in some designs. > Chips are getting so dense nowadays that you can only pack > circuits so tightly because of the heat they generate. Async > processing solves this. Async processors does nothing to solve this. The circuit is only low power when it is not running. If you have trouble getting rid of the heat when running full tilt you have a chip that you can't use to its full capacity. > Unfortunately, making tiny little Forth > machines throws away the efficiency gain by simulating the hardware > you want instead of implementing it directly. OKAD should be used to > design cores that people want, such as GPUs. I'm not sure what you mean by this. A stack processor is a processor the same as any other. Why do you need to simulate hardware on it? > Specialized processing, such as the GPU in your phone, is what's > keeping Moore's Law alive. The cost per computation is still halving > every 18 months even though process shrinks are approaching a dead > end because more and more processing is done on dedicated hardware > rather than general purpose CPUs. I don't follow this conclusion either. Why would Moore's law only apply to CPUs and not other hardware? > Speaking of Moore's Law, the cost per calculation curve goes back > through vacuum tubes, relays, and gears to the quill pen. In the > quill pen domain, it goes back through the discovery of ever more > powerful mathematical methods. For all we know, it could go back to > people writing tally marks on a cave wall. BTW, the Moore's Law > expression of 2^1.5*y is curiously close to Phi^y. It could be that > cost per computation goes down by the golden ratio Phi year after > year as one of nature's Fibonacci growth spirals. If you like a > little mysticism with your computing. I'm a bit lost. The golden ratio is around 1.6. 2^1.5 is 2.8. That's not very close. I think your formula should have been 2^(y/1.5). That would be 1.587^y which is very close to the golden ratio. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-29 13:44 -0800 |
| Message-ID | <dbeb1b1a-f5e4-4494-a7a2-c552c64fdc4e@googlegroups.com> |
| In reply to | #52965 |
On Tuesday, November 29, 2016 at 12:46:38 PM UTC-7, rickman wrote: > On 11/29/2016 12:17 PM, Brad Eckert wrote: > > Unfortunately, making tiny little Forth > > machines throws away the efficiency gain by simulating the hardware > > you want instead of implementing it directly. OKAD should be used to > > design cores that people want, such as GPUs. > > I'm not sure what you mean by this. A stack processor is a processor > the same as any other. Why do you need to simulate hardware on it? > Take for example a digital filter I coded in 486 assembly. Lots of code is spent moving data around when a few DSP instructions would have done the job. The way I see it, I'm simulating DSP hardware. In fact, if it had to be crazy fast, real hardware could execute a pipelined version in one clock cycle. Instead, I simulate that with code. > > > Specialized processing, such as the GPU in your phone, is what's > > keeping Moore's Law alive. The cost per computation is still halving > > every 18 months even though process shrinks are approaching a dead > > end because more and more processing is done on dedicated hardware > > rather than general purpose CPUs. > > I don't follow this conclusion either. Why would Moore's law only apply > to CPUs and not other hardware? > There are various versions of Moore's Law. The cost per computation is the one that goes back to mechanical calculating machines. People are always saying Moore's law will poop out somewhere below 10nm, but I think efficiency improvements will push that out a couple of decades. The CPU makers sometimes give apps a huge performance boost (at not much extra cost) by adding custom instruction set extensions for crypto or multimedia. The size of the consumer electronics industry will support the shift to more hardware-based solutions. The case today is that designers have more transistors than they know what to do with. The easiest thing to do, but far from the most efficient, is put multiple CPU cores on a chip. > > > Speaking of Moore's Law, the cost per calculation curve goes back > > through vacuum tubes, relays, and gears to the quill pen. In the > > quill pen domain, it goes back through the discovery of ever more > > powerful mathematical methods. For all we know, it could go back to > > people writing tally marks on a cave wall. BTW, the Moore's Law > > expression of 2^1.5*y is curiously close to Phi^y. It could be that > > cost per computation goes down by the golden ratio Phi year after > > year as one of nature's Fibonacci growth spirals. If you like a > > little mysticism with your computing. > > I'm a bit lost. The golden ratio is around 1.6. 2^1.5 is 2.8. That's > not very close. I think your formula should have been 2^(y/1.5). That > would be 1.587^y which is very close to the golden ratio. Derp. Mistranslated "doubles every 18 months".
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-29 18:39 -0500 |
| Message-ID | <o1l3hr$66f$1@dont-email.me> |
| In reply to | #52967 |
On 11/29/2016 4:44 PM, Brad Eckert wrote: > On Tuesday, November 29, 2016 at 12:46:38 PM UTC-7, rickman wrote: >> On 11/29/2016 12:17 PM, Brad Eckert wrote: >>> Unfortunately, making tiny little Forth machines throws away the >>> efficiency gain by simulating the hardware you want instead of >>> implementing it directly. OKAD should be used to design cores >>> that people want, such as GPUs. >> >> I'm not sure what you mean by this. A stack processor is a >> processor the same as any other. Why do you need to simulate >> hardware on it? >> > > Take for example a digital filter I coded in 486 assembly. Lots of > code is spent moving data around when a few DSP instructions would > have done the job. The way I see it, I'm simulating DSP hardware. In > fact, if it had to be crazy fast, real hardware could execute a > pipelined version in one clock cycle. Instead, I simulate that with > code. I still don't know what you were referring to in the original statement. What "efficiency gain" were you talking about that gets thrown away? >>> Specialized processing, such as the GPU in your phone, is what's >>> keeping Moore's Law alive. The cost per computation is still >>> halving every 18 months even though process shrinks are >>> approaching a dead end because more and more processing is done >>> on dedicated hardware rather than general purpose CPUs. >> >> I don't follow this conclusion either. Why would Moore's law only >> apply to CPUs and not other hardware? >> > > There are various versions of Moore's Law. The cost per computation > is the one that goes back to mechanical calculating machines. People > are always saying Moore's law will poop out somewhere below 10nm, but > I think efficiency improvements will push that out a couple of > decades. The CPU makers sometimes give apps a huge performance boost > (at not much extra cost) by adding custom instruction set extensions > for crypto or multimedia. The size of the consumer electronics > industry will support the shift to more hardware-based solutions. The > case today is that designers have more transistors than they know > what to do with. The easiest thing to do, but far from the most > efficient, is put multiple CPU cores on a chip. Moore's law only referred to the number of transistors on a chip. As far as I know, that still holds true today. Again, I don't know what "efficiency gains" you are talking about. The part I am really confused about is about the process shrinks approaching a dead end because of dedicated hardware. Hardware of all types benefit from smaller transistors. >>> Speaking of Moore's Law, the cost per calculation curve goes >>> back through vacuum tubes, relays, and gears to the quill pen. In >>> the quill pen domain, it goes back through the discovery of ever >>> more powerful mathematical methods. For all we know, it could go >>> back to people writing tally marks on a cave wall. BTW, the >>> Moore's Law expression of 2^1.5*y is curiously close to Phi^y. It >>> could be that cost per computation goes down by the golden ratio >>> Phi year after year as one of nature's Fibonacci growth spirals. >>> If you like a little mysticism with your computing. >> >> I'm a bit lost. The golden ratio is around 1.6. 2^1.5 is 2.8. >> That's not very close. I think your formula should have been >> 2^(y/1.5). That would be 1.587^y which is very close to the golden >> ratio. > > Derp. Mistranslated "doubles every 18 months". What is "Derp."? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-30 15:00 -0800 |
| Message-ID | <9856432c-827b-4688-9961-e91ba386bf04@googlegroups.com> |
| In reply to | #52971 |
On Tuesday, November 29, 2016 at 4:39:54 PM UTC-7, rickman wrote: > > I still don't know what you were referring to in the original statement. > What "efficiency gain" were you talking about that gets thrown away? > Each code a highly tuned, compact layout of a little CPU. Very energy efficient. But simulating a wire to make the layout work isn't very efficient. And speaking of async computing being much better, maybe it's not. Clock trees are only a problem due to their implementation. That can change. Besides, things like Booth multipliers are fabrics of gates that have no clock. They're only synchronous around the edges. Chuck is being, well, Chuck. He's all cowboy. He could have gone back to build up Forth Inc after his foray into hardware, but that wouldn't be very cowboy. > > >>> Specialized processing, such as the GPU in your phone, is what's > >>> keeping Moore's Law alive. The cost per computation is still > >>> halving every 18 months even though process shrinks are > >>> approaching a dead end because more and more processing is done > >>> on dedicated hardware rather than general purpose CPUs. > >> > >> I don't follow this conclusion either. Why would Moore's law only > >> apply to CPUs and not other hardware? > >> > > > > There are various versions of Moore's Law. The cost per computation > > is the one that goes back to mechanical calculating machines. People > > are always saying Moore's law will poop out somewhere below 10nm, but > > I think efficiency improvements will push that out a couple of > > decades. The CPU makers sometimes give apps a huge performance boost > > (at not much extra cost) by adding custom instruction set extensions > > for crypto or multimedia. The size of the consumer electronics > > industry will support the shift to more hardware-based solutions. The > > case today is that designers have more transistors than they know > > what to do with. The easiest thing to do, but far from the most > > efficient, is put multiple CPU cores on a chip. > > Moore's law only referred to the number of transistors on a chip. As > far as I know, that still holds true today. Again, I don't know what > "efficiency gains" you are talking about. > > The part I am really confused about is about the process shrinks > approaching a dead end because of dedicated hardware. Hardware of all > types benefit from smaller transistors. > It's probably in the way I process generalities. It's more a phenomenon related to Moore's Law. Gordon Moore was a transistor guy who noticed the number of transistors on a chip following an exponential trend. The human cost per computation can be shown to follow the same curve, approximately 1.618^-y. Y goes up, cost goes down. That curve goes back a century at least. If you include the mathematicians and their discoveries, maybe much further. My point is that as it gets harder to make transistors cheaper, and Gordon Moore's law flattens, the difference will be made up in the way transistors are used. The big silicon economy can afford to put resources into using them more efficiently. Using them to make a large SRAM for a general purpose processor does a little something for everyone. Lots of room for improvement for specialized needs. More customers with deep pockets means further decreases in cost per computation even if further process shrinks stop. The real question is what comes after the process shrinks have stopped and the transistors are used as efficiently as possible? Will the 1.618^-y still hold? What if it's a metaphysical thing?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-30 18:42 -0500 |
| Message-ID | <o1no1m$jaj$1@dont-email.me> |
| In reply to | #52997 |
On 11/30/2016 6:00 PM, Brad Eckert wrote: > On Tuesday, November 29, 2016 at 4:39:54 PM UTC-7, rickman wrote: >> >> I still don't know what you were referring to in the original >> statement. What "efficiency gain" were you talking about that gets >> thrown away? >> > Each code a highly tuned, compact layout of a little CPU. Very energy > efficient. But simulating a wire to make the layout work isn't very > efficient. And speaking of async computing being much better, maybe > it's not. Clock trees are only a problem due to their implementation. > That can change. Besides, things like Booth multipliers are fabrics > of gates that have no clock. They're only synchronous around the > edges. So you mean a software driven device loses efficiency over dedicated hardware? Every approach has shortcomings. Comms is a problem in the GA144 as they have to travel through a path of nodes to get anywhere. That works ok for a data flow application or for some types of signal processing, especially if a fast signal is being decimated. > Chuck is being, well, Chuck. He's all cowboy. He could have gone back > to build up Forth Inc after his foray into hardware, but that > wouldn't be very cowboy. I'm not aware that Forth, Inc needs building up. Aren't they doing ok as it is? Certainly MPE is doing ok as well. >>>>> Specialized processing, such as the GPU in your phone, is >>>>> what's keeping Moore's Law alive. The cost per computation is >>>>> still halving every 18 months even though process shrinks >>>>> are approaching a dead end because more and more processing >>>>> is done on dedicated hardware rather than general purpose >>>>> CPUs. >>>> >>>> I don't follow this conclusion either. Why would Moore's law >>>> only apply to CPUs and not other hardware? >>>> >>> >>> There are various versions of Moore's Law. The cost per >>> computation is the one that goes back to mechanical calculating >>> machines. People are always saying Moore's law will poop out >>> somewhere below 10nm, but I think efficiency improvements will >>> push that out a couple of decades. The CPU makers sometimes give >>> apps a huge performance boost (at not much extra cost) by adding >>> custom instruction set extensions for crypto or multimedia. The >>> size of the consumer electronics industry will support the shift >>> to more hardware-based solutions. The case today is that >>> designers have more transistors than they know what to do with. >>> The easiest thing to do, but far from the most efficient, is put >>> multiple CPU cores on a chip. >> >> Moore's law only referred to the number of transistors on a chip. >> As far as I know, that still holds true today. Again, I don't know >> what "efficiency gains" you are talking about. >> >> The part I am really confused about is about the process shrinks >> approaching a dead end because of dedicated hardware. Hardware of >> all types benefit from smaller transistors. >> > > It's probably in the way I process generalities. It's more a > phenomenon related to Moore's Law. Gordon Moore was a transistor guy > who noticed the number of transistors on a chip following an > exponential trend. The human cost per computation can be shown to > follow the same curve, approximately 1.618^-y. Y goes up, cost goes > down. That curve goes back a century at least. If you include the > mathematicians and their discoveries, maybe much further. > > My point is that as it gets harder to make transistors cheaper, and > Gordon Moore's law flattens, the difference will be made up in the > way transistors are used. The big silicon economy can afford to put > resources into using them more efficiently. Using them to make a > large SRAM for a general purpose processor does a little something > for everyone. Lots of room for improvement for specialized needs. > More customers with deep pockets means further decreases in cost per > computation even if further process shrinks stop. Are you referring to the NRE associated with developing the next process node? That *will* have a limit, maybe not technically, but economically. It was over 10 years ago the mask set cost rose to over a million dollars. That makes it hard to justify a custom chip. Foundries cost billions of dollars. That makes it hard to justify a switch to a new node. At some point the cost of developing and switching to the next node will be so large the amortization will make the next node chips as costly as the present node chips and there will be no reason to continue. > The real question is what comes after the process shrinks have > stopped and the transistors are used as efficiently as possible? Will > the 1.618^-y still hold? What if it's a metaphysical thing? I'm not sure why it would be a metaphysical thing. There may be new paradigms that facilitate processing with greatly reduced costs. Maybe instead of everyone having processing in their hands, they will have great comms and all the real processing money will go into remote servers. Then the economics are a bit different. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-30 14:26 -1000 |
| Message-ID | <ebqdnQ8lOpi786LFnZ2dnUU7-VnNnZ2d@supernews.com> |
| In reply to | #52999 |
On 11/30/16 1:42 PM, rickman wrote: > On 11/30/2016 6:00 PM, Brad Eckert wrote: ... >> Chuck is being, well, Chuck. He's all cowboy. He could have gone back >> to build up Forth Inc after his foray into hardware, but that >> wouldn't be very cowboy. > > I'm not aware that Forth, Inc needs building up. Aren't they doing ok > as it is? Certainly MPE is doing ok as well. Doing fine, thank you! Several major contracts under way. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-29 13:58 -0500 |
| Message-ID | <o1kj23$3ia$2@dont-email.me> |
| In reply to | #52931 |
On 11/28/2016 4:33 PM, Paul Rubin wrote: > Manuel Rodriguez <aa5@gmx.net> writes: >> The idea is, to compare a stackmachine like the GA144 chipset with a >> normal CPU or a ASIC ... stackmachine have no significant advantage >> to ASIC mining so it makes no sense to switch to forth only for speed >> reasons. > > Of course an ASIC will be faster. Much more interesting is how GA144 > compares to a normal CPU or FPGA with a comparable fab process. Why is an ASIC automatically faster? -- Rick C
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.forth
csiph-web