Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #4626 > unrolled thread

Forth Performance Question

Back to article view | Back to comp.lang.forth

Contents

  Forth Performance Question TS <thinksquared@gmail.com> - 2011-08-06 20:43 -0700
    Re: Forth Performance Question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-07 01:02 -0400
      Re: Forth Performance Question Chris Hinsley <chris.hinsley@gmail.com> - 2011-08-16 12:09 +0100
        Re: Forth Performance Question stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-16 14:08 +0000
    Re: Forth Performance Question mhx@iae.nl (Marcel Hendrix) - 2011-08-07 07:45 +0200
      Re: Forth Performance Question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-07 16:18 +0000
    Re: Forth Performance Question Bruno Gauthier <bgauthier@free.fr> - 2011-08-07 07:53 +0200
    Re: Forth Performance Question Julian Fondren <ayrnieu@gmail.com> - 2011-08-07 01:01 -0500
    Re: Forth Performance Question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-07 12:50 +0000
    Re: Forth Performance Question stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-07 11:46 +0000
    Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-10 17:03 +0000
      Re: Forth Performance Question Julian Fondren <ayrnieu@gmail.com> - 2011-08-10 13:35 -0500
        Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-11 15:05 +0000
          Re: Forth Performance Question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-11 16:26 +0000
            Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-12 08:15 +0000
              Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-11 22:29 -1000
                Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-12 10:09 +0000
                  Re: Forth Performance Question Julian Fondren <ayrnieu@gmail.com> - 2011-08-12 08:15 -0500
              Re: Forth Performance Question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-12 09:31 +0000
          Re: Forth Performance Question crc <charles.childers@gmail.com> - 2011-08-11 10:27 -0700
          Re: Forth Performance Question Julian Fondren <ayrnieu@gmail.com> - 2011-08-11 13:18 -0500
          Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-11 12:00 -1000
            Re: Forth Performance Question Howerd <howerdo@yahoo.co.uk> - 2011-08-11 15:13 -0700
            Re: Forth Performance Question Charles Childers <crc_nospam@retroforth.org> - 2011-08-11 20:52 -0400
            Re: Forth Performance Question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-12 02:19 -0400
              Re: Forth Performance Question Julian Fondren <ayrnieu@gmail.com> - 2011-08-12 02:10 -0500
                Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-11 21:48 -1000
              Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-11 21:41 -1000
            Re: Forth Performance Question Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-23 18:52 -0700
      Re: Forth Performance Question Charles Childers <crc_nospam@retroforth.org> - 2011-08-10 23:33 -0400
        Re: Forth Performance Question Ron Aaron <rambamist@gmail.com> - 2011-08-11 08:59 +0300
        Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-11 13:48 +0000
          Re: Forth Performance Question Charles Childers <crc@retroforth.org> - 2011-08-11 10:30 -0400
      Re: Forth Performance Question Ron Aaron <rambamist@gmail.com> - 2011-08-11 08:46 +0300
      Re: Forth Performance Question arc <arc@vorsicht-bissig.de> - 2011-08-12 12:20 +0000
        Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-12 13:59 +0000
          Re: Forth Performance Question stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-12 15:11 +0000
            Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-12 17:49 +0000
              Re: Forth Performance Question stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-12 19:38 +0000
              Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 12:41 -1000
                Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-13 03:35 +0000
                  Re: Forth Performance Question "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 17:52 -1000
                  Re: Forth Performance Question Paul Rubin <no.email@nospam.invalid> - 2011-08-12 23:55 -0700
                  Re: Forth Performance Question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-14 09:01 +0000
                    Re: Forth Performance Question Paul Rubin <no.email@nospam.invalid> - 2011-08-14 01:36 -0700
                      Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-15 01:43 +0000
                        Re: Forth Performance Question Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-15 16:59 -0700
                          Re: Forth Performance Question Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:25 -0700
                            Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-16 11:22 +0000
                              Re: Forth Performance Question Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-16 14:37 -0700
                                Re: Forth Performance Question Arnold Doray <thinksquared@gmail.com> - 2011-08-19 14:11 +0000
                                  Re: Forth Performance Question Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 19:52 -0700
              Re: Forth Performance Question Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-13 02:28 +0200
          Re: Forth Performance Question Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-12 20:53 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4746

