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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-13 18:33 -0800 |
| Subject | Are stack machines inherently faster? |
| Message-ID | <40b9c778-3a98-450b-b65b-6cbaee444921@googlegroups.com> |
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?
[toc] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-13 23:02 -0500 |
| Message-ID | <o0bcvo$f3g$2@dont-email.me> |
| In reply to | #52599 |
On 11/13/2016 9:33 PM, polymorph self wrote: > 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? No. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-14 16:59 -0800 |
| Message-ID | <6a4467c7-1b3b-4e36-b10d-c6a4c98433c6@googlegroups.com> |
| In reply to | #52602 |
On Sunday, November 13, 2016 at 11:02:32 PM UTC-5, rickman wrote: > On 11/13/2016 9:33 PM, polymorph self wrote: > > 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? > > No. > > -- > > Rick C misc having few instructions to get things done sounds like less gets more done
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-14 22:27 -0500 |
| Message-ID | <o0dvao$kt9$1@dont-email.me> |
| In reply to | #52638 |
On 11/14/2016 7:59 PM, polymorph self wrote: > On Sunday, November 13, 2016 at 11:02:32 PM UTC-5, rickman wrote: >> On 11/13/2016 9:33 PM, polymorph self wrote: >>> 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? >> >> No. >> >> -- >> >> Rick C > > misc having few instructions to get things done > sounds like less > gets more done No. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-11-17 06:26 -0800 |
| Message-ID | <0ebbb961-6537-4472-8170-f899bd801edb@googlegroups.com> |
| In reply to | #52641 |
> > misc having few instructions to get things done > > sounds like less > > gets more done > > No. Yes :)
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-17 08:08 -0800 |
| Message-ID | <dae80a10-e734-433e-a6fa-1c44c8d09059@googlegroups.com> |
| In reply to | #52696 |
On Thursday, November 17, 2016 at 9:26:52 AM UTC-5, Ilya Tarasov wrote:
> > > misc having few instructions to get things done
> > > sounds like less
> > > gets more done
> >
> > No.
>
> Yes :)
Customer: "That's not an argument, that's just contradiction."
Counselor: "No it isn't."
Monty Python, The Argument
From what I remember of Stack Machines, Koopman, it really depends on what the
problem is that you are trying to solve. Stack machines can be remarkably
faster at servicing a simple hardware interrupt, but register machines can win
the day in general computation benchmarks and so on.
Disclaimer: I did not check the text.
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 and assembler can
even be eliminated by inlining Forth primitives without next where that is
possible in critical inner loop stuff.
IMHO Forth and Forth CPUs seems to be better in practice than theory would
indicate, but I don't have the studies to prove that.
BF
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-11-17 10:52 -0800 |
| Message-ID | <34e47822-500b-421c-a53d-a9e0fcc1f6ae@googlegroups.com> |
| In reply to | #52698 |
On Thursday, November 17, 2016 at 5:08:08 PM UTC+1, 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 and assembler can even be eliminated by inlining Forth > primitives without next where that is > possible in critical inner loop stuff. It depends on what you call "very well." I would say that you're describing a popular Forth myth. It is not true. There have been (very, very long ago), CLF threads that posed problems that piqued people's interest and resulted in a flurry of smart algorithmic tricks that would have been a lot more cumbersome to come up with, design, and test in other languages. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-17 09:57 -1000 |
| Message-ID | <0uydnbvPrp42lrPFnZ2dnUU7-XHNnZ2d@supernews.com> |
| In reply to | #52701 |
On 11/17/16 8:52 AM, mhx@iae.nl wrote: > On Thursday, November 17, 2016 at 5:08:08 PM UTC+1, 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 and assembler can even be eliminated by inlining Forth >> primitives without next where that is >> possible in critical inner loop stuff. > > It depends on what you call "very well." I would say that you're > describing a popular Forth myth. It is not true. Well, it was my experience as well. But in a real world project, good design of the software is a far greater determinant of performance than anything else. > There have been (very, very long ago), CLF threads that posed > problems that piqued people's interest and resulted in a flurry > of smart algorithmic tricks that would have been a lot more > cumbersome to come up with, design, and test in other languages. > > -marcel > Agreed. -- ================================================== 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-17 15:58 -0800 |
| Message-ID | <87vavld5g6.fsf@nightsong.com> |
| In reply to | #52701 |
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.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-17 16:29 -0800 |
| Message-ID | <63102df4-9610-4609-9fc0-72574dd813dd@googlegroups.com> |
| In reply to | #52705 |
That's what I should have said Paul. Thank you. BF
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-11-18 08:26 +0000 |
| Message-ID | <MPG.3298cb8d2601f8dc9896ca@news.virginmedia.com> |
| In reply to | #52705 |
In article <87vavld5g6.fsf@nightsong.com>, no.email@nospam.invalid says... > 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. > To some degree that is something I've been considering myself. But care needs to be used to stop it becoming habitual or inappropriate.. Can I take this opportunity to let you all know that jim - who has been staying with me and managing my web site the last couple of weeks and posting here - has had some bad news and had to fly home. If anyone was expecting replies from him that will be why he isn't responding. I'm expecting him back in a couple of weeks. If you want to know what we are working on I've put a preliminary release on the web site (library and jims forum). As I've told jim, any input from readers of this group would be more than welcome. john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-18 11:17 +0000 |
| Message-ID | <582ee232.719393556@news.eternal-september.org> |
| In reply to | #52705 |
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
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-18 06:37 -0800 |
| Message-ID | <fa562bf3-7e5f-47fb-9779-a70d6f6e529a@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 That's a better ratio of improvement over DTC in intel than I would have expected Stephen, so VFX is quite efficient. I have a question. Let me begin with the fact that I have nothing but praise for the excellent work MPE has done in pushing the envelope in native code generation with Forth compilers. Here here. I find myself wondering what you would have done with that client if they had requested a speedup on that recalculation and you had NOT developed VFX? ( I am assuming they were prepared to pay for the work) Could you have hand coded a few time critical/inner loop routines and achieved those results? It's a moot point now since you have invested the time to create VFX but I am curious nevertheless. BF
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-18 15:30 +0000 |
| Message-ID | <582f1934.733475657@news.eternal-september.org> |
| In reply to | #52710 |
On Fri, 18 Nov 2016 06:37:35 -0800 (PST), foxaudioresearch@gmail.com wrote: >That's a better ratio of improvement over DTC in intel than I would have >expected Stephen, so VFX is quite efficient. Our numbers suggest (it was a long time ago, and CPUs have changed) that going from DTC to STC gains you about 2.2:1. Adding fairly plain vanilla optimisation gains you about another 2:1 by simple inlining. Beyond this, you are in the territory of lots of grunt work. Both VFX and iForth also tokenise small words and expand them inline, which can pay big dividends, depending very much on CPU and coding style. >I find myself wondering what you would have done with that client if they had >requested a speedup on that recalculation and you had NOT developed VFX? >( I am assuming they were prepared to pay for the work) We could have spent several months writing code routines for the recalculation engine (effectively a spreadsheet), but it would still not have been as fast as the VFX solution. Sometimes, the correct solution to a coding problem is to rewrite the compiler. The MPE benchmark suite is on the MPE website. We gave up benchmarking ITC Forths some years ago when VFX was more than 12 times faster than the popular ITC Forth. The good business decisions we made in developing VFX were to decide to do it properly and get funding for the development. >Could you have hand coded a few time critical/inner loop routines and > achieved those results? Probably not. Remember also that assembler code is harder to write and to maintain, and affects both cost and time to market. As I keep pointing out, I haven't written an interrupt routine in assembler for an ARM for about 15 years ... except to prove that I can still do it. A good code generator is an enabling technology. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-27 00:25 -0800 |
| Message-ID | <ea39d95b-2ce8-4476-bab0-bcc13ed6687e@googlegroups.com> |
| In reply to | #52713 |
On Friday, November 18, 2016 at 10:30:16 AM UTC-5, Stephen Pelc wrote: > On Fri, 18 Nov 2016 06:37:35 -0800 (PST), foxaudioresearch@gmail.com > wrote: > > >That's a better ratio of improvement over DTC in intel than I would have > >expected Stephen, so VFX is quite efficient. > > Our numbers suggest (it was a long time ago, and CPUs have changed) > that going from DTC to STC gains you about 2.2:1. Adding fairly plain > vanilla optimisation gains you about another 2:1 by simple inlining. > Beyond this, you are in the territory of lots of grunt work. Both VFX > and iForth also tokenise small words and expand them inline, which can > > pay big dividends, depending very much on CPU and coding style. > > >I find myself wondering what you would have done with that client if they had > >requested a speedup on that recalculation and you had NOT developed VFX? > >( I am assuming they were prepared to pay for the work) > > We could have spent several months writing code routines for the > recalculation engine (effectively a spreadsheet), but it would still > not have been as fast as the VFX solution. Sometimes, the correct > solution to a coding problem is to rewrite the compiler. The MPE > benchmark suite is on the MPE website. We gave up benchmarking > ITC Forths some years ago when VFX was more than 12 times faster > than the popular ITC Forth. > > The good business decisions we made in developing VFX were to decide > to do it properly and get funding for the development. > > >Could you have hand coded a few time critical/inner loop routines and > > achieved those results? > > Probably not. Remember also that assembler code is harder to write and > to maintain, and affects both cost and time to market. As I keep > pointing out, I haven't written an interrupt routine in assembler for > an ARM for about 15 years ... except to prove that I can still do it. > A good code generator is an enabling technology. > > 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 by the gods I can't even imagine writing an interrupt in assembler how the hell did you learn such?
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-11-27 05:08 -0500 |
| Message-ID | <20161127050858.1dbc490d@_> |
| In reply to | #52890 |
On Sun, 27 Nov 2016 00:25:22 -0800 (PST) polymorph self <jackvanc3@gmail.com> wrote: > > Probably not. Remember also that assembler code is harder to write > > and to maintain, and affects both cost and time to market. As I keep > > pointing out, I haven't written an interrupt routine in assembler > > for an ARM for about 15 years ... except to prove that I can still > > do it. A good code generator is an enabling technology. > > > by the gods I can't even imagine writing an interrupt in assembler It's no different than coding a subroutine or procedure in assembly. You just have to take care of some extra steps. There are a bunch of people who have done so for the x86 processor on alt.os.development. I have yet to see anyone on a.o.d. who codes for the ARM processor. > how the hell did you learn such? You read the programmer instruction manuals from the processor manufacturer. You teach yourself how to program in assembly. Then, like everything else in life, you solve the puzzle. You make it work by doing what needs to be done. Think of it as a procedure with a few extra layers wrapped around the code for a procedure. For x86, the basic sequence is: disable interrupts preserve registers (optionally) switch stacks do what needs to be done for the interrupt procedure (optionally) restore stacks restore registers enable interrupts return from interrupt Of course, you have to do that sequence in assembly. But, you don't have to code the interrupt in assembly. You can code most of it in a high level language like C. However, most high level languages don't provide a mechanism to implement interrupt routines. So, you have to find a method to transfer from assembly to the high level language, and a way to transfer back too. This is more assembly code. This code is custom to each compiler. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-27 15:12 -1000 |
| Message-ID | <9cidnYT32LENGabFnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #52895 |
On 11/27/16 12:08 AM, Rod Pemberton wrote: > On Sun, 27 Nov 2016 00:25:22 -0800 (PST) > polymorph self <jackvanc3@gmail.com> wrote: > >>> Probably not. Remember also that assembler code is harder to write >>> and to maintain, and affects both cost and time to market. As I keep >>> pointing out, I haven't written an interrupt routine in assembler >>> for an ARM for about 15 years ... except to prove that I can still >>> do it. A good code generator is an enabling technology. >>> >> by the gods I can't even imagine writing an interrupt in assembler > > It's no different than coding a subroutine or procedure in assembly. > You just have to take care of some extra steps. > > There are a bunch of people who have done so for the x86 processor on > alt.os.development. I have yet to see anyone on a.o.d. who codes for > the ARM processor. > >> how the hell did you learn such? > > You read the programmer instruction manuals from the processor > manufacturer. You teach yourself how to program in assembly. Then, > like everything else in life, you solve the puzzle. You make it work by > doing what needs to be done. Think of it as a procedure with a few > extra layers wrapped around the code for a procedure. > > For x86, the basic sequence is: > > disable interrupts > preserve registers > (optionally) switch stacks > do what needs to be done for the interrupt procedure > (optionally) restore stacks > restore registers > enable interrupts > return from interrupt > > Of course, you have to do that sequence in assembly. But, you don't > have to code the interrupt in assembly. You can code most of it > in a high level language like C. However, most high level languages > don't provide a mechanism to implement interrupt routines. So, you > have to find a method to transfer from assembly to the high level > language, and a way to transfer back too. This is more assembly code. > This code is custom to each compiler. It can be even simpler. In SwiftX we follow the convention that a task managing an interrupt-driven device initiates an operation and then "sleeps" until an interrupt signals its completion. The interrupt routine does only the minimum required (tally a counter, read a number and store it, etc.) and wakes the task, which does any other processing in high-level Forth. It isn't necessary to save & restore all registers, and typical interrupt routines use only one (often none, depending on the processer). Often interrupt routines are only a few instructions long (4-6, sometimes fewer). 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-27 21:06 -0800 |
| Message-ID | <41768c5d-fc4b-4050-9940-64c97402f69b@googlegroups.com> |
| In reply to | #52908 |
On Sunday, November 27, 2016 at 6:12:54 PM UTC-7, Elizabeth D. Rather wrote: > It can be even simpler. In SwiftX we follow the convention that a task > managing an interrupt-driven device initiates an operation and then > "sleeps" until an interrupt signals its completion. The interrupt > routine does only the minimum required (tally a counter, read a number > and store it, etc.) and wakes the task, which does any other processing > in high-level Forth. It isn't necessary to save & restore all registers, > and typical interrupt routines use only one (often none, depending on > the processer). Often interrupt routines are only a few instructions > long (4-6, sometimes fewer). This is nonsense, as usual. An ISR (interrupt service routine) typically uses a circular buffer. An ISR doing input would put the data into the buffer, and the main program would remove data from the buffer (hopefully before it gets full). An ISR doing output would take data from the buffer, and the main program would put data into the buffer (usually at a much higher speed than the output port is operating at). An ISR is not going to be 4-6 instructions long --- it is going to be much longer, and it is going to use some registers --- you can't work with a circular buffer without at least two registers, and that would be pretty restrictive. Most likely, you don't know what a circular buffer is. Your ISRs are super-short because they just use a single variable as their buffer. The problem with this, of course, is that the main-program has to be reading from or writing to that variable as fast as the data comes in or goes out. This has almost no benefit compared to the main-program directly accessing the I/O port. The only benefit is that the processor can be put in low-power sleep mode while it waits for an interrupt, which would be useful if the I/O is very slow. This is a minor benefit though. You should just learn what a circular buffer is so your main-program doesn't have to be totally on top of the I/O but it can just let I/O be done in the background while it does more important work. In the 1980s the 6502 was commonly used as a micro-controller. It had absolute-indexed addressing which I think was provided primarily for implementing 256-byte circular buffers. Everybody knew about circular buffers in the 1980s. I think they were well-known in the late 1970s too --- maybe in the early 1970s, or the 1960s, they were unknown --- of course, COBOL programmers such as yourself don't know any computer-science whatsoever, then or now.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-11-28 12:20 +0000 |
| Message-ID | <MPG.32a63160f482ed659896cd@news.virginmedia.com> |
| In reply to | #52915 |
> In article <41768c5d-fc4b-4050-9940-64c97402f69b@googlegroups.com>, hughaguilar96@gmail.com says... > An ISR is not going to be 4-6 instructions long --- it is going to be much longer, and it is going to use some registers --- you can't work with a circular buffer without at least two registers, and that would be pretty restrictive. > > Another method for ISR's is: set a flag in the main program and clear the interrupt flag then exit the ISR This results in very short ISR's The main program checks the flag, clears it and performs the actual service required. This reduces the time an interrupt is being dealt with and the number of recursions you may otherwise have interfering with main operation. And perhaps crucially less chance of missing an interrupt.. It does have the drawback of having to check flags regularly though Horses for courses as they say. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-28 13:43 +0000 |
| Message-ID | <o1hc6t$etj$1@dont-email.me> |
| In reply to | #52915 |
On 11/28/2016 05:06, hughaguilar96@gmail.com wrote: > On Sunday, November 27, 2016 at 6:12:54 PM UTC-7, Elizabeth D. Rather > wrote: >> It can be even simpler. In SwiftX we follow the convention that a >> task managing an interrupt-driven device initiates an operation and >> then "sleeps" until an interrupt signals its completion. The >> interrupt routine does only the minimum required (tally a counter, >> read a number and store it, etc.) and wakes the task, which does >> any other processing in high-level Forth. It isn't necessary to >> save & restore all registers, and typical interrupt routines use >> only one (often none, depending on the processer). Often interrupt >> routines are only a few instructions long (4-6, sometimes fewer). > > This is nonsense, as usual. > > An ISR (interrupt service routine) typically uses a circular buffer. > An ISR doing input would put the data into the buffer, and the main > program would remove data from the buffer (hopefully before it gets > full). An ISR doing output would take data from the buffer, and the > main program would put data into the buffer (usually at a much higher > speed than the output port is operating at). > > An ISR is not going to be 4-6 instructions long --- it is going to be > much longer, and it is going to use some registers --- you can't work > with a circular buffer without at least two registers, and that would > be pretty restrictive. > > Most likely, you don't know what a circular buffer is. Your ISRs are > super-short because they just use a single variable as their buffer. > The problem with this, of course, is that the main-program has to be > reading from or writing to that variable as fast as the data comes in > or goes out. This has almost no benefit compared to the main-program > directly accessing the I/O port. The only benefit is that the > processor can be put in low-power sleep mode while it waits for an > interrupt, which would be useful if the I/O is very slow. This is a > minor benefit though. You should just learn what a circular buffer is > so your main-program doesn't have to be totally on top of the I/O but > it can just let I/O be done in the background while it does more > important work. > > In the 1980s the 6502 was commonly used as a micro-controller. It had > absolute-indexed addressing which I think was provided primarily for > implementing 256-byte circular buffers. Everybody knew about circular > buffers in the 1980s. I think they were well-known in the late 1970s > too --- maybe in the early 1970s, or the 1960s, they were unknown --- > of course, COBOL programmers such as yourself don't know any > computer-science whatsoever, then or now. > You are very confused about this, and predictably didactic & rude to Elizabeth. Circular buffers are but one method for handling incoming or outgoing data, and they have been used for a lot longer than you realise. A circular buffer can be as simple as a block of data, addressed by an index modulo the number of buffers. I have no idea why you think a pair of registers is required. Neither is data movement needed, since we can use a circular buffer of pointers to data. ISRs are typically very short and do as little work as is possible. The general rule is to try and minimise the amount of time in interrupts, esecialy if they block other activity, and to do the bulk of the work outside of the interrupt. An ISR may be as simple as moving a task pointer from a blocked to a ready queue as part of a scheduler, and the work is done later by the task. -- Alex
[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