Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56858 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-04-08 20:53 +1000 |
| Last post | 2017-04-10 07:42 -1000 |
| Articles | 20 on this page of 151 — 21 participants |
Back to article view | Back to comp.lang.forth
polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-08 20:53 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-08 12:29 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 09:50 +1000
Re: polyForth multitasker question David Schultz <abuse@127.0.0.1> - 2017-04-09 19:25 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 10:52 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 08:58 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-15 10:39 +1000
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 11:12 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-10 18:22 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:17 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-11 03:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 14:37 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-09 18:05 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 15:50 -1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-10 07:47 +0200
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 12:20 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 09:11 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 04:20 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 10:53 +0100
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 11:24 +0100
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:05 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-11 14:27 +0100
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 07:08 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-11 18:06 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-11 18:58 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 13:57 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 18:02 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 19:47 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 21:22 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 02:57 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-12 23:17 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 00:13 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:43 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 19:34 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 19:57 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 02:45 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 21:28 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 07:53 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:44 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-14 02:01 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:28 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:23 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:46 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 11:31 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:23 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:06 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 08:13 -0500
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 14:12 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-14 09:30 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 08:46 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-15 13:07 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:27 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 18:18 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 13:53 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 11:34 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 11:31 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-14 12:14 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:46 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:48 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:50 -0700
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:39 +0200
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 11:48 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 22:07 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 16:47 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 11:36 -1000
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 17:07 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 14:17 -1000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 18:27 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 06:53 +0300
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 22:00 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 08:59 +0300
Re: polyForth multitasker question lehs <skydda.barnen@gmail.com> - 2017-04-15 22:19 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 17:26 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 09:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:13 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:28 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:27 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-16 14:45 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 17:50 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 12:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 13:27 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 03:49 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-18 13:47 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 14:30 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 20:58 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-18 11:47 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 19:19 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 04:34 -0500
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 02:00 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 18:10 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 01:41 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 21:38 +1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-19 10:56 +0200
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-19 07:22 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:10 -0700
Re: polyForth multitasker question stephen@mpeforth.com (Stephen Pelc) - 2017-04-18 09:35 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-18 08:01 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-18 09:03 -0700
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 11:07 -0500
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 10:59 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 19:13 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:36 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:27 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 04:32 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:15 -1000
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:07 +0200
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 15:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:36 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:48 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:36 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 14:55 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 15:27 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 23:45 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 21:13 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-17 16:57 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:08 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 20:29 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 15:34 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 19:43 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:03 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 23:50 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 03:55 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 01:38 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 11:50 -0400
Re: polyForth multitasker question john <anon@example.com> - 2017-04-15 12:03 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 12:41 +0000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:14 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:32 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 20:41 -0400
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 14:57 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 20:45 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:56 -0400
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:32 +0200
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:05 -0400
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-15 04:10 -0500
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 03:19 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-13 15:46 +0100
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-14 11:37 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:48 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 05:37 -0500
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 22:12 -0700
Multitasking with Forth processors Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 07:39 +0200
Re: Multitasking with Forth processors Paul Rubin <no.email@nospam.invalid> - 2017-04-11 22:58 -0700
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 03:00 -0400
Re: Multitasking with Forth processors albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:18 +0200
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 17:11 -0400
Re: Multitasking with Forth processors foxaudioresearch@gmail.com - 2017-04-12 13:50 -0700
Re: Multitasking with Forth processors "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:30 -1000
Re: Multitasking with Forth processors Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-14 12:20 +0100
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-14 16:47 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-10 07:42 -1000
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 11:28 -0700 |
| Message-ID | <87efwuhmhm.fsf@nightsong.com> |
| In reply to | #57282 |
minforth@arcor.de writes: > 6 mA at 3 V makes 18 mW peak. I don't know much about such boards, > but I'd expect power ratings below 1 mW for such tiny things today. At 48 MHz it's 125 uA per MHz, which is beatable but still pretty good.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 16:23 -0400 |
| Message-ID | <ocrau2$9oe$1@dont-email.me> |
| In reply to | #57282 |
On 4/14/2017 5:01 AM, minforth@arcor.de wrote: > Am Freitag, 14. April 2017 10:44:51 UTC+2 schrieb Paul Rubin: >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> And if you have 1000 such tasks, every PAUSE scrubs the L1 cache... >>> It's simple, but it does not scale. >> >> Tbh I don't imagine using this tasking scheme on a big x86 with 1000s of >> tasks. But a small embedded program might still use a few tens of >> tasks. Maybe the scheme can work at that level. >> >> I came across a really nice little board, a new addition to the Adafruit >> Feather series: >> >> https://www.adafruit.com/product/3403 >> >> - 48 mhz ARM Cortex M0 cpu, 256k on-chip flash, 32k on-chip ram >> - 32 khz on-board crystal for use with built-in RTC counter in the cpu >> - 2MB on-board SPI flash, with boot loader that makes the whole board >> look like a USB mass storage device, so you can drag and drop files >> to it from your PC >> - Max power drain seems to be around 6 mA when running benchmark code. >> Usually much less than that. >> - Can be powered from USB port or Lipo cell through JST connector. >> Automatically charges Lipo cell from USB power. >> - Lots of analog and digital i/o pins, Feather add-on boards, etc. >> - Costs 20 USD, a bit steep by AliExpress standards but not bad >> unless you need a lot of them. >> >> It's made to run a MicroPython fork but it seems to call for a >> completely self-hosted Forth system with multitasking. > > 6 mA at 3 V makes 18 mW peak. I don't know much about such boards, > but I'd expect power ratings below 1 mW for such tiny things today. It all depends on what you are doing. Most can turn themselves off and run the timer at sub-uA levels. If you are blasting instructions through the CPU it is going to draw current. There's no way around that. Most ARM lines can achieve current ratings of 100 uA/MHz ballpark. That's pretty durn good really. So 6 mA @ 48 MHz (120 uA/MHz) is right in there with the best of them. I recall a decade ago currents were more like 1 mA/MHz. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 22:46 -1000 |
| Message-ID | <-MadnS8jLJDXEW3FnZ2dnUU7-RHNnZ2d@supernews.com> |
| In reply to | #57277 |
On 4/13/17 9:53 PM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In fact, it's far less complicated than that. Each task knows how long >> it's sleeping, and each time around the round-robin checks to see if it's >> wake-up time yet. A very few instructions each time. > > If you have 100 tasks waiting in MS, that's maybe 1000 instructions > and 100 cache line touches (20% of the L1 cache of a recent Intel CPU) > every time a working task PAUSEs. And if you have 1000 such tasks, > every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e., > about 50000 cycles from the cache misses alone). It's simple, but it > does not scale. > > And it burns CPU when everything is waiting. Fortunately such scenarios are rare (I've only seen 100 tasks a couple of times). Perhaps we define a "task" a little differently than you do. I certainly prefer a scenario where a task can initiate a process that will interrupt when it is complete, as that's much more efficient than polling. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-14 11:31 +0000 |
| Message-ID | <2017Apr14.133103@mips.complang.tuwien.ac.at> |
| In reply to | #57280 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/13/17 9:53 PM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> In fact, it's far less complicated than that. Each task knows how long
>>> it's sleeping, and each time around the round-robin checks to see if it's
>>> wake-up time yet. A very few instructions each time.
>>
>> If you have 100 tasks waiting in MS, that's maybe 1000 instructions
>> and 100 cache line touches (20% of the L1 cache of a recent Intel CPU)
>> every time a working task PAUSEs. And if you have 1000 such tasks,
>> every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e.,
>> about 50000 cycles from the cache misses alone). It's simple, but it
>> does not scale.
>>
>> And it burns CPU when everything is waiting.
>
>Fortunately such scenarios are rare (I've only seen 100 tasks a couple
>of times).
Of course, when your multi-tasker does not scale, programmers avoid
using many tasks. By contrast, Erlang has implemented scalable
multi-tasking and demonstrated it with 85,000 tasks (processes in
Erlang terminology) in
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.1969&rep=rep1&type=pdf>
in order to suppoort concurrency-oriented programming.
>I certainly prefer a scenario where a task can initiate a process that
>will interrupt when it is complete, as that's much more efficient than
>polling.
You lost me here. You have argued that polling the current time in
each task is the right way to implement MS, now you argue that the
approach that others have advocated is preferable. Either I
misunderstand what you mean, or you are silently changing your
position.
- 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 | 2017-04-14 11:23 -0700 |
| Message-ID | <87inm6hmqf.fsf@nightsong.com> |
| In reply to | #57284 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > By contrast, Erlang has implemented scalable multi-tasking and > demonstrated it with 85,000 tasks (processes in Erlang terminology) That's really not Forth-like at all though: it's completely preemptive and the Erlang processes run in a complicated virtual machine, basically an entire OS running inside a host OS, separate GC for each process etc. There's a bare metal Erlang board at grisp.org now, but it's an ARM7 with something like 32MB of off-chip ram. I don't think that can be compared with a typical Forth environment.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-14 10:06 -1000 |
| Message-ID | <MuydncK1WZhdtmzFnZ2dnUU7-UHNnZ2d@supernews.com> |
| In reply to | #57284 |
On 4/14/17 1:31 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 4/13/17 9:53 PM, Anton Ertl wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>> In fact, it's far less complicated than that. Each task knows how long >>>> it's sleeping, and each time around the round-robin checks to see if it's >>>> wake-up time yet. A very few instructions each time. >>> >>> If you have 100 tasks waiting in MS, that's maybe 1000 instructions >>> and 100 cache line touches (20% of the L1 cache of a recent Intel CPU) >>> every time a working task PAUSEs. And if you have 1000 such tasks, >>> every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e., >>> about 50000 cycles from the cache misses alone). It's simple, but it >>> does not scale. >>> >>> And it burns CPU when everything is waiting. >> >> Fortunately such scenarios are rare (I've only seen 100 tasks a couple >> of times). > > Of course, when your multi-tasker does not scale, programmers avoid > using many tasks. By contrast, Erlang has implemented scalable > multi-tasking and demonstrated it with 85,000 tasks (processes in > Erlang terminology) in > <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.1969&rep=rep1&type=pdf> > in order to suppoort concurrency-oriented programming. Well, it depends on what you call a task and how you use it. We consider a "task" to be an entity with a given list of responsibilities in a complex application: running a conveyor belt, running a press machine, managing an operator station, and managing a real-time display, for example. >> I certainly prefer a scenario where a task can initiate a process that >> will interrupt when it is complete, as that's much more efficient than >> polling. > > You lost me here. You have argued that polling the current time in > each task is the right way to implement MS, now you argue that the > approach that others have advocated is preferable. Either I > misunderstand what you mean, or you are silently changing your > position. Polling may be the only way to time an interval or check for input on a device without interrupts, but if you're doing something with a device like a disk or keyboard, it's better to initiate the action and let the device interrupt the task when it's done. That way the task stays asleep. In other words, use the hardware when it's available. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-14 08:13 -0500 |
| Message-ID | <uPednfe7K92eVm3FnZ2dnUU7-SPNnZ2d@supernews.com> |
| In reply to | #57277 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>In fact, it's far less complicated than that. Each task knows how >>long it's sleeping, and each time around the round-robin checks to >>see if it's wake-up time yet. A very few instructions each time. > > If you have 100 tasks waiting in MS, IMO, this is the wrong way to think about it. You probably don't, or at least it's unlikely in a system where most tasks are stopped most of the time waiting for some kind of I/O event. If you really do need hundreds of tasks waiting in MS, then you can code a version of MS which is optimized for a large number of tasks. That version of MS is complicated because you'll have to maintain a priority queue. A fast priority queue with O(n log n) insertion time requires a heap or a balanced binary tree, and the result is more than an order of magnitude more complex than that simple version of MS. It might be easier and more efficient to maintain a timer task which kicks other tasks at intervals: it depends on the application. > It's simple, but it does not scale. That's true. And it's a good thing. That's the big idea of Forth design: do the simple thing, and only if it turns out to be inadequate do the complicated thing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-14 14:12 +0000 |
| Message-ID | <2017Apr14.161245@mips.complang.tuwien.ac.at> |
| In reply to | #57287 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>>In fact, it's far less complicated than that. Each task knows how
>>>long it's sleeping, and each time around the round-robin checks to
>>>see if it's wake-up time yet. A very few instructions each time.
>>
>> If you have 100 tasks waiting in MS,
>
>IMO, this is the wrong way to think about it.
>
>You probably don't, or at least it's unlikely in a system where most
>tasks are stopped most of the time waiting for some kind of I/O event.
Then you have the same scaling problem.
Also, an example of a system with a huge number of tasks waiting on
timers is a game, where various agents in the game are implemented as
tasks. Some of these agents (and that can easily be hundreds or
thousands) just do something at various intervals, say every 5s; a
natural way to implement this is:
begin do-something 5000 ms again
[Yes, an interface that is not relative to the current time would be
even better than MS.]
>If you really do need hundreds of tasks waiting in MS, then you can
>code a version of MS which is optimized for a large number of tasks.
>That version of MS is complicated because you'll have to maintain a
>priority queue. A fast priority queue with O(n log n) insertion time
>requires a heap or a balanced binary tree, and the result is more than
>an order of magnitude more complex than that simple version of MS.
True, but it scales.
As an intermediate variant, you can have a separate MS task list, and
scan that completely whenever the next MS timer is reached, and wakes
these tasks. Slightly more complex than the polling variant, but
already much more efficient.
>> It's simple, but it does not scale.
>
>That's true. And it's a good thing. That's the big idea of Forth
>design: do the simple thing, and only if it turns out to be inadequate
>do the complicated thing.
This approach has its charms, but the other approach of having a
scalable thing, giving the users the freedom to roam outside the
narrow confines of the implementor's imagination, also has its
advantages.
In the present case, we know how to do the scalable thing, it's not
very expensive, and it has been used in other environments, so I think
that the advantages of the scalable approach outweigh the
disadvantages (unless you are on tiny hardware where you cannot afford
hundreds of tasks anyway).
- 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 | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-04-14 09:30 -0700 |
| Message-ID | <771beb26-4b3d-4a4d-9251-373b2ff47b70@googlegroups.com> |
| In reply to | #57290 |
It seems to me that in the current gforth snapshot MS is not scalable either.
Isn't it ?
pahihu
\ kernel/io.fs
Defer deadline ( d -- )
\G wait to absolute time @var{d} in ns since 1970-1-1 0:00:00+000
: ns ( d -- ) ntime d+ deadline ;
: ms ( n -- ) #1000000 um* ns ;
\ tasker.fs
: task-deadline ( d -- )
BEGIN pause 2dup ntime d- d0<= UNTIL 2drop ;
' task-deadline IS deadline
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-15 08:46 +0000 |
| Message-ID | <2017Apr15.104628@mips.complang.tuwien.ac.at> |
| In reply to | #57292 |
pahihu <pahihu@gmail.com> writes:
>It seems to me that in the current gforth snapshot MS is not scalable either.
>Isn't it ?
>
>pahihu
>
>
>\ kernel/io.fs
>Defer deadline ( d -- )
>\G wait to absolute time @var{d} in ns since 1970-1-1 0:00:00+000
>: ns ( d -- ) ntime d+ deadline ;
>: ms ( n -- ) #1000000 um* ns ;
I don't know how current your snapshot is, but the code above now
looks as follows:
( 2015-09-11) Defer deadline ( d -- )
( 2015-09-11) \G wait to absolute time @var{d} in ns since 1970-1-1 0:00:00+000
( 2015-09-11) : kernel-deadline ( d -- )
( 2016-08-03) BEGIN 2dup ntime d- 2dup d0< IF 2drop #0. THEN
( 2016-08-03) #1000000000 um/mod (ns) EINTR <> UNTIL
( 2016-03-02) 2drop ;
( 2015-09-11) ' kernel-deadline IS deadline
( 2015-09-11) : ns ( d -- ) ntime d+ deadline ;
( 2015-09-11) : ms ( n -- ) #1000000 um* ns ;
[I have added the commit dates of the lines in the comments in front.]
(NS) calls pselect() or an equivalent system call.
>\ tasker.fs
>: task-deadline ( d -- )
> BEGIN pause 2dup ntime d- d0<= UNTIL 2drop ;
>
>' task-deadline IS deadline
That code is still there, but I cannot even load tasker.fs.
In any case, Gforth multitasking relies on OS multithreading (not as
scalable as Erlang). The main reason is that we are using blocking
system calls for I/O. We have discussed whether we should switch to
non-blocking system calls in order to do more (or anything) in the
Forth scheduler, but have concluded not to go there for now (I don't
remember what the decisive argument was).
- 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 | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-04-15 13:07 -0700 |
| Message-ID | <9cc8fad9-67b9-49a8-a1f4-8e45fb7ca63c@googlegroups.com> |
| In reply to | #57360 |
I have poked around in the gforth-0.7.9_20170406 source code tree. > That code is still there, but I cannot even load tasker.fs. It would be better to remove then from the distro. > In any case, Gforth multitasking relies on OS multithreading > (not as scalable as Erlang). OK, I see the code in unix/pthread.fs So gforth is as scalable as the underlying OS. Do you have any numbers comparing Pthread vs. old tasker.fs based multi-tasking ? pahihu
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-15 17:27 -0700 |
| Message-ID | <87bmrxfb84.fsf@nightsong.com> |
| In reply to | #57389 |
pahihu <pahihu@gmail.com> writes: > Do you have any numbers comparing Pthread vs. old tasker.fs based > multi-tasking ? I remember being able to task switch around 20k times/second on an old small 300mhz ARM board. The board had 64mb of ram and I ran a Python program on it that used around 20 threads and it wasn't a problem. On a full sized x86 server I've run 1000s of threads and that works too, but millions probably wouldn't.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-15 18:18 -0700 |
| Message-ID | <488e27c2-3d1a-4a5a-b620-5678fb18b983@googlegroups.com> |
| In reply to | #57403 |
"I remember being able to task switch around 20k times/second on an old small 300mhz ARM board. The board had 64mb of ram and I ran a Python " My cooperative tasker on an 8Mhz 6811 had a context switch time of 37uS. Scaled to 300 MHz that is 0.1uS. That is why polyforth could do what it did in its time. B
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-17 13:53 +0000 |
| Message-ID | <2017Apr17.155356@mips.complang.tuwien.ac.at> |
| In reply to | #57389 |
pahihu <pahihu@gmail.com> writes:
>Do you have any numbers comparing Pthread vs. old tasker.fs based multi-tasking ?
Sorry, no. Note that the old cooperative multi-tasker was very
limited in its applicability, because you could not use most I/O words
(blocking I/O does not go well with cooperative multitasking), and
because a bunch of VARIABLEs were not USERized yet.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-14 11:34 -0500 |
| Message-ID | <Vv6dnYA3-LOtZ23FnZ2dnUU7-K_NnZ2d@supernews.com> |
| In reply to | #57290 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>>In fact, it's far less complicated than that. Each task knows how >>>>long it's sleeping, and each time around the round-robin checks to >>>>see if it's wake-up time yet. A very few instructions each time. >>> >>> If you have 100 tasks waiting in MS, >> >>IMO, this is the wrong way to think about it. >> >>You probably don't, or at least it's unlikely in a system where most >>tasks are stopped most of the time waiting for some kind of I/O event. > > Then you have the same scaling problem. Not entirely, no: there a substantial difference between stopped tasks and tasks that are woken every time around the round robin. But indeed, if you have hundreds or thousands of stopped tasks, you should be thinking about something a bit more complicated, such as putting stopped tasks on a separate queue. >>> It's simple, but it does not scale. >> >>That's true. And it's a good thing. That's the big idea of Forth >>design: do the simple thing, and only if it turns out to be inadequate >>do the complicated thing. > > This approach has its charms, but the other approach of having a > scalable thing, giving the users the freedom to roam outside the > narrow confines of the implementor's imagination, also has its > advantages. I agree. It's a contrast between the "add the hooks and facilities now just in case" approach and the Forth approach that's described in Thinking Forth. One can lead to very neat, compact, and simple systems, and one leads to more complex but perhaps more scalable and general-purpose ones. > In the present case, we know how to do the scalable thing, it's not > very expensive, and it has been used in other environments, so I > think that the advantages of the scalable approach outweigh the > disadvantages (unless you are on tiny hardware where you cannot > afford hundreds of tasks anyway). The Forth scheduler, despite its supposed lack of sophistication, was able to run many terminals on a lowly IBM PC even when it was supposedly "impossible" to run conventional multi-user systems on that hardware. Those multi-user systems used things like priority queues and sophisticated schedulers, supposedly for efficiency, but such systems didn't scale *downwards*. Scalability goes in both directions! That "tiny hardware" probably makes up many (most?) of the computers in the world. Also, I'm thinking about the joy of knowing that the system you just shipped is the simplest cleanest, and (yes!) most perfect you know how to make. That's got to be worth something. But really, I shouldn't have to argue in favour of simplicity on c.l.f. It's the Basic Principle on which everything else is based. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 11:31 -0700 |
| Message-ID | <bc33da38-a3fa-4e6e-8737-03f1c2696ee6@googlegroups.com> |
| In reply to | #57293 |
On Friday, April 14, 2017 at 9:35:02 AM UTC-7, Andrew Haley wrote:
> Also, I'm thinking about the joy of knowing that the system you just
> shipped is the simplest cleanest, and (yes!) most perfect you know how
> to make. That's got to be worth something.
It is not worth anything if it is past deadline.
> But really, I shouldn't have to argue in favour of simplicity on
> c.l.f. It's the Basic Principle on which everything else is based.
Andrew Haley is deeply loyal to Elizabeth Rather, which is why she appointed him to the Forth-200x committee.
All of these arguments eventually come to the idea that Elizabeth Rather alone knows the "Forth Way" --- this is why I consider ANS-Forth to be a cult --- this is why I can never be an ANS-Forth programmer.
Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists:
https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo
This was his code:
: each[ ( list -- )
POSTPONE begin POSTPONE dup POSTPONE while ; immediate
( list -- list )
: ]each ( list -- )
POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate
His code will work sometimes, but not always. It won't work if the code inside needs access to data on the data-stack, because that data is covered up by the internal data of EACH[ ]EACH that is in the way. He is exposing the internal workings of EACH[ ]EACH to the user, although the whole point of abstraction is to hide the internal workings from the user. Also, his code won't work if the code inside changes the link field of the node that it is working on (see REMOVE in the novice-package).
My code is general-purpose; it works in every situation. It is not the simplest solution though in certain circumstances that allow for a super-simple solution. My use of >R makes my code slightly slower than Julien Fondren's code (in those certain super-simple circumstances when Julien Fondren's code actually works) --- this is a matter of nanoseconds though, so it doesn't matter from a practical standpoint --- it is more important to have general-purpose code-libraries available than to have code optimized for certain circumstances that doesn't work in other circumstances.
This is my code:
---------------------------------------------------------------------------
SwiftForth? [if]
icode next>r ( node -- node ) \ r: -- next-node
0 [ebx] push
ret end-code
[else]
macro: next>r ( node -- node ) \ r: -- next-node
dup .fore @ >r ;
[then]
macro: each[ \ toucher: i*x node -- j*x
begin dup while
next>r ;
macro: ]each
r> repeat drop ;
\ EACH[...]EACH generates faster-executing code than EACH, and can be more readable, but the code is more bloated.
\ EACH[...]EACH uses the return stack. This can create havoc in functions that use locals or use >R and R>.
\ EACH[...]EACH is mostly only used when speed is important, which largely precludes locals anyway.
\ FIND-NODE and FIND-PRIOR can't be written like this because they both involve an early-out.
\ EACH allows the toucher (the code that touches the node) to be tested on its own, and also to be used on its own.
\ EACH also allows the toucher to use local variables.
\ Both of these advantages can be achieved with EACH[...]EACH by factoring the toucher into a function and calling it.
\ EACH can easily be rewritten in assembly language, which might not be true of EACH[...]EACH.
\ Because of these reasons, EACH should generally be used rather than EACH[...]EACH.
SwiftForth? [if]
icode each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
ebx push [drop] \ -- node \r: -- 'toucher
begin non-zero? while
0 [ebx] push \ -- node \r: -- 'toucher next
w [esp] eax mov edi eax add eax call \ --
[dup] ebx pop \ -- next \r: -- 'toucher
repeat
[drop] [rdrop] ret end-code
[else]
: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;
[then]
\ It is possible for the toucher to access data underneath the node,
\ as EACH has no internal data on the stack (that is why we put everything on the return stack during the EXECUTE).
\ It is ok for the toucher to REMOVE the node from this list,
\ as we already have our next node on the r-stack.
\ When writing a filter, you REMOVE all of the nodes that you don't want to keep.
\ The toucher shouldn't remove multiple nodes however,
\ as it might clobber the next-node that EACH has waiting on the r-stack.
SwiftForth? [if]
code find-node ( i*x head 'toucher -- j*x node|false ) \ toucher: i*x node -- j*x flag
ebx push [drop] \ -- node \r: -- 'toucher
begin non-zero? while
0 [ebx] push ebx push \ -- node \r: -- 'toucher next node
w 2* [esp] eax mov edi eax add eax call \ --
non-zero? if ebx pop [2rdrop] ret then
[rdrop] ebx pop
repeat
[rdrop] ret end-code
[else]
: find-node ( i*x head 'toucher -- j*x node|false ) \ toucher: i*x node -- j*x flag
>r
begin dup while \ -- node \r: -- toucher
r@ over .fore @ >r over >r \ -- node toucher \r: -- toucher next node
execute if r> 2rdrop exit then \ return node
rdrop r> repeat \ -- next \r: -- toucher
rdrop ; \ return the node, which is NIL (FALSE) by now
[then]
\ FIND-NODE is like EACH except that it stops when the toucher returns true,
\ and it either returns the found node or false
SwiftForth? [if]
code find-prior ( i*x head 'toucher -- j*x -1|node|false ) \ toucher: i*x node -- j*x flag
ebx push [drop] \ -- node \ r: -- 'toucher
-1 # push \ r: -- 'toucher prior \ prior is -1
begin non-zero? while
0 [ebx] push ebx push \ -- node \ r: -- 'toucher prior next node
w 3 * [esp] eax mov edi eax add eax call \ -- flag
non-zero? if [2rdrop] ebx pop [rdrop] ret then
eax pop ebx pop [rdrop] eax push
repeat
[2rdrop] ret end-code
[else]
: find-prior ( i*x head 'toucher -- j*x -1|node|false ) \ toucher: i*x node -- j*x flag
>r -1 >r \ prior is -1, meaning found node was the head
begin dup while \ -- node \r: -- 'toucher prior
rr@ over .fore @ >r over >r \ -- node toucher \r: -- 'toucher prior next node
execute if 2rdrop r> rdrop exit then \ return prior
2r> rdrop >r repeat \ -- next \r: -- 'toucher node
2rdrop ; \ return the node, which is NIL (FALSE) by now
[then]
\ FIND-PRIOR is like FIND-NODE except that it returns the node prior to the found node,
\ or -1 if the found node was the head --- or false if no node was found.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-04-14 12:14 -0700 |
| Message-ID | <981beee3-6be0-4552-b4e3-92ec56188304@googlegroups.com> |
| In reply to | #57302 |
On Friday, April 14, 2017 at 1:31:04 PM UTC-5, hughag...@gmail.com wrote: > Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists: > https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo > > This was his code: > > : each[ ( list -- ) > POSTPONE begin POSTPONE dup POSTPONE while ; immediate > > ( list -- list ) > > : ]each ( list -- ) > POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate > > His code will work sometimes, but not always. ... > My code is general-purpose; it works in every situation. No. There are some "super-simple cases" in which your code will work, but consider \ interim code accessing values left on the return stack >r each[ ... r@ ... ]each \ interim code not consuming the node on the data stack each[ dup . ]each \ interim code trying to skip ahead in the iteration each[ dup cell+ @ if @ @ @ then ]each \ interim code uses EXIT each[ 2dup cell+ @ = if 2drop true exit then ]each None of that works with your code. Your code isn't general-purpose, nor does it work in every situation. It evidently only works for the situations it was designed for! Honestly, it's disgusting. And also, by preventing use of the return stack and by not reusing the value you push to the data stack, you're "exposing the internal workings of EACH[ ]EACH to the user", when "the whole point of abstraction is to hide the internal workings from the user"!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 12:46 -0700 |
| Message-ID | <9060e7ce-4219-498a-b8ce-b03aeb024871@googlegroups.com> |
| In reply to | #57305 |
On Friday, April 14, 2017 at 12:14:09 PM UTC-7, Julian Fondren wrote: > On Friday, April 14, 2017 at 1:31:04 PM UTC-5, hughag...@gmail.com wrote: > > Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists: > > https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo > > > > This was his code: > > > > : each[ ( list -- ) > > POSTPONE begin POSTPONE dup POSTPONE while ; immediate > > > > ( list -- list ) > > > > : ]each ( list -- ) > > POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate > > > > His code will work sometimes, but not always. > ... > > My code is general-purpose; it works in every situation. > > No. There are some "super-simple cases" in which your code will work, > but consider > > \ interim code accessing values left on the return stack > >r each[ ... r@ ... ]each > > \ interim code not consuming the node on the data stack > each[ dup . ]each > > \ interim code trying to skip ahead in the iteration > each[ dup cell+ @ if @ @ @ then ]each > > \ interim code uses EXIT > each[ 2dup cell+ @ = if 2drop true exit then ]each > > None of that works with your code. Your code isn't general-purpose, > nor does it work in every situation. It evidently only works for the > situations it was designed for! Honestly, it's disgusting. > > And also, by preventing use of the return stack and by not reusing the > value you push to the data stack, you're "exposing the internal > workings of EACH[ ]EACH to the user", when "the whole point of > abstraction is to hide the internal workings from the user"! This is the comment documenting my code: \ EACH[...]EACH generates faster-executing code than EACH, and can be more readable, but the code is more bloated. \ EACH[...]EACH uses the return stack. This can create havoc in functions that use locals or use >R and R>. \ EACH[...]EACH is mostly only used when speed is important, which largely precludes locals anyway. \ FIND-NODE and FIND-PRIOR can't be written like this because they both involve an early-out. \ EACH allows the toucher (the code that touches the node) to be tested on its own, and also to be used on its own. \ EACH also allows the toucher to use local variables. \ Both of these advantages can be achieved with EACH[...]EACH by factoring the toucher into a function and calling it. \ EACH can easily be rewritten in assembly language, which might not be true of EACH[...]EACH. \ Because of these reasons, EACH should generally be used rather than EACH[...]EACH.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 12:48 -0700 |
| Message-ID | <cc9a7476-e816-4e1b-ba55-f72475981e90@googlegroups.com> |
| In reply to | #57308 |
On Friday, April 14, 2017 at 12:46:15 PM UTC-7, hughag...@gmail.com wrote: > On Friday, April 14, 2017 at 12:14:09 PM UTC-7, Julian Fondren wrote: > > On Friday, April 14, 2017 at 1:31:04 PM UTC-5, hughag...@gmail.com wrote: > > > Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists: > > > https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo > > > > > > This was his code: > > > > > > : each[ ( list -- ) > > > POSTPONE begin POSTPONE dup POSTPONE while ; immediate > > > > > > ( list -- list ) > > > > > > : ]each ( list -- ) > > > POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate > > > > > > His code will work sometimes, but not always. > > ... > > > My code is general-purpose; it works in every situation. > > > > No. There are some "super-simple cases" in which your code will work, > > but consider > > > > \ interim code accessing values left on the return stack > > >r each[ ... r@ ... ]each > > > > \ interim code not consuming the node on the data stack > > each[ dup . ]each > > > > \ interim code trying to skip ahead in the iteration > > each[ dup cell+ @ if @ @ @ then ]each > > > > \ interim code uses EXIT > > each[ 2dup cell+ @ = if 2drop true exit then ]each > > > > None of that works with your code. Your code isn't general-purpose, > > nor does it work in every situation. It evidently only works for the > > situations it was designed for! Honestly, it's disgusting. > > > > And also, by preventing use of the return stack and by not reusing the > > value you push to the data stack, you're "exposing the internal > > workings of EACH[ ]EACH to the user", when "the whole point of > > abstraction is to hide the internal workings from the user"! > > This is the comment documenting my code: > > \ EACH[...]EACH generates faster-executing code than EACH, and can be more readable, but the code is more bloated. > \ EACH[...]EACH uses the return stack. This can create havoc in functions that use locals or use >R and R>. > \ EACH[...]EACH is mostly only used when speed is important, which largely precludes locals anyway. > \ FIND-NODE and FIND-PRIOR can't be written like this because they both involve an early-out. > > \ EACH allows the toucher (the code that touches the node) to be tested on its own, and also to be used on its own. > \ EACH also allows the toucher to use local variables. > \ Both of these advantages can be achieved with EACH[...]EACH by factoring the toucher into a function and calling it. > \ EACH can easily be rewritten in assembly language, which might not be true of EACH[...]EACH. > > \ Because of these reasons, EACH should generally be used rather than EACH[...]EACH. My ARENA.4TH game was a good demonstration of EACH being used in various circumstances --- you code would have failed.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 12:50 -0700 |
| Message-ID | <b1f06a7f-edc6-4005-a2e1-9c45d57b75a1@googlegroups.com> |
| In reply to | #57305 |
On Friday, April 14, 2017 at 12:14:09 PM UTC-7, Julian Fondren wrote: > \ interim code uses EXIT > each[ 2dup cell+ @ = if 2drop true exit then ]each Use FIND-NODE or FIND-PRIOR for this.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web