Arnold Doray <thinksquared@gmail.com> writes:

> On Wed, 10 Aug 2011 13:35:23 -0500, Julian Fondren wrote:
>> 
>> Except, you aren't learning Forth.  You're learning Retro. You
>> wouldn't've mixed up the arguments to DO .. LOOP if you had set out to
>> learn Forth; as a suggested barrier to Java programmers, that's just
>> absurd.
>
> Wouldn't learning Scheme help one learn Lisp? ;) IMO, the Retro language 
> set might be a comfortable introduction to Forth for programmers from a C/
> Java background. 

1. No.  I have a lot of experience behind this 'no'.

2. Common Lisp is a huge, huge language.  Forth is not.  Size, like
   flexibility, is absolutely no excuse for diving into one of the
   attractive nuisances.

> The point of the DO...LOOP example wasn't that I got the arguments mixed 
> up, but that [it's possible for anyone to mix them up.]

This is the case with all positional arguments, with a few exceptions.
DO takes positional arguments, so there's the possibility that anyone
can mix them up.  Likewise your TIMES takes a number and then a block;
someone could very well give it a block and then a number.

"X is possible." does not imply "X is an actual rather than an imaginary
problem.", and neither does "X happened to this guy who's decided not to
learn Forth control structures." make a persuasive argument.

> (I 
> am curious -- is there a reason that ANS Forth does it this way?) 

  \ 'reversed' and potentially identical on purpose.
  : prune ( -- )
    1 #polled @ 1- do  \ loop backwards, only over clients
      i pollfd[] closed? if i lost then
    -1 +loop ;

  \ although BOUNDS could be written for either ordering
  : spaced ( c-addr u -- )
    bounds ?do i c@ [char] . = if bl i c! then loop ;

  \ speaking of C, how common a kind of loop do you think
  \ for (i = 0; i < provided_number; i++) ... is ?
  : times ( xt u -- )
    0 ?do dup >r execute R> loop drop ;
  : spaces ( u -- )
    0 ?do space loop ;

> This observation might seem pedantic to an experienced Forther, but it is 
> hard for a beginner to deal with such "gotchas" at the start.

No, it isn't.  You aren't a Forth beginner.

[toc] | [prev] | [next] | [standalone]

#4747

On 8/11/11 5:05 AM, Arnold Doray wrote:
> On Wed, 10 Aug 2011 13:35:23 -0500, Julian Fondren wrote:
>>
>> Except, you aren't learning Forth.  You're learning Retro. You
>> wouldn't've mixed up the arguments to DO .. LOOP if you had set out to
>> learn Forth; as a suggested barrier to Java programmers, that's just
>> absurd.
>
> Wouldn't learning Scheme help one learn Lisp? ;) IMO, the Retro language
> set might be a comfortable introduction to Forth for programmers from a C/
> Java background.
>
> The point of the DO...LOOP example wasn't that I got the arguments mixed
> up, but that the ANS Forth DO...LOOP is equivalent to:
>
> for(int i =<start>; i =<end>; ++i){
>    ...
> }

People who are attempting to learn a human language sometimes fall into 
the trap of translating everything (input and output) into their native 
language.  It is a mistake, which slows your learning and leads to 
garbled syntax and general incoherence.

Indeed, Forth is very different from C/Java/Fortran, whatever.  Its 
entire structure and economics are different.  When I am teaching a 
Forth programming course (which I have done for 35 years), I follow the 
strategy that is so successful with Berlitz and other human language 
learning courses, which is total immersion: do not focus on "how you 
would do [this] in [your familiar language]", but instead embrace the 
few simple rules in Forth and avoid "translating".  Those rules are:

* Forth's text interpreter processes “words” separated by spaces.

* Words may be defined in the dictionary, converted as numbers and 
pushed on the stack, or rejected as “not understood”.

* Words expect parameters on the data stack, remove them, and leave 
explicit results.

That's really all there is.  Everything else involved in learning Forth 
consists of developing a vocabulary of words, for which you must 
remember what arguments they take and what results they return. The 
sooner people stop trying to translate, or applying their expectations 
from other languages to Forth, the quicker they can learn.

> Which most sane C/Java/Python/Ruby programmers would avoid due to the
> possibility of "start" exceeding "end" at the outset. The Retro "times"
> implementation matches exactly this reasonable cultural expectation. (I
> am curious -- is there a reason that ANS Forth does it this way?)

Yes.  It's because of parameters being passed on the stack.  Consider:

: star ( -- )   ." *" ;   \ Displays an asterisk
: stars ( n -- )   0 do  star loop ;   \ Displays 'n' asterisks

So, all you do to display, say, 10 stars, is to type:

10 stars

...which is very simple, logical, and readable, and a very common idiom. 
Good naming conventions help!

It is true that omitting the parameter, or asking for 0 stars will cause 
a problem, which is why Anton recommended ?do for situations in which 
the argument may be zero.

> This observation might seem pedantic to an experienced Forther, but it is
> hard for a beginner to deal with such "gotchas" at the start.

They are "gotchas" only if you cling to the expectation that Forth works 
like other languages.  If you take to heart those 3 rules, everything is 
consistent and unsurprising.

> The Retro language reduces the Forth learning curve by meeting some of
> these cultural expectations. I don't know if it does this by sacrificing
> some of the expressive power of ANS Forth, which you amply demonstrate in
> your looping examples.

I think it extends the learning curve, by teaching you a lot of false 
expectations and inappropriate habits.

>> You don't gain any freedom by throwing Forth away; you just lose Forth.
>> It's like saying "I want to wear a neon pink cowboy hat, but people give
>> me dirty looks, so - rather than wear the hat and accept the looks - I
>> guess I'll just have to move to Zimbabwe."
>
> It's more like "I want to wear a neon pink cowboy hat, so I'll start by
> wearing a cowboy hat."

No, it's more like saying "I want to learn English, so I'll start by 
learning Pidgin."  It's a distraction.

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]

