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 | 20 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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-11-22 17:43 +1100 |
| Message-ID | <o10pen$p8s$1@gioia.aioe.org> |
| In reply to | #52736 |
Stephen Pelc wrote: > On Sat, 19 Nov 2016 11:29:47 +1100, "HAA" <someone@microsoft.com> > wrote: > > >No doubt your client could also demonstrate that VFX is faster than > >SwiftForth. Yet Forth Inc still exists and presumably gets work. > >The model which states 'fastest is best' appears not to follow. > >What happens when 1.5 seconds is not good enough? Discard Forth > >for C? That's not unreasonable either. CPU, clock, language, facilities, > >I rank greater than compiler technology. Get those wrong and it won't > >matter whether it's DTC or NCC. > > I was asked a question about performance and I answered it. You responded to a comment in which the poster considered ITC performance good enough with an 'apples and oranges' speed comparison of DTC vs. NCC. > If > you want to compare performance between two Forth systems, try > downloading the MPE benchmark suite ... and using it. No thanks. Your prospective clients may wish to do so.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-11-22 12:51 +0000 |
| Message-ID | <MPG.329e4fad2531d90e9896cb@news.virginmedia.com> |
| In reply to | #52805 |
In article <o10pen$p8s$1@gioia.aioe.org>, someone@microsoft.com says... > > Stephen Pelc wrote: > > On Sat, 19 Nov 2016 11:29:47 +1100, "HAA" <someone@microsoft.com> > > wrote: > > > > >No doubt your client could also demonstrate that VFX is faster than > > >SwiftForth. Yet Forth Inc still exists and presumably gets work. > > >The model which states 'fastest is best' appears not to follow. > > >What happens when 1.5 seconds is not good enough? Discard Forth > > >for C? That's not unreasonable either. CPU, clock, language, facilities, > > >I rank greater than compiler technology. Get those wrong and it won't > > >matter whether it's DTC or NCC. > > > > I was asked a question about performance and I answered it. > > You responded to a comment in which the poster considered ITC > performance good enough with an 'apples and oranges' speed > comparison of DTC vs. NCC. > > > If > > you want to compare performance between two Forth systems, try > > downloading the MPE benchmark suite ... and using it. > > No thanks. Your prospective clients may wish to do so. Perhaps if you all considered application efficiency rather than speed you could all stop waffling. VFX is by far the best commercial Forth I have ever seen and the only one I would consider for any commercial forth project. I'l say that again - the only one. Is it better than using another language? - well that depends on factors totally unrelated to the language itself. I'll say that again as well - totally unrelated. Of course wringing the best out of a processor is important but it's pretty pointless if there's no support, no backup no documentation no toolchain. I've just been looking at jims selection for our project and it saddens me this was the best he could find for all manner of reasons. Not because it's bad but just because it's so promising and yet unfinished while people are poncing about with benchnmarks that are nothing of the sort anyway and it seems still worrying about whether to use upper or lower case. (I was convinced jim was extracting the P when he told me this) Are stack machines inherently faster? The first thing you all need to answer is "faster at what?" and does the "what" you come up with have any validity in the real world? -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-24 13:30 -0800 |
| Message-ID | <48b5c229-1a20-40cb-ba1c-ff7eef6246ea@googlegroups.com> |
| In reply to | #52813 |
On Tuesday, November 22, 2016 at 5:53:35 AM UTC-7, john wrote: > Perhaps if you all considered application efficiency rather than speed you could > all stop waffling. VFX is by far the best commercial Forth I have ever seen > and the only one I would consider for any commercial forth project. > I'l say that again - the only one. > > Is it better than using another language? - well that depends on factors > totally unrelated to the language itself. > I'll say that again as well - totally unrelated. > > Of course wringing the best out of a processor is important but it's pretty > pointless if there's no support, no backup no documentation no toolchain. I agree that VFX is very impressive. I think that Stephen Pelc is a very talented programmer. I also think that it is a waste of talent to write an ANS-Forth compiler. QBASIC was better than PolyForth in every way. What qualification did Elizabeth Rather have for writing the ANS-Forth Standard and imposing it on the entire Forth community? None! Way back in 1984 when I first got into Forth, I could see that Forth-83 had a lot of problems. I was told that a new standard was coming and that it would fix these problems. What I didn't realize is that Charles Moore had been kicked out of Forth Inc. in 1982 --- the Forth-83 standard was written by Forth Inc. without his assistance and that was why it was no good --- in 1994 the ANS-Forth standard was written by Forth Inc. without his assistance and that is why it was no good either. In 1984 I did not imagine a future in which I myself would have to write a Forth standard in the year 2016. I really expected some leadership in the Forth community, but none was ever forth-coming (so to speak). What is sad about this is that most of the ideas in Straight Forth are obvious. Of course, I think there are some clever parts (I would think that; I wrote it!) --- honestly though, most of it is very straight-forward (hence the name: Straight Forth) --- anybody with a modicum of Forth application-programming experience would have thought up most of this easily. The two built-in data-structures are chains and arrays --- what else would anybody consider? --- this is an obvious design! > Are stack machines inherently faster? > The first thing you all need to answer is "faster at what?" > and does the "what" you come up with have any validity in the real world? When Testra started the MiniForth project, they were using an 80c320 (LMI Forth code with a heavy dose of assembly-language) in their motion-control board for the laser-etcher --- the competition was using an MC68000 (C code with some assembly-language) in their motion-control board for the laser-etcher --- Testra's board was less expensive, but it was not competitive in regard to speed. The MiniForth board was both less-expensive than the MC68000 board (about the same cost as the 80c320 board) and significantly faster than the MC68000. The competition just abandoned the laser-etcher market because they were no longer competitive in any way. Does that sound like "validity" to you? Writing MFX was something that I was proud of. ANS-Forth killed Forth though --- nobody ever took Forth seriously after ANS-Forth became the Standard.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-18 20:27 -0800 |
| Message-ID | <87k2c0ccwx.fsf@nightsong.com> |
| In reply to | #52709 |
stephen@mpeforth.com (Stephen Pelc) writes: > One of our clients has a recalculation that used to take 15 or so > seconds on our DTC ProForth for Windows. The boss excitedly took > me to his office to show that the conversion to VFX Forth took > about 1.5 seconds. To him, that was important. Of course this happens sometimes. In the programs that most people I know work on, it doesn't happen often: the resource constraints are rarely computational. In the application you mentioned, if it's spreadsheet-like, I wonder whether algorithmic improvements (like finding the dependency graph between formulas and updating only the necessary cells after a change) might have helped more than better code generation. OTOH you may already have been doing that.
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-27 00:23 -0800 |
| Message-ID | <75dd1116-dbf5-4a77-ab00-0468d6b61fc1@googlegroups.com> |
| In reply to | #52709 |
On Friday, November 18, 2016 at 6:17:01 AM UTC-5, Stephen Pelc wrote: > On Thu, 17 Nov 2016 15:58:33 -0800, Paul Rubin > <no.email@nospam.invalid> wrote: > > >I don't know about Foxaudio, but I'd say "very well" means the ITC > >performance is enough to satisfy users' real-world requirements. Most > >of my stuff these days is written in Python and it's fast enough for my > >purposes, and Gforth-itc is probably >10x faster than Python. I've > >never written a Forth program that wasn't a benchmark, that used enough > >computation time for me to notice. > > One of our clients has a recalculation that used to take 15 or so > seconds on our DTC ProForth for Windows. The boss excitedly took > me to his office to show that the conversion to VFX Forth took > about 1.5 seconds. To him, that was important. > > These days, there are plenty of algorithms that do not follow the > "90% of the time in 10% of the code" model. > > 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 do you code in gforth on debian? do you think websites can be easily made with such?
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-27 00:22 -0800 |
| Message-ID | <638f6ed5-6850-46c6-9243-820a2b8bc72a@googlegroups.com> |
| In reply to | #52705 |
On Thursday, November 17, 2016 at 6:58:35 PM UTC-5, Paul Rubin wrote: > mhx@iae.nl writes: > >> My own experience is that in real world projects, even ITC Forth > >> performed very well, if you allow for a hand coded primitive ... > > It depends on what you call "very well." I would say that you're > > describing a popular Forth myth. It is not true. > > I don't know about Foxaudio, but I'd say "very well" means the ITC > performance is enough to satisfy users' real-world requirements. Most > of my stuff these days is written in Python and it's fast enough for my > purposes, and Gforth-itc is probably >10x faster than Python. I've > never written a Forth program that wasn't a benchmark, that used enough > computation time for me to notice. > > Even big problems that need a lot of computation can often be > parallelized. Computers are cheap and it's often better business to > just buy more of them, than to increase software development costs or > decrease maintainability. > > > CLF threads that posed problems that piqued people's interest and > > resulted in a flurry of smart algorithmic tricks > > Sure, good algorithms can produce a far bigger speedup than careful > optimization of dumb algorithms can possibly hope to. > > > that would have been a lot more cumbersome to come up with, design, > > and test in other languages. > > I'd be interested in seeing an example. so use forth and throw hardware at the problem?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-17 12:50 -0800 |
| Message-ID | <b7421d56-33cc-4ba6-a920-38a940f0f777@googlegroups.com> |
| In reply to | #52698 |
On Thursday, November 17, 2016 at 9:08:08 AM UTC-7, foxaudio...@gmail.com wrote: > My own experience is that in real world projects, even ITC Forth performed very > well, if you allow for a hand coded primitive or two or three... This works well with a fat Standard, because you have more primitives. Straight Forth is a fat Standard because it includes two data-structures: the chain and the array. ANS-Forth is a thin Standard because it doesn't include any data-structures, so all data-structures have to be custom written in Forth by the application programmer. This is why I'm expecting the ITC version of Straight Forth to generate code that is about twice the speed of SwiftForth code (SwiftForth is STC but has very little optimization) --- of course, I'm also expecting that 99% of Straight Forth programs will use the built-in data-structures --- if you need a different data-structure, and you write it yourself in Forth, then the fact that the Forth code is ITC is going to cause it to be slow (as compared to hand-written assembly-language). Also, despite the fact that Straight Forth is a fat Standard and ANS-Forth is a thin Standard, I expect Straight Forth to be smaller than ANS-Forth --- this is because I discard all of the weird and useless cruft that is in ANS-Forth --- for example, DO loops get discarded, and I don't care if they were invented by Charles Moore in the 1970s and everybody expects them to be part of any Forth.
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-27 00:22 -0800 |
| Message-ID | <f031836e-6d42-4670-a10e-13e5d207c8b1@googlegroups.com> |
| In reply to | #52704 |
On Thursday, November 17, 2016 at 3:50:17 PM UTC-5, hughag...@gmail.com wrote: > On Thursday, November 17, 2016 at 9:08:08 AM UTC-7, foxaudio...@gmail.com wrote: > > My own experience is that in real world projects, even ITC Forth performed very > > well, if you allow for a hand coded primitive or two or three... > > This works well with a fat Standard, because you have more primitives. > > Straight Forth is a fat Standard because it includes two data-structures: the chain and the array. ANS-Forth is a thin Standard because it doesn't include any data-structures, so all data-structures have to be custom written in Forth by the application programmer. This is why I'm expecting the ITC version of Straight Forth to generate code that is about twice the speed of SwiftForth code (SwiftForth is STC but has very little optimization) --- of course, I'm also expecting that 99% of Straight Forth programs will use the built-in data-structures --- if you need a different data-structure, and you write it yourself in Forth, then the fact that the Forth code is ITC is going to cause it to be slow (as compared to hand-written assembly-language). > > Also, despite the fact that Straight Forth is a fat Standard and ANS-Forth is a thin Standard, I expect Straight Forth to be smaller than ANS-Forth --- this is because I discard all of the weird and useless cruft that is in ANS-Forth --- for example, DO loops get discarded, and I don't care if they were invented by Charles Moore in the 1970s and everybody expects them to be part of any Forth. what forth exactly do you use? do you run any blog or website on forth?
[toc] | [prev] | [next] | [standalone]
| From | Manuel Rodriguez <aa5@gmx.net> |
|---|---|
| Date | 2016-11-28 11:00 -0800 |
| Message-ID | <a9e5c3e0-b65e-4c70-a8bf-da3ccf62687b@googlegroups.com> |
| In reply to | #52599 |
Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph self: > I am noticing 15,000 context switches per second on my debian testing linux 4.7 6 cpu amd fx machine. > > Are stack chips misc (?) and thus since fewer instructions, a 300mhz chip that is a stack machine gets a lot more done per cycle? or does less work to accomplish the same thing? Recently there was here in the newsgroup a similar question. The thread developed after a while into a direction which uses Bitcoin-mining as perforamance index. The idea is, to compare a stackmachine like the GA144 chipset with a normal CPU or a ASIC in advance that the stackmachine is so fast, that it will outperform all other solution. The conclusion of the thread in the past was, that stackmachine have no significant advantage to ASIC mining so it makes no sense to switch to forth only for speed reasons.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-11-28 16:10 -0500 |
| Message-ID | <o1i6fl$tat$1@gioia.aioe.org> |
| In reply to | #52928 |
On 2016-11-28 2:00 PM, Manuel Rodriguez wrote: > Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph self: >> I am noticing 15,000 context switches per second on my debian >> testing linux 4.7 6 cpu amd fx machine. >> >> Are stack chips misc (?) and thus since fewer instructions, a >> 300mhz chip that is a stack machine gets a lot more done per cycle? >> or does less work to accomplish the same thing? > > Recently there was here in the newsgroup a similar question. The > thread developed after a while into a direction which uses > Bitcoin-mining as perforamance index. The idea is, to compare a > stackmachine like the GA144 chipset with a normal CPU or a ASIC in > advance that the stackmachine is so fast, that it will outperform all > other solution. The conclusion of the thread in the past was, that > stackmachine have no significant advantage to ASIC mining so it makes > no sense to switch to forth only for speed reasons. > As one more data point. In the ISA development work I have done stack machines can often have very compact code but have slower execution in the benchmarks we have run. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-29 13:58 -0500 |
| Message-ID | <o1kj18$3ia$1@dont-email.me> |
| In reply to | #52930 |
On 11/28/2016 4:10 PM, Walter Banks wrote: > On 2016-11-28 2:00 PM, Manuel Rodriguez wrote: >> Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph self: >>> I am noticing 15,000 context switches per second on my debian >>> testing linux 4.7 6 cpu amd fx machine. >>> >>> Are stack chips misc (?) and thus since fewer instructions, a >>> 300mhz chip that is a stack machine gets a lot more done per cycle? >>> or does less work to accomplish the same thing? >> >> Recently there was here in the newsgroup a similar question. The >> thread developed after a while into a direction which uses >> Bitcoin-mining as perforamance index. The idea is, to compare a >> stackmachine like the GA144 chipset with a normal CPU or a ASIC in >> advance that the stackmachine is so fast, that it will outperform all >> other solution. The conclusion of the thread in the past was, that >> stackmachine have no significant advantage to ASIC mining so it makes >> no sense to switch to forth only for speed reasons. >> > > As one more data point. In the ISA development work I have done stack > machines can often have very compact code but have slower execution in > the benchmarks we have run. I don't know of any particular feature of a stack machine that allows it to have more compact code. The way they are often used to implement Forth may result in smaller code as the typical Forth program uses smaller modules with little overhead that can encourage reuse. Why do you say stack machines result in smaller code? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-11-30 00:46 -0600 |
| Message-ID | <o1lshk$ts6$1@dont-email.me> |
| In reply to | #52962 |
On 11/29/2016 12:58 PM, rickman wrote: > On 11/28/2016 4:10 PM, Walter Banks wrote: >> On 2016-11-28 2:00 PM, Manuel Rodriguez wrote: >>> Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph self: >>>> I am noticing 15,000 context switches per second on my debian >>>> testing linux 4.7 6 cpu amd fx machine. >>>> >>>> Are stack chips misc (?) and thus since fewer instructions, a >>>> 300mhz chip that is a stack machine gets a lot more done per cycle? >>>> or does less work to accomplish the same thing? >>> >>> Recently there was here in the newsgroup a similar question. The >>> thread developed after a while into a direction which uses >>> Bitcoin-mining as perforamance index. The idea is, to compare a >>> stackmachine like the GA144 chipset with a normal CPU or a ASIC in >>> advance that the stackmachine is so fast, that it will outperform all >>> other solution. The conclusion of the thread in the past was, that >>> stackmachine have no significant advantage to ASIC mining so it makes >>> no sense to switch to forth only for speed reasons. >>> >> >> As one more data point. In the ISA development work I have done stack >> machines can often have very compact code but have slower execution in >> the benchmarks we have run. > > I don't know of any particular feature of a stack machine that allows it > to have more compact code. The way they are often used to implement > Forth may result in smaller code as the typical Forth program uses > smaller modules with little overhead that can encourage reuse. > > Why do you say stack machines result in smaller code? > One of the Forth CPUs I been playing with the ep32 packs 5 instructions to a 32 bit word, no statistics or anything but that has to save some space. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-30 02:01 -0500 |
| Message-ID | <o1ltek$f1$1@dont-email.me> |
| In reply to | #52978 |
On 11/30/2016 1:46 AM, Cecil Bayona wrote: > On 11/29/2016 12:58 PM, rickman wrote: >> On 11/28/2016 4:10 PM, Walter Banks wrote: >>> On 2016-11-28 2:00 PM, Manuel Rodriguez wrote: >>>> Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph self: >>>>> I am noticing 15,000 context switches per second on my debian >>>>> testing linux 4.7 6 cpu amd fx machine. >>>>> >>>>> Are stack chips misc (?) and thus since fewer instructions, a >>>>> 300mhz chip that is a stack machine gets a lot more done per cycle? >>>>> or does less work to accomplish the same thing? >>>> >>>> Recently there was here in the newsgroup a similar question. The >>>> thread developed after a while into a direction which uses >>>> Bitcoin-mining as perforamance index. The idea is, to compare a >>>> stackmachine like the GA144 chipset with a normal CPU or a ASIC in >>>> advance that the stackmachine is so fast, that it will outperform all >>>> other solution. The conclusion of the thread in the past was, that >>>> stackmachine have no significant advantage to ASIC mining so it makes >>>> no sense to switch to forth only for speed reasons. >>>> >>> >>> As one more data point. In the ISA development work I have done stack >>> machines can often have very compact code but have slower execution in >>> the benchmarks we have run. >> >> I don't know of any particular feature of a stack machine that allows it >> to have more compact code. The way they are often used to implement >> Forth may result in smaller code as the typical Forth program uses >> smaller modules with little overhead that can encourage reuse. >> >> Why do you say stack machines result in smaller code? >> > One of the Forth CPUs I been playing with the ep32 packs 5 instructions > to a 32 bit word, no statistics or anything but that has to save some > space. I don't follow at all. I have looked at instruction sizes from 4 bits to 18 bits. My consideration of instruction sizes indicates the amount of compression is fairly constant in that the smaller instructions are more limited. A larger instruction size allows for a lot more variation and so more can happen in a single instruction... or what happens is more tailored. For example, consider the variations of add, subtract, with and without carry. The GA144 dispenses with all that and just has an add instruction expecting the programmer to add other instructions to implement the variations. The resulting size of your code depends on whether you are utilizing the features available when a larger instruction size is used. If your code needs subtract as often as add and utilize carry such as in double precision operations. The observations I made were that code density is impacted more by the instruction set fitting the application more than anything else. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-12-01 13:01 -0500 |
| Message-ID | <o1pohf$13tl$1@gioia.aioe.org> |
| In reply to | #52979 |
On 2016-11-30 2:01 AM, rickman wrote: > On 11/30/2016 1:46 AM, Cecil Bayona wrote: >> On 11/29/2016 12:58 PM, rickman wrote: >>> On 11/28/2016 4:10 PM, Walter Banks wrote: >>>> On 2016-11-28 2:00 PM, Manuel Rodriguez wrote: >>>>> Am Montag, 14. November 2016 03:33:26 UTC+1 schrieb polymorph >>>>> self: >>>>>> I am noticing 15,000 context switches per second on my >>>>>> debian testing linux 4.7 6 cpu amd fx machine. >>>>>> >>>>>> Are stack chips misc (?) and thus since fewer instructions, >>>>>> a 300mhz chip that is a stack machine gets a lot more done >>>>>> per cycle? or does less work to accomplish the same thing? >>>>> >>>>> Recently there was here in the newsgroup a similar question. >>>>> The thread developed after a while into a direction which >>>>> uses Bitcoin-mining as perforamance index. The idea is, to >>>>> compare a stackmachine like the GA144 chipset with a normal >>>>> CPU or a ASIC in advance that the stackmachine is so fast, >>>>> that it will outperform all other solution. The conclusion of >>>>> the thread in the past was, that stackmachine have no >>>>> significant advantage to ASIC mining so it makes no sense to >>>>> switch to forth only for speed reasons. >>>>> >>>> >>>> As one more data point. In the ISA development work I have done >>>> stack machines can often have very compact code but have slower >>>> execution in the benchmarks we have run. >>> >>> I don't know of any particular feature of a stack machine that >>> allows it to have more compact code. The way they are often used >>> to implement Forth may result in smaller code as the typical >>> Forth program uses smaller modules with little overhead that can >>> encourage reuse. >>> >>> Why do you say stack machines result in smaller code? >>> >> One of the Forth CPUs I been playing with the ep32 packs 5 >> instructions to a 32 bit word, no statistics or anything but that >> has to save some space. > > I don't follow at all. I have looked at instruction sizes from 4 > bits to 18 bits. My consideration of instruction sizes indicates the > amount of compression is fairly constant in that the smaller > instructions are more limited. A larger instruction size allows for > a lot more variation and so more can happen in a single > instruction... or what happens is more tailored. For example, > consider the variations of add, subtract, with and without carry. > The GA144 dispenses with all that and just has an add instruction > expecting the programmer to add other instructions to implement the > variations. The resulting size of your code depends on whether you > are utilizing the features available when a larger instruction size > is used. If your code needs subtract as often as add and utilize > carry such as in double precision operations. > > The observations I made were that code density is impacted more by > the instruction set fitting the application more than anything else. > The comment came out experience we have had with ISA development. Part of it is the instruction packing possibilities some of it is the code generation tools that can take advantage of very good data flow analysis. The trade off between addressing fields and pure operation's favors operation only instructions for application code. All things being equal the execution turnout slower. We do know that this was so generally because of the overhead for the extra steps needed to execute code. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-03 17:15 -0800 |
| Message-ID | <6d25e14e-275c-47eb-b2d3-9c7380924e7f@googlegroups.com> |
| In reply to | #53017 |
On Thursday, December 1, 2016 at 11:01:22 AM UTC-7, Walter Banks wrote: > The comment came out experience we have had with ISA development. Part > of it is the instruction packing possibilities some of it is the code > generation tools that can take advantage of very good data flow > analysis. The trade off between addressing fields and pure operation's > favors operation only instructions for application code. > > All things being equal the execution turnout slower. We do know that > this was so generally because of the overhead for the extra steps needed > to execute code. > > w.. I designed the Stundurd processor given these assumptions: 1.) Register access is very fast compared than memory access. 2.) Registers are very expensive in terms of hardware resources, so you can't have a lot. 3.) It is difficult or impossible to support branching in assembly-language, although it is possible to have a conditional load of a register (like the CMOV instruction in x86). 4.) Code bloat has to be minimized because fetching opcodes out of the instruction stream is a big drain on speed. Some people (including yourself, as I recall), said that none of these assumptions are true now --- all of these assumptions were true in 1994 when the MiniForth was developed --- the world of custom processors has changed since then.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-12-04 02:29 -0500 |
| Message-ID | <20161204022950.04bb2190@_> |
| In reply to | #53065 |
On Sat, 3 Dec 2016 17:15:42 -0800 (PST) hughaguilar96@gmail.com wrote: > 2.) Registers are very expensive in terms of hardware resources, so > you can't have a lot. Why? Modern processors have large caches and multiple layers of them. There is no reason that a register file can't be just as large. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-04 03:41 -0600 |
| Message-ID | <y8ydnZBp1eIued7FnZ2dnUU7-XnNnZ2d@supernews.com> |
| In reply to | #53066 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > On Sat, 3 Dec 2016 17:15:42 -0800 (PST) > hughaguilar96@gmail.com wrote: > >> 2.) Registers are very expensive in terms of hardware resources, so >> you can't have a lot. > > Why? > > Modern processors have large caches and multiple layers of them. > There is no reason that a register file can't be just as large. https://lh3.googleusercontent.com/-Um9o8x0OulQ/VoFj0Mq2MqI/AAAAAAAAyPk/2twW9hihUvw/w500/chip-labeled.png It's quite impressive to look at the sheer size of the register file in a simple processor like the ARM1. The reason for this is that registers have to be very fast (so need big transistors to drive the lines) and they need to be multi-ported. Seen here, the register file (only 16 registers) is twice the size of the ALU. Caches can be made much smaller because they don't have to be anything like as fast and don't have to read or write many operands in a cycle. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-12-04 10:10 -0500 |
| Message-ID | <20161204101011.4cd9fe66@_> |
| In reply to | #53067 |
On Sun, 04 Dec 2016 03:41:07 -0600 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > > On Sat, 3 Dec 2016 17:15:42 -0800 (PST) > > hughaguilar96@gmail.com wrote: > > > >> 2.) Registers are very expensive in terms of hardware resources, so > >> you can't have a lot. > > > > Why? > > > > Modern processors have large caches and multiple layers of them. > > There is no reason that a register file can't be just as large. > > https://lh3.googleusercontent.com/-Um9o8x0OulQ/VoFj0Mq2MqI/AAAAAAAAyPk/2twW9hihUvw/w500/chip-labeled.png > > It's quite impressive to look at the sheer size of the register file > in a simple processor like the ARM1. The reason for this is that > registers have to be very fast (so need big transistors to drive the > lines) and they need to be multi-ported. Seen here, the register file > (only 16 registers) is twice the size of the ALU. Caches can be made > much smaller because they don't have to be anything like as fast and > don't have to read or write many operands in a cycle. > http://www.chip-architect.com/news/Real_Sao_Paolo_Shanghai_Nehalem_1600x784_.jpg https://randomascii.files.wordpress.com/2012/12/image1.png It appears to me that the caches can consume far more area than any other logic block. The blocks within the processor cores - one of which should be the register file - are far smaller than labeled caches. The processor in second image (Sandybridge) seems to have integrated the L1 and L2 caches into the cores, at least based on how they're labeled. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-04 17:16 +0000 |
| Message-ID | <2016Dec4.181624@mips.complang.tuwien.ac.at> |
| In reply to | #53069 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>http://www.chip-architect.com/news/Real_Sao_Paolo_Shanghai_Nehalem_1600x784_.jpg
>https://randomascii.files.wordpress.com/2012/12/image1.png
>
>It appears to me that the caches can consume far more area than any
>other logic block. The blocks within the processor cores - one of
>which should be the register file - are far smaller than labeled caches.
>The processor in second image (Sandybridge) seems to have integrated the
>L1 and L2 caches into the cores, at least based on how they're labeled.
Note that the L1 cache has 4 cycles latency, the L2 cache has about 10
cycles latency, and the L3 cache has about 50 cycles of latency. If
you use the L3 cache as register file, it will be 8MB large, but you
will have 50 cycles of latency, and it has only one port per 2MB slice
(for four cores), so even if you can circumvent the latency issue, you
will typically only have one instruction every three cycles on every
core (compared to four on a real Sandy Bridge).
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-28 13:33 -0800 |
| Message-ID | <87eg1v8f2q.fsf@nightsong.com> |
| In reply to | #52928 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web