#4748

Hi Elizabeth,

On Aug 11, 11:00 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
[snip]
Those rules are:

* Forth's text interpreter processes “words” separated by spaces.

* Words may be defined in the dictionary, converted as numbers and
pushed on the stack, or rejected as “not understood”.

* Words expect parameters on the data stack, remove them, and leave
explicit results.

That's really all there is.
[snip]

I like this!

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#4751

On 2011-08-11 18:00:54 -0400, Elizabeth D. Rather said:

...

> * Forth's text interpreter processes “words” separated by spaces.
> 
> * Words may be defined in the dictionary, converted as numbers and 
> pushed on the stack, or rejected as “not understood”.
> 
> * Words expect parameters on the data stack, remove them, and leave 
> explicit results.
> 
> That's really all there is.  Everything else involved in learning Forth 
> consists of developing a vocabulary of words, for which you must 
> remember what arguments they take and what results they return. The 
> sooner people stop trying to translate, or applying their expectations 
> from other languages to Forth, the quicker they can learn.

These rules are true for Retro as well.

...

>> The Retro language reduces the Forth learning curve by meeting some of
>> these cultural expectations. I don't know if it does this by sacrificing
>> some of the expressive power of ANS Forth, which you amply demonstrate in
>> your looping examples.
> 
> I think it extends the learning curve, by teaching you a lot of false 
> expectations and inappropriate habits.

I don't (and won't) promote Retro as a means of learning ANS Forth (or 
other Forth dialects). Though Retro is fundamentally similar to Forth, 
I consider it a different language. And apart from the basic rules you 
outlined, it's too different from ANS to be a good learning tool.

-- crc

[toc] | [prev] | [next] | [standalone]

#4758

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:OM2dnfp9muWFzNnTnZ2dnUVZ_sadnZ2d@supernews.com...
> [...]
> Everything else involved in learning Forth
> consists of developing a vocabulary of words, for which you must
> remember what arguments they take and what results they return.
>

"for which you must remember ..."  That's a serious enough deficiency that
one should adopt C.  Those are documented for us ...

If I haven't used a C function somewhat recently, I have to look up it's
arguments.  That's after many years of C, and with an excellent memory.
You're telling me that Forth requires you remember all the arguments to all
the functions you use?  How do you use a larger library?  I'm assuming you
must have a reference manual, ANSI spec, book, or personal notes that
you use to keep track of the parameters for larger sets of Forth words.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#4759

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:

> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:OM2dnfp9muWFzNnTnZ2dnUVZ_sadnZ2d@supernews.com...
>> [...]
>> Everything else involved in learning Forth
>> consists of developing a vocabulary of words, for which you must
>> remember what arguments they take and what results they return.
>>
>
> "for which you must remember ..."  That's a serious enough deficiency that
> one should adopt C.  Those are documented for us ...
>
> If I haven't used a C function somewhat recently, I have to look up it's
> arguments.  That's after many years of C, and with an excellent memory.
> You're telling me that Forth requires you remember all the arguments to all
> the functions you use?  How do you use a larger library?  I'm assuming you
> must have a reference manual, ANSI spec, book, or personal notes that
> you use to keep track of the parameters for larger sets of Forth words.
>
>
> Rod Pemberton

I'll interpret this as a roundabout way of asking "hey, how do Forth
programmers look up the usage of a word?"  As a slap isn't an option.

1. LOCATE <word> and then EDIT , to first get the stack comment and then
   pull up the file in which a word is defined, for context.

2. dpANS, reference manual, library documentation, etc.

3. Editor extensions to perform #1 or #2 on a word.

4. System environment extensions (e.g., right-clicking on a selected
   word) to perform #1 or #2.

So, nothing special.  Although LOCATE EDIT is a godly combo.

[toc] | [prev] | [next] | [standalone]

#4761

On 8/11/11 9:10 PM, Julian Fondren wrote:
> "Rod Pemberton"<do_not_have@noavailemail.cmm>  writes:
...
>> If I haven't used a C function somewhat recently, I have to look up it's
>> arguments.  That's after many years of C, and with an excellent memory.
>> You're telling me that Forth requires you remember all the arguments to all
>> the functions you use?  How do you use a larger library?  I'm assuming you
>> must have a reference manual, ANSI spec, book, or personal notes that
>> you use to keep track of the parameters for larger sets of Forth words.
>>
>>
>> Rod Pemberton
>
> I'll interpret this as a roundabout way of asking "hey, how do Forth
> programmers look up the usage of a word?"  As a slap isn't an option.
>
> 1. LOCATE<word>  and then EDIT , to first get the stack comment and then
>     pull up the file in which a word is defined, for context.
>
> 2. dpANS, reference manual, library documentation, etc.
>
> 3. Editor extensions to perform #1 or #2 on a word.
>
> 4. System environment extensions (e.g., right-clicking on a selected
>     word) to perform #1 or #2.
>
> So, nothing special.  Although LOCATE EDIT is a godly combo.

Fortunately, some systems (the ones I'm familiar with) show you the 
source plus several lines above and below in response to LOCATE <name> 
(as well as the right-click options).  EDIT is only necessary if you 
want to see the whole file, or make a change.

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]

#4760

On 8/11/11 8:19 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> news:OM2dnfp9muWFzNnTnZ2dnUVZ_sadnZ2d@supernews.com...
>> [...]
>> Everything else involved in learning Forth
>> consists of developing a vocabulary of words, for which you must
>> remember what arguments they take and what results they return.
>>
>
> "for which you must remember ..."  That's a serious enough deficiency that
> one should adopt C.  Those are documented for us ...
>
> If I haven't used a C function somewhat recently, I have to look up it's
> arguments.  That's after many years of C, and with an excellent memory.
> You're telling me that Forth requires you remember all the arguments to all
> the functions you use?  How do you use a larger library?  I'm assuming you
> must have a reference manual, ANSI spec, book, or personal notes that
> you use to keep track of the parameters for larger sets of Forth words.
>
>
> Rod Pemberton

I certainly didn't mean that memory is your only recourse.  Forth as a 
language is well-documented in the Standard and various books, and the 
better Forth systems have extensive supporting documentation, as do 
professionally-written applications.  So, just as you have C 
documentation to fall back on, there is Forth documentation to support 
learners and folks with rusty memories.  But people who use Forth 
regularly do develop a considerable working vocabulary of words whose 
stack behavior they remember, just as one remembers verb forms, tenses, 
etc., in human languages one uses regularly. By the end of one of my 
courses students have a working vocabulary of a hundred or so words. A 
full-time Forth programmer probably has a working vocabulary of several 
hundred words, maybe more.

Nobody wants to take the time to look up every word every time, in any 
language.

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]

#5183

On Aug 11, 4:00 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> Indeed, Forth is very different from C/Java/Fortran, whatever.  Its
> entire structure and economics are different.  When I am teaching a
> Forth programming course (which I have done for 35 years), I follow the
> strategy that is so successful with Berlitz and other human language
> learning courses, which is total immersion: do not focus on "how you
> would do [this] in [your familiar language]", but instead embrace the
> few simple rules in Forth and avoid "translating".  Those rules are:
>
> * Forth's text interpreter processes “words” separated by spaces.
>
> * Words may be defined in the dictionary, converted as numbers and
> pushed on the stack, or rejected as “not understood”.
>
> * Words expect parameters on the data stack, remove them, and leave
> explicit results.
>
> That's really all there is.  Everything else involved in learning Forth
> consists of developing a vocabulary of words, for which you must
> remember what arguments they take and what results they return.

Apparently your "total immersion" doesn't involve telling the student
about compile-time code?

I have met a lot of C programmers who claim to know everything there
is to know about Forth, and who in the next breath will say that Forth
is stupid. Invariably, they believe that the only distinguishing
characteristic of Forth is that it uses postfix rather than infix
notation. They believe this is the result of the Forthers trying to be
cute and/or is the result of the Forthers being too dumb to figure out
how to implement infix (implementing infix involves recursion! Gah!)
They must be graduates of your class, as they believe that postfix
notation is "really all there is" --- they have never heard about how
Forth allows the programmer to write code that executes at compile-
time, or they vaguely assume that this is something similar to #DEFINE
in C.

> > Which most sane C/Java/Python/Ruby programmers would avoid due to the
> > possibility of "start" exceeding "end" at the outset. The Retro "times"
> > implementation matches exactly this reasonable cultural expectation. (I
> > am curious -- is there a reason that ANS Forth does it this way?)
>
> Yes.  It's because of parameters being passed on the stack.  Consider:
>
> : star ( -- )   ." *" ;   \ Displays an asterisk
> : stars ( n -- )   0 do  star loop ;   \ Displays 'n' asterisks
>
> So, all you do to display, say, 10 stars, is to type:
>
> 10 stars
>
> ...which is very simple, logical, and readable, and a very common idiom.
> Good naming conventions help!

When I was 18 years old (1984) and learning Forth, I saw compile-time
code as being the distinguishing feature of Forth (as compared to
Pascal, that has the distinguishing feature of rigid type-checking).
That is *why* I totally immersed myself in Forth rather than in
Pascal. You're still using that STARS example from "Starting Forth,"
and you are totally failing to consider that there is more to Forth
than syntax. You aren't giving the students any reason to totally
immerse themselves in Forth --- they just think that all of that
postfix stuff is ugly and dumb --- nobody is going to take that class
unless they are getting paid to do so, and they are going to fidget in
their seats and watch the clock the entire time.

[toc] | [prev] | [next] | [standalone]

#4714

On 2011-08-10 13:03:38 -0400, Arnold Doray said:

> : foo 1 1000000 * drop ;

...

> : test 1 100000000 [ foo ] times ;
...

> Unfortunately, unless I am mistaken, Retro is slow: My test above shows
> that it is more than 10x slower than Gforth.

Retro's performance is largely dependant on the VM implementation being 
used. For me, the current C, Python, and Forth implementations are fast 
enough, and I'm (unfortunately) short on time to work on improving 
performance. When I have time to spare, I'll be looking into developing 
a faster VM, but until then other projects are higher priority for me.

For now, on my Mac, I can build a slightly modified VM that completes 
running the code here in a bit over 12 seconds (down from 57 seconds 
for a non-optimized build and 32 seconds for one built with -O3). See 
http://rx-core.org/dev/corpse/article/131 and 
https://gist.github.com/1138806 for some details on what I did to 
achieve this.

For gforth, I get a speed of 3 seconds. So Retro is still noticeably 
slower, but the patched VM is at least a little closer.

-- crc

[toc] | [prev] | [next] | [standalone]

#4720

On 08/11/2011 06:33 AM, Charles Childers wrote:

> For gforth, I get a speed of 3 seconds. So Retro is still noticeably
> slower, but the patched VM is at least a little closer.

Using this code saved in the file 't.f':

: times ( n xt -- ) swap 0 do dup execute loop drop ;
: foo 1 1000000 * drop ;
: test 1 100000000 ['] foo times ;
test bye



I get these results with Gforth and Reva:

me $ time reva t.f

real    0m0.332s
user    0m0.328s
sys     0m0.000s

me $ time gforth t.f

real    0m1.577s
user    0m1.516s
sys     0m0.000s


The system I'm using is quite fast; so adding one more zero to the
'test' iteration gives me gforth at 15.075s (real) and reva at 3.254s
(real).

Of course, if Reva did any optimization on 'foo' ... but it doesn't.

[toc] | [prev] | [next] | [standalone]

#4730

I notice that in Retro 11, "times" leaves the first parameter on the 
stack after the loop exits. Is this by design? 

: test 100 200 [ 1 drop ] times ; 
test 
putn
>>> 100 

It would be nice for the VM not to exit on an error. Makes interactivity 
much more easier. 

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#4731

In article <j20mii$ej5$1@dont-email.me>, thinksquared@gmail.com says...

> I notice that in Retro 11, "times" leaves the first parameter on the 
> stack after the loop exits. Is this by design? 

Yes. From the documentation:

+--------+-----+----------------------+
| times  | nq- | Run quote (n) times  |
+--------+-----+----------------------+

> It would be nice for the VM not to exit on an error. Makes 
interactivity 
> much more easier. 

I'll work on this tonight. Should be pretty easy to trap the common 
things causing the VM to exit and report them rather than just dieing 
silently.

-- crc

[toc] | [prev] | [next] | [standalone]

#4718

On 08/10/2011 08:03 PM, Arnold Doray wrote:

> I am actually interested in Retro (small VM, which seems to be easy to 
> extend; reasonably good documentation and IMO nice language coverage)

...

> Unfortunately, unless I am mistaken, Retro is slow: My test above shows 
> that it is more than 10x slower than Gforth. 


You might then be interested in Reva, which derives from Retro (but
forked almost six years ago).  It does not use a VM, but rather compiles
native code (with no optimizations except tail-recursion elimination).

In most scenarios it is about as fast as unoptimized C, and is usually
considerably faster than Gforth.  The actual binary (reva or reva.exe)
is around 30K or so, but the sources, support libraries and binaries for
the three supported OSes, and documentation/examples beef up the
distributed package to almost 10M.

[toc] | [prev] | [next] | [standalone]

#4773

Arnold, 

May I ask, why are you learning Forth? 

Do you have an immediate practical problem for which speed is critical? 
If not, why this concern with performance? 

If you are seeking to learn new concepts and new ways of expressing
yourself, then why are you being so timid?  There's no point in learning
a new language if you're going to shoehorn it into being C.  Trying to
program in C in Forth strikes me as a recipe for frustration and
disenchantment. I'm sure C is a better C than Forth will ever be. 

The best way to learn to program in a new language is by programming in
the new language -- not programming in an old language in the new
language.  There's a certain amount of diving into the deep end that has
to happen.

I'm sure you're quite capable of it.  There's no need to fear the
looping constructs. 

(I'm quite new at this myself) 

-arc

[toc] | [prev] | [next] | [standalone]

#4776

On Fri, 12 Aug 2011 12:20:39 +0000, arc wrote:
> May I ask, why are you learning Forth?
> 
> Do you have an immediate practical problem for which speed is critical?
> If not, why this concern with performance?

I hope to write a mapreduce framework in Forth. So speed and portability 
are important. I chose Forth because you can build efficient DSLs on top 
of it relatively easily. This is much harder to do in other languages. 

> 
> If you are seeking to learn new concepts and new ways of expressing
> yourself, then why are you being so timid?  There's no point in learning
> a new language if you're going to shoehorn it into being C.  Trying to
> program in C in Forth strikes me as a recipe for frustration and
> disenchantment. I'm sure C is a better C than Forth will ever be.
> 

I'm not being timid, neither am I trying to shoehorn Forth into C. 

But I am documenting my own learning process so that others from a C/Java 
background might perhaps benefit. Compared with other languages, I feel 
that there is a lack of Forth tutorials/books with a practical bent aimed 
at someone with a C/Java background.  

The "total immersion" method is one approach, but I suspect you'd have to 
be extremely motivated (eg, your boss mandates that you take the course) 
for it to work. Most people learning a new programming language would 
implicitly ask themselves "how do I do X in this language?" 

In my own experience, it seems that people learn best by analogy, 
mentally mapping what they know into the unknown. Of course there's a 
good amount of deep diving, but it helps to have some familiar footholds.

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#4780

On Fri, 12 Aug 2011 13:59:09 +0000 (UTC), Arnold Doray
<thinksquared@gmail.com> wrote:

>But I am documenting my own learning process so that others from a C/Java 
>background might perhaps benefit. Compared with other languages, I feel 
>that there is a lack of Forth tutorials/books with a practical bent aimed 
>at someone with a C/Java background.  

Which ones have you read and what was wrong with them? I ask as an
author of a book on Forth.
  http://www.mpeforth.com/books.htm

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]

#4783

On Fri, 12 Aug 2011 15:11:32 +0000, Stephen Pelc wrote:
> Which ones have you read and what was wrong with them? I ask as an
> author of a book on Forth.
>   http://www.mpeforth.com/books.htm
> 

Stephen, 

I haven't read your book, but it was one of the first few that I 
evaluated in some detail to put on my Forth reading list.

My overall impression was that it looks like an excellent introduction to 
Forth for embedded programming. 

But I'm primarily interested in general application development in Forth, 
so please take my comments below in that light! 

Some things I didn't like:
Nothing on network programming. Nothing on the existing opensource Forth 
libraries, and their use. The application examples (Dairy/PhoneBook) are 
neither interesting nor realistic. Perhaps a tiny Forth web server? Or a 
HTML code documenter for Forth (like javadoc)? Or a game? Or implementing 
a simple Ethernet packet protocol, like the one in Circuit Cellar 
magazine? Your overall approach is to introduce words, but leave it to 
the reader to do something with it. The book doesn't seem to impart to 
the reader much about good Forth technique. Not much on string 
processing. You don't teach how to write usable libraries. 

Some things I liked:
You cover multitasking, but only over a few pages. You cover mixed 
language programming, but again, only a couple of pages. You have 
exercises. And answers! But it might be better for these to be sprinkled 
throughout the text instead of all in one chapter towards the end of the 
book. You have a good discussion on Forth internals. I like your date 
validation example. I like the humor - "call by text editor" indeed! 

I fully appreciate that your book doesn't set out to address these 
issues, perhaps because it is primarily focused on the needs of your 
clients, who are likely from the embedded sector.

All of the other books/online resources I have evaluated have similar 
shortcomings, or are outdated, or out of print (eg, Julian V Noble's 
Scientific Forth. I have searched high and low for this book but no 
luck!). 

I have not yet had the opportunity to evaluate any of EDR's books. I will 
be away on sabbatical and they won't ship in time. 

I'm currently reading the Gforth tutorial and manual, after which I will 
probably try to make sense of Hugh Aguilar's "novice" package.

Cheers,
Arnold





 

[toc] | [prev] | [next] | [standalone]

#4790

On Fri, 12 Aug 2011 17:49:12 +0000 (UTC), Arnold Doray
<thinksquared@gmail.com> wrote:

>Some things I didn't like:
>Nothing on network programming.

If it's Winsock or BSD API, there are a squillion books to choose
from. It really isn't the job of a language primer to cover that
sort of stuff.

> Nothing on the existing opensource Forth libraries, and their use.

Again, those are application programming issues. I agree that 
librariy code is essential, but the compendium books ... library
A ... B ... C are deadly dull IMHO.

> The application examples (Dairy/PhoneBook) are neither interesting
> nor realistic.

It's a question of scale.

> Perhaps a tiny Forth web server? Or a 
>HTML code documenter for Forth (like javadoc)? Or a game? Or implementing 
>a simple Ethernet packet protocol, like the one in Circuit Cellar 
>magazine? Your overall approach is to introduce words, but leave it to 
>the reader to do something with it. The book doesn't seem to impart to 
>the reader much about good Forth technique. Not much on string 
>processing. You don't teach how to write usable libraries. 

Guilty as charged. MPE sells a TCP/IP stack and we know how complex
it really is. We ship DocGen (rather like Doxygen, but better) with
our systems.

In C, string processing is a library issue. The book made the
apparently foolish assumption that its readers already know
how to program.

Anyway, thanks for the feedback.

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]

#4796

On 8/12/11 7:49 AM, Arnold Doray wrote:
> On Fri, 12 Aug 2011 15:11:32 +0000, Stephen Pelc wrote:
>> Which ones have you read and what was wrong with them? I ask as an
>> author of a book on Forth.
>>    http://www.mpeforth.com/books.htm

As an author of several books on Forth, I have a keen interest in this 
topic, too!

...
> Nothing on network programming. Nothing on the existing opensource Forth
> libraries, and their use. The application examples (Dairy/PhoneBook) are
> neither interesting nor realistic. Perhaps a tiny Forth web server? Or a
> HTML code documenter for Forth (like javadoc)? Or a game? Or implementing
> a simple Ethernet packet protocol, like the one in Circuit Cellar
> magazine? Your overall approach is to introduce words, but leave it to
> the reader to do something with it. The book doesn't seem to impart to
> the reader much about good Forth technique. Not much on string
> processing. You don't teach how to write usable libraries.

It's very difficult to write a book that's good at being a basic 
introduction to a language and also takes on advanced programming topics 
like networking or writing web servers.  One has to walk before one can run.

I try in my books to address style issues.  Although it's dated on 
technical details, Brodie's Thinking Forth is good on style, as well.

Libraries in Forth aren't really formal things.  Basically, all you do 
is set up a file that INCLUDEs the other files that constitute a set of 
tools that work together, give it a name, and INCLUDE it in applications 
that need it.

...
>
> I have not yet had the opportunity to evaluate any of EDR's books. I will
> be away on sabbatical and they won't ship in time.

My Forth Programmer's Handbook is included as a pdf with the free 
evaluation version of SwiftForth at www.forth.com.  You can have it 
today!  But Forth Application Techniques is more of a tutorial.

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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web