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

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

MISC - Stack Based vs. Register Based

Started byrickman <gnuarm@gmail.com>
First post2013-03-29 17:00 -0400
Last post2013-04-15 19:28 +0200
Articles 17 on this page of 117 — 25 participants

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

Contents

  MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-03-29 17:00 -0400
    Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-03-29 21:43 +0000
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-03-29 20:28 -0400
        Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-03-31 18:34 +0000
          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 09:54 -0400
            Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-02 17:20 +0000
              Re: MISC - Stack Based vs. Register Based David Brown <david@westcontrol.removethisbit.com> - 2013-04-03 09:12 +0200
      Re: MISC - Stack Based vs. Register Based Jon Elson <jmelson@wustl.edu> - 2013-04-01 15:11 -0500
    Re: MISC - Stack Based vs. Register Based AKE <assadebrahim2000@gmail.com> - 2013-03-29 18:19 -0700
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-03-30 18:50 -0400
        Re: MISC - Stack Based vs. Register Based Jecel <jecel@merlintec.com> - 2013-04-01 13:18 -0700
          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 10:50 -0400
            Re: MISC - Stack Based vs. Register Based Jecel <jecel@merlintec.com> - 2013-04-02 23:39 -0700
              Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-03 09:54 -0400
                Re: MISC - Stack Based vs. Register Based Jecel <jecel@merlintec.com> - 2013-04-05 14:30 -0700
                  Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 17:53 -0400
                    Re: MISC - Stack Based vs. Register Based Jecel <jecel@merlintec.com> - 2013-04-06 13:27 -0700
                      Re: MISC - Stack Based vs. Register Based Jecel <jecel@merlintec.com> - 2013-04-06 13:37 -0700
          Re: MISC - Stack Based vs. Register Based Paul Rubin <no.email@nospam.invalid> - 2013-04-07 15:21 -0700
            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-08 01:24 -0400
              Re: MISC - Stack Based vs. Register Based Syd Rumpo <usenet@nononono.co.uk> - 2013-04-08 10:18 +0100
            Re: MISC - Stack Based vs. Register Based Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-08 04:18 -0500
    Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-03-30 08:20 +0100
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-03-30 19:00 -0400
        Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-03-31 13:20 +0200
    Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-30 17:54 -0400
      Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-03-31 09:11 +0200
        Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-01 20:10 -0400
          Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-02 00:54 +0000
            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 13:31 -0400
              Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-02 19:03 +0000
          Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-02 08:25 +0200
            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 13:33 -0400
          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 13:26 -0400
            Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-03 20:34 -0400
              Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-04 02:07 +0000
                Re: MISC - Stack Based vs. Register Based albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-04 11:16 +0000
                  Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-04 13:25 +0200
                    Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-04 12:44 +0000
                      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-04 17:04 -0400
                        Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-04 21:34 +0000
                          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-04 19:30 -0400
                            Re: MISC - Stack Based vs. Register Based Mark Wills <markrobertwills@yahoo.co.uk> - 2013-04-05 00:41 -0700
                        Re: MISC - Stack Based vs. Register Based Alex McDonald <blog@rivadpm.com> - 2013-04-04 15:30 -0700
                          Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-04 23:15 +0000
                            Re: MISC - Stack Based vs. Register Based Alex McDonald <blog@rivadpm.com> - 2013-04-04 17:26 -0700
                        Re: MISC - Stack Based vs. Register Based albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-05 01:17 +0000
                          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 18:00 -0400
                          Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:55 -0400
                  Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-04 20:07 -0400
                    Re: MISC - Stack Based vs. Register Based Mark Wills <markrobertwills@yahoo.co.uk> - 2013-04-05 00:51 -0700
                      Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-05 14:31 +0200
                        Re: MISC - Stack Based vs. Register Based Mark Wills <markrobertwills@yahoo.co.uk> - 2013-04-05 07:33 -0700
                          Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-05 17:01 +0200
                            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 18:25 -0400
                          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-06 17:44 -0400
                        Re: MISC - Stack Based vs. Register Based Brad Eckert <hwfwguy@gmail.com> - 2013-04-05 10:14 -0700
                          Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-05 20:13 +0200
                            Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-05 20:15 +0200
                            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 18:54 -0400
                            Re: MISC - Stack Based vs. Register Based Brad Eckert <hwfwguy@gmail.com> - 2013-04-08 09:57 -0700
                              Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-09 10:13 -0400
                                Re: MISC - Stack Based vs. Register Based Brad Eckert <hwfwguy@gmail.com> - 2013-04-09 08:55 -0700
                                  Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-09 14:40 -0400
                          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 18:49 -0400
                            Re: MISC - Stack Based vs. Register Based daveyrotten <danw8804@gmail.com> - 2013-04-09 13:02 -0700
                              Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-09 16:07 -0400
                                Re: MISC - Stack Based vs. Register Based daveyrotten <danw8804@gmail.com> - 2013-04-09 13:26 -0700
                                  Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-10 00:33 -0400
                                    Re: MISC - Stack Based vs. Register Based daveyrotten <danw8804@gmail.com> - 2013-04-10 07:08 -0700
                                      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-10 10:13 -0400
                                        Re: MISC - Stack Based vs. Register Based Sieur de Bienville <morrimichael@gmail.com> - 2013-04-10 21:08 -0700
                                          Re: MISC - Stack Based vs. Register Based Paul Rubin <no.email@nospam.invalid> - 2013-04-10 22:47 -0700
                                            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-11 16:32 -0400
                                          Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-18 06:23 -0400
                                            Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-18 17:06 -0400
                        Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-05 17:33 +0000
                        Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-06 17:37 -0400
                      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 18:08 -0400
                      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-06 17:32 -0400
                        Re: MISC - Stack Based vs. Register Based Brian Davis <brimdavis@aol.com> - 2013-04-07 14:59 -0700
                          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-08 01:16 -0400
                            Re: MISC - Stack Based vs. Register Based albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-08 09:52 +0000
              Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-03 22:42 -0400
              Re: MISC - Stack Based vs. Register Based Alex McDonald <blog@rivadpm.com> - 2013-04-04 16:07 -0700
                Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-05 04:10 +0000
                  Re: MISC - Stack Based vs. Register Based Alex McDonald <blog@rivadpm.com> - 2013-04-04 23:49 -0700
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-02 12:04 -0400
        Re: MISC - Stack Based vs. Register Based "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-03 20:35 -0400
          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-04 00:09 -0400
    Re: MISC - Stack Based vs. Register Based the_gavino_himself <visphatesjava@gmail.com> - 2013-04-02 11:17 -0700
    Re: MISC - Stack Based vs. Register Based Syd Rumpo <usenet@nononono.co.uk> - 2013-04-04 09:38 +0100
      Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-04 11:31 +0200
        Re: MISC - Stack Based vs. Register Based "Elizabeth D. Rather" <erather@forth.com> - 2013-04-04 08:36 -1000
          Re: MISC - Stack Based vs. Register Based Brad Eckert <hwfwguy@gmail.com> - 2013-04-05 10:21 -0700
            Re: MISC - Stack Based vs. Register Based "Elizabeth D. Rather" <erather@forth.com> - 2013-04-05 07:53 -1000
      Re: MISC - Stack Based vs. Register Based glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-04-04 12:49 +0000
        Re: MISC - Stack Based vs. Register Based Arlet Ottens <usenet+5@c-scape.nl> - 2013-04-04 15:02 +0200
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-04 18:57 -0400
    Re: MISC - Stack Based vs. Register Based AKE <assadebrahim2000@gmail.com> - 2013-04-05 15:29 -0700
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-05 19:32 -0400
        Re: MISC - Stack Based vs. Register Based anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-06 14:16 +0000
          Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-06 15:50 -0400
            Re: MISC - Stack Based vs. Register Based mhx@iae.nl (Marcel Hendrix) - 2013-04-07 01:33 +0200
              Re: MISC - Stack Based vs. Register Based AKE <assadebrahim2000@gmail.com> - 2013-04-07 02:57 -0700
                Re: MISC - Stack Based vs. Register Based stephenXXX@mpeforth.com (Stephen Pelc) - 2013-04-07 11:02 +0000
                Re: MISC - Stack Based vs. Register Based anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-07 13:51 +0000
                  Re: MISC - Stack Based vs. Register Based "Elizabeth D. Rather" <erather@forth.com> - 2013-04-07 09:16 -1000
              Re: MISC - Stack Based vs. Register Based anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-07 14:13 +0000
                Re: MISC - Stack Based vs. Register Based mhx@iae.nl (Marcel Hendrix) - 2013-04-07 17:14 +0200
                  Re: MISC - Stack Based vs. Register Based anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-07 15:31 +0000
              Re: MISC - Stack Based vs. Register Based Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 18:53 +0200
            Re: MISC - Stack Based vs. Register Based anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-07 14:22 +0000
    Re: MISC - Stack Based vs. Register Based "WJ" <w_a_x_man@yahoo.com> - 2013-04-14 00:19 +0000
      Re: MISC - Stack Based vs. Register Based rickman <gnuarm@gmail.com> - 2013-04-14 09:44 -0400
      Re: MISC - Stack Based vs. Register Based Brad Eckert <hwfwguy@gmail.com> - 2013-04-15 09:39 -0700
        Re: MISC - Stack Based vs. Register Based Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-15 19:28 +0200

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#21447

Fromrickman <gnuarm@gmail.com>
Date2013-04-05 19:32 -0400
Message-ID<kjnmph$gmu$1@dont-email.me>
In reply to#21443
On 4/5/2013 6:29 PM, AKE wrote:
> On Friday, March 29, 2013 9:00:50 PM UTC, rickman wrote:
>>
>> In the thread on stack ops it was pointed out repeatedly that very often
>> the stack operands would be optimized to register operands, meaning they
>> wouldn't need to do the stack ops at all really.  So I took a look at a
>> register based MISC design.  Guess what, I don't see the disadvantage!
>
> Anton Ertl has an interesting page here in which he compares the performance of a number of Forths on a collection of benchmarks.
>
> http://www.complang.tuwien.ac.at/forth/performance.html
>
> The relevant quote is below:
>
> 'These results also show that the following statement has not become outdated yet: ``The resulting machine code is a factor of two or three slower than the equivalent code written in machine language, due mainly to the use of the stack rather than registers.'' [Ros86]'
>
> If I'm understanding this correctly, I think it is in support of your thought that MISC + registers may be a winning combination.

I'm not sure this is still a relevant quote.  The footnote is Ros86 
which I believe means it was in 1986, no?  That nearly 30 years ago!

-- 

Rick

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

#21460

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-04-06 14:16 +0000
Message-ID<2013Apr6.161619@mips.complang.tuwien.ac.at>
In reply to#21447
rickman <gnuarm@gmail.com> writes:
>On 4/5/2013 6:29 PM, AKE wrote:
>> Anton Ertl has an interesting page here in which he compares the performance of a number of Forths on a collection of benchmarks.
>>
>> http://www.complang.tuwien.ac.at/forth/performance.html
>>
>> The relevant quote is below:
>>
>> 'These results also show that the following statement has not become outdated yet: ``The resulting machine code is a factor of two or three slower than the equivalent code written in machine language, due mainly to the use of the stack rather than registers.'' [Ros86]'
>>
>> If I'm understanding this correctly, I think it is in support of your thought that MISC + registers may be a winning combination.
>
>I'm not sure this is still a relevant quote.  The footnote is Ros86 
>which I believe means it was in 1986, no?  That nearly 30 years ago!

So what?  The part that AKE cited says that it had not become outdated
when the page above was written (which was in 1996 or shortly after).
If it held true for so long, it might still hold true today.  If you
want to know, go out an measure it!  The page contains the measured
code, so it's not that hard.  Current iForth and VFX might do better
(or maybe not), but for everything else I expect that the factor of
2-3 still holds.

- 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 2013: http://www.euroforth.org/ef13/

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

#21462

Fromrickman <gnuarm@gmail.com>
Date2013-04-06 15:50 -0400
Message-ID<kjpu5p$vi6$1@dont-email.me>
In reply to#21460
On 4/6/2013 10:16 AM, Anton Ertl wrote:
> rickman<gnuarm@gmail.com>  writes:
>> On 4/5/2013 6:29 PM, AKE wrote:
>>> Anton Ertl has an interesting page here in which he compares the performance of a number of Forths on a collection of benchmarks.
>>>
>>> http://www.complang.tuwien.ac.at/forth/performance.html
>>>
>>> The relevant quote is below:
>>>
>>> 'These results also show that the following statement has not become outdated yet: ``The resulting machine code is a factor of two or three slower than the equivalent code written in machine language, due mainly to the use of the stack rather than registers.'' [Ros86]'
>>>
>>> If I'm understanding this correctly, I think it is in support of your thought that MISC + registers may be a winning combination.
>>
>> I'm not sure this is still a relevant quote.  The footnote is Ros86
>> which I believe means it was in 1986, no?  That nearly 30 years ago!
>
> So what?  The part that AKE cited says that it had not become outdated
> when the page above was written (which was in 1996 or shortly after).
> If it held true for so long, it might still hold true today.  If you
> want to know, go out an measure it!  The page contains the measured
> code, so it's not that hard.  Current iForth and VFX might do better
> (or maybe not), but for everything else I expect that the factor of
> 2-3 still holds.

Except that unless I am missing something this doesn't hold.  The 
analysis completely ignores the results of FLK which appears to be a 
Forth.  The reported speeds are 0.83 to 1.99 compared to f2c.opt and 
compares similarly to the hand coded C an even is faster in the fib 
benchmark where both references score a 1.00.

Is there a reason why this Forth was tested, but not included in the 
analysis?

-- 

Rick

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

#21473

Frommhx@iae.nl (Marcel Hendrix)
Date2013-04-07 01:33 +0200
Message-ID<03700296998434@frunobulax.edu>
In reply to#21462
rickman <gnuarm@gmail.com> writes Re: MISC - Stack Based vs. Register Based

> On 4/6/2013 10:16 AM, Anton Ertl wrote:
>> rickman<gnuarm@gmail.com>  writes:
[..]
>> So what?  The part that AKE cited says that it had not become outdated
>> when the page above was written (which was in 1996 or shortly after).
>> If it held true for so long, it might still hold true today.  If you
>> want to know, go out an measure it!  The page contains the measured
>> code, so it's not that hard.  Current iForth and VFX might do better
>> (or maybe not), but for everything else I expect that the factor of
>> 2-3 still holds.
[..]

I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.

#                sieve  bubble  matmul   fib    ssa   mm-rtcg
# gforth         0.285  0.376   0.223   0.334  0.269   0.322
# gforth-fast    0.250  0.300   0.176   0.267  0.224   0.501
# SF 3.4.2       0.119  0.146   0.042   0.048  0.056   0.541 
# Vfx 4.5        0.094  0.109   0.031   0.047  0.031   0.234
# iForth 4.0     0.089  0.088   0.020   0.082  0.037   0.420
# gcc manual     0.071  0.086   0.028   0.052
# f2c            0.070  0.074   0.036   0.052

                 f2c  gforth gforth-fast SF3.4.2  Vfx 4.5 iForth 4.0  gcc
# sieve		 1    4.1    3.6         1.7      1.34    1.27        1 
# bubble         1    5.1    4.1         1.98     1.5     1.19        1.16
# matmul	 1?   6.2    4.9         1.17     0.86    0.56 	      0.78
# fib		 1    6.4    5.13        0.92     0.9     1.58        1

# (old) Webpage results
#               f2c   gcc   iForth  Gforth   
# sieve        1.00   0.86   2.16    5.05   
# bubble       1.00   0.87   2.32    6.25   
# matmul       1.00   1.10   2.19    5.92   
# fib          1.00   1.00   1.32    3.79   

1) The matmul test for f2c core-dumps. 
2) The Sieve algorithm for the manual C program is not the same as Forth uses.
3) iForth 4.0 and the C-manual programs are 64bit program, the others 32bit
4) The results for fib are a parlor trick for most compilers

-marcel

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

#21480

FromAKE <assadebrahim2000@gmail.com>
Date2013-04-07 02:57 -0700
Message-ID<2d6c1a20-677b-40c4-8b7b-ac615f44d1d4@googlegroups.com>
In reply to#21473
On Sunday, April 7, 2013 12:33:00 AM UTC+1, Marcel Hendrix wrote:
> 
> 
> I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
> 
> #                sieve  bubble  matmul   fib    ssa   mm-rtcg
> # gforth         0.285  0.376   0.223   0.334  0.269   0.322
> # gforth-fast    0.250  0.300   0.176   0.267  0.224   0.501
> # SF 3.4.2       0.119  0.146   0.042   0.048  0.056   0.541 
> # Vfx 4.5        0.094  0.109   0.031   0.047  0.031   0.234
> # iForth 4.0     0.089  0.088   0.020   0.082  0.037   0.420
> # gcc manual     0.071  0.086   0.028   0.052
> # f2c            0.070  0.074   0.036   0.052
> 
>

Broadly speaking, it looks like these tests segment Forths/compilers into roughly three classes:

Gforth        SwiftForth         VFX/iForth/Gcc/f2c


where moving from left to right gives a non-trivial speed-up (relative to the previous class).

I don't know much about the differences between the various Forths -- what roughly would be the reason why VFX or iForth posts significantly better times than Gforth?  

Is it a difference in compiler technology?  Threading mode?  Or perhaps something about the test cases?

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

#21481

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-04-07 11:02 +0000
Message-ID<51615159.176305855@news.demon.co.uk>
In reply to#21480
On Sun, 7 Apr 2013 02:57:18 -0700 (PDT), AKE
<assadebrahim2000@gmail.com> wrote:

>I don't know much about the differences between the various
>Forths -- what roughly would be the reason why VFX or iForth
>posts significantly better times than Gforth?  

iForth and VFX Forth use analytical code generators - they
model the Forth data stack at the very least. This reduces
the number of instructions generated, and also reduces the
amount of memory traffic. Far more is carried in registers.

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]

#21484

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-04-07 13:51 +0000
Message-ID<2013Apr7.155132@mips.complang.tuwien.ac.at>
In reply to#21480
AKE <assadebrahim2000@gmail.com> writes:
>On Sunday, April 7, 2013 12:33:00 AM UTC+1, Marcel Hendrix wrote:
>> 
>> 
>> I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
>> 
>> #                sieve  bubble  matmul   fib    ssa   mm-rtcg
>> # gforth         0.285  0.376   0.223   0.334  0.269   0.322
>> # gforth-fast    0.250  0.300   0.176   0.267  0.224   0.501
>> # SF 3.4.2       0.119  0.146   0.042   0.048  0.056   0.541 
>> # Vfx 4.5        0.094  0.109   0.031   0.047  0.031   0.234
>> # iForth 4.0     0.089  0.088   0.020   0.082  0.037   0.420
>> # gcc manual     0.071  0.086   0.028   0.052
>> # f2c            0.070  0.074   0.036   0.052
>> 
>>
>
>Broadly speaking, it looks like these tests segment Forths/compilers into roughly three classes:
>
>Gforth        SwiftForth         VFX/iForth/Gcc/f2c
>
>
>where moving from left to right gives a non-trivial speed-up (relative to the previous class).
>
>I don't know much about the differences between the various Forths -- what roughly would be the reason why VFX or iForth posts significantly better times than Gforth?  
>
>Is it a difference in compiler technology?

Yes.  Gforth is based on a threaded code interpreter, with various
techniques that make it a good bit faster (if there is nothing
blocking them; there are quite big variations between builds of Gforth
because of this [*]; I usually see a better speedup from gforth-fast
over gforth).  Swiftforth is a subroutine-threaded system with
inlining and high-level peephole optimization (what Gforth calls
static superinstructions).  VFX and iForth are more sophisticated
("analytic") compilers that allocate stack items to registers, and
should not have the problem that Rose mentioned to the same degree.

>  Or perhaps something about the test cases?

It seems that these small benchmarks are more amenable to optimization
than most application benchmarks.

[*] E.g., from Gforth's Benchres file:

sieve bubble matrix  fib
 0.152 0.208  0.076 0.244 gforth-fast 0.7.0; Core 2 3GHz (Xeon 5160) 64 bits;
                          gcc-4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

- 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 2013: http://www.euroforth.org/ef13/

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

#21494

From"Elizabeth D. Rather" <erather@forth.com>
Date2013-04-07 09:16 -1000
Message-ID<Os2dnbK0ZLCFW_zMnZ2dnUVZ_gGdnZ2d@supernews.com>
In reply to#21484
On 4/7/13 3:51 AM, Anton Ertl wrote:
> AKE <assadebrahim2000@gmail.com> writes:
>> On Sunday, April 7, 2013 12:33:00 AM UTC+1, Marcel Hendrix wrote:
>>>
>>>
>>> I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
>>>
>>> #                sieve  bubble  matmul   fib    ssa   mm-rtcg
>>> # gforth         0.285  0.376   0.223   0.334  0.269   0.322
>>> # gforth-fast    0.250  0.300   0.176   0.267  0.224   0.501
>>> # SF 3.4.2       0.119  0.146   0.042   0.048  0.056   0.541
>>> # Vfx 4.5        0.094  0.109   0.031   0.047  0.031   0.234
>>> # iForth 4.0     0.089  0.088   0.020   0.082  0.037   0.420
>>> # gcc manual     0.071  0.086   0.028   0.052
>>> # f2c            0.070  0.074   0.036   0.052
>>>
>>>
>>
>> Broadly speaking, it looks like these tests segment Forths/compilers into roughly three classes:
>>
>> Gforth        SwiftForth         VFX/iForth/Gcc/f2c
>>
>>
>> where moving from left to right gives a non-trivial speed-up (relative to the previous class).
>>
>> I don't know much about the differences between the various Forths -- what roughly would be the reason why VFX or iForth posts significantly better times than Gforth?
>>
>> Is it a difference in compiler technology?
>
> Yes.  Gforth is based on a threaded code interpreter, with various
> techniques that make it a good bit faster (if there is nothing
> blocking them; there are quite big variations between builds of Gforth
> because of this [*]; I usually see a better speedup from gforth-fast
> over gforth).  Swiftforth is a subroutine-threaded system with
> inlining and high-level peephole optimization (what Gforth calls
> static superinstructions).  VFX and iForth are more sophisticated
> ("analytic") compilers that allocate stack items to registers, and
> should not have the problem that Rose mentioned to the same degree.
>
>>   Or perhaps something about the test cases?
>
> It seems that these small benchmarks are more amenable to optimization
> than most application benchmarks.
>
> [*] E.g., from Gforth's Benchres file:
>
> sieve bubble matrix  fib
>   0.152 0.208  0.076 0.244 gforth-fast 0.7.0; Core 2 3GHz (Xeon 5160) 64 bits;
>                            gcc-4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

These benchmarks are useful for certain comparisons, but don't 
necessarily given an overall picture of the particular implementation as 
regards a particular application. For example, the overhead on OS calls 
varies tremendously from one implementation to another, as does other 
aspects such as multi-thread support (and overhead), user convenience, 
debugging aids, etc.

Still, I hope you can see that your original question about optimization 
(using stack vs. memory) doesn't have a simple answer!

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]

#21485

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-04-07 14:13 +0000
Message-ID<2013Apr7.161345@mips.complang.tuwien.ac.at>
In reply to#21473
mhx@iae.nl (Marcel Hendrix) writes:
>I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
[...]
>                 f2c  gforth gforth-fast SF3.4.2  Vfx 4.5 iForth 4.0  gcc
># sieve          1    4.1    3.6         1.7      1.34    1.27        1 
># bubble         1    5.1    4.1         1.98     1.5     1.19        1.16
># matmul         1?   6.2    4.9         1.17     0.86    0.56        0.78
># fib            1    6.4    5.13        0.92     0.9     1.58        1

Thanks.

>2) The Sieve algorithm for the manual C program is not the same as Forth uses.

Does not look that different to me; the Forth programs does have some
induction variable optimizations applied manually.  The C program also
contains an iteration counter that the Forth porgram doesn't, and that
might slow it down.  I find it remarkable that f2c and c-manual
produced the same results in old times and now, though.

>4) The results for fib are a parlor trick for most compilers

C compilers do cool things with that nowadays (I guess that's the kind
of real-world programs that Andrew referred to elsewhere:-).  I would
not expect Forth compilers to do that (it does not help on what counts
as real world in the Forth world); so what parlor trick do you mean?

- 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 2013: http://www.euroforth.org/ef13/

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

#21487

Frommhx@iae.nl (Marcel Hendrix)
Date2013-04-07 17:14 +0200
Message-ID<17891896998434@frunobulax.edu>
In reply to#21485
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: MISC - Stack Based vs. Register Based

> mhx@iae.nl (Marcel Hendrix) writes:
>>I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
[...]
>>                 f2c  gforth gforth-fast SF3.4.2  Vfx 4.5 iForth 4.0  gcc
>># sieve          1    4.1    3.6         1.7      1.34    1.27        1 
>># bubble         1    5.1    4.1         1.98     1.5     1.19        1.16
>># matmul         1?   6.2    4.9         1.17     0.86    0.56        0.78
>># fib            1    6.4    5.13        0.92     0.9     1.58        1

>Thanks.

>>2) The Sieve algorithm for the manual C program is not the same as Forth uses.

> Does not look that different to me; the Forth programs does have some
> induction variable optimizations applied manually.  The C program also
> contains an iteration counter that the Forth porgram doesn't, and that
> might slow it down.

OK, I looked again and the core is indeed the same, a nested for loop. 
However, both Vfx and iForth are about twice faster with the 'original' 
Forth Sieve. Of course, that could be caused by specific peephole 
optimizations.

>                      I find it remarkable that f2c and c-manual
> produced the same results in old times and now, though.

Yes, I also wondered about that. I compiled with MinGW64's version of gcc 
and did not change the options in the makefile (only -O3).

I had to tweak the makefile (to explicitly call bash for the time command, and
to change the ftp path to a local one). The -DUNIX macro didn't work on Windows,
-DMSC fixed it, but in the end I had to hack the timer calls in one of the C 
files. The makefile should also have CC=gcc.

Note that the f2c matmul seems to crash, or maybe bash crashed (core dumped,
but I still got output from the `time` command).

>>4) The results for fib are a parlor trick for most compilers

> C compilers do cool things with that nowadays (I guess that's the kind
> of real-world programs that Andrew referred to elsewhere:-).  I would
> not expect Forth compilers to do that (it does not help on what counts
> as real world in the Forth world); so what parlor trick do you mean?

FIB is about the only program that I know that benefits so much from 
having TOS in a register. Even SF is a lot faster than iForth here, while
it is far slower for all other programs I tested. Maybe it is fundamentally
better to have the TOS in a register. I thought that it would become a hindrance
when the compiler reached a certain level of sophistication, but at least
for iForth (and Vfx) that level is still a bit far off.

-marcel

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

#21489

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-04-07 15:31 +0000
Message-ID<2013Apr7.173141@mips.complang.tuwien.ac.at>
In reply to#21487
mhx@iae.nl (Marcel Hendrix) writes:
>Note that the f2c matmul seems to crash, or maybe bash crashed (core dumped,
>but I still got output from the `time` command).

Looks to me like a 32/64-bit portability issue; the sizes of the
arrays are hard-coded in bytes in the generated C code.  Try compiling
with -m32.

>>>4) The results for fib are a parlor trick for most compilers
>
>> C compilers do cool things with that nowadays (I guess that's the kind
>> of real-world programs that Andrew referred to elsewhere:-).  I would
>> not expect Forth compilers to do that (it does not help on what counts
>> as real world in the Forth world); so what parlor trick do you mean?
>
>FIB is about the only program that I know that benefits so much from 
>having TOS in a register. Even SF is a lot faster than iForth here, while
>it is far slower for all other programs I tested. Maybe it is fundamentally
>better to have the TOS in a register.

Yes, all the data I have indicates that it is a good idea.

1) http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz

Figure 21 shows the benefits (in terms of reduces loads+stores) of
keeping the TOS in a register between primitives (and why more doesn't
help).

Figure 24 shows that, if you optimize basic blocks and have 1 or 2
registers, keeping the TOS in a register at basic block boundaries is
optimal, while for more registers, keeping TOS and NOS in registers is
slightly better (for the performance model assumed there).

2) http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz

Here we see timing data from real machines instead of a performance
model, and the discussion says (in Section 4.4):

|The number of instructions executed is smallest for the canonical
|stack representation with one register (except for some of the smaller
|benchmarks).  Similarly, for the single-representation stack caches,
|the one with one register executes the least instructions.
|
|The PPC7400 timings behave quite similar to the instruction counts,
|although the timing reduction is somewhat higher than the instruction
|reduction; on the PPC7447A and especially the PPC970 the times for
|canonical representations with more than one registers rise much more
|slowly (and sometimes not at all).
|
|Nevertheless, even on those CPUs using the one-register representation
|as canonical representation or, for single-representation stack
|caches, as the representation is optimal for many benchmarks, and
|close to optimal on the others.

> I thought that it would become a hindrance
>when the compiler reached a certain level of sophistication, but at least
>for iForth (and Vfx) that level is still a bit far off.

Well, if your compiler works on larger units, it will do much of that
automatically within the units, but at unit boundaries (where you
return to the canonical stack state) it is still an advantage; I think
that, with larger units, keeping more stack items in registers at
boundaries might be beneficial, but have no data on that.

Working on Gforth I originally thought that keeping the TOS in a
register would increase the register pressure, but that turned out not
to be the case.  Most primitives load the TOS at some early point
anyway and store it later, and the point of highest register pressure
is between these points; keeping the TOS in a register across NEXT
does not increase register pressure.

- 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 2013: http://www.euroforth.org/ef13/

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

#21516

FromBernd Paysan <bernd.paysan@gmx.de>
Date2013-04-08 18:53 +0200
Message-ID<kjusn9$l79$1@online.de>
In reply to#21473
Marcel Hendrix wrote:

> rickman <gnuarm@gmail.com> writes Re: MISC - Stack Based vs. Register
> Based
> 
>> On 4/6/2013 10:16 AM, Anton Ertl wrote:
>>> rickman<gnuarm@gmail.com>  writes:
> [..]
>>> So what?  The part that AKE cited says that it had not become outdated
>>> when the page above was written (which was in 1996 or shortly after).
>>> If it held true for so long, it might still hold true today.  If you
>>> want to know, go out an measure it!  The page contains the measured
>>> code, so it's not that hard.  Current iForth and VFX might do better
>>> (or maybe not), but for everything else I expect that the factor of
>>> 2-3 still holds.
> [..]
> 
> I redid the tests just now (i7 920 @2.66 GHz, Window 7). Times in ms.
> 
> #                sieve  bubble  matmul   fib    ssa   mm-rtcg
> # gforth         0.285  0.376   0.223   0.334  0.269   0.322
> # gforth-fast    0.250  0.300   0.176   0.267  0.224   0.501

On my new core i7 @ 3.4 GHz, gforth-fast gets

            sieve  bubble matmu fib
gforth      0.253  0.343  0.166 0.456
gforth-fast 0.088  0.138  0.048 0.132

Didn't test the others, but gforth-fast is really much faster on Core i7 
than the memory-updating Gforth (Core i7 is write-port limited, which 
explains this factor 3).  64 bits.  Apples to apples, there's a good reason 
why iForth is 64 bits, and exactly the same reason applies to Gforth, too: 
more registers, more fun.

32 bits suck, due to the lack of registers, and apparently some of our hand-
tuned register assignments don't work on GCC 4.7, which needs investigation.  
That's even slower than your 2.66GHz CPU:

             sieve  bubble matmu fib
gforth       0.370  0.489  0.274 0.414
gforth-fast  0.318  0.429  0.196 0.313

% ./gforth-fast-x32 --diag -e bye
*** performance problems ***
    automatic register allocation: performance degradation possible

Well, that explains a lot...  If that's the case, don't bother to benchmark 
it.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#21486

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-04-07 14:22 +0000
Message-ID<2013Apr7.162229@mips.complang.tuwien.ac.at>
In reply to#21462
rickman <gnuarm@gmail.com> writes:
>Except that unless I am missing something this doesn't hold.  The 
>analysis completely ignores the results of FLK which appears to be a 
>Forth.  The reported speeds are 0.83 to 1.99 compared to f2c.opt and 
>compares similarly to the hand coded C an even is faster in the fib 
>benchmark where both references score a 1.00.
>
>Is there a reason why this Forth was tested, but not included in the 
>analysis?

Looking at the original text (section 4.5 of
<http://www.complang.tuwien.ac.at/papers/ertl96diss.ps.gz>), I see
that FLK did not occur there.  So apparently I started with that text,
and later updated it with newer data, but did not rewrite the analysis
when I added FLK to the data.

- 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 2013: http://www.euroforth.org/ef13/

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

#21656

From"WJ" <w_a_x_man@yahoo.com>
Date2013-04-14 00:19 +0000
Message-ID<kkcsn2$1di$1@dont-email.me>
In reply to#21227
rickman wrote:

> I have been working with stack based MISC designs in FPGAs for
> some years.  All along I have been comparing my work to the work
> of others. These others were the conventional RISC type
> processors supplied by the FPGA vendors as well as the many
> processor designs done by individuals or groups as open source.

I broke your lines for you.

When you post to usenet, YOU MUST LIMIT THE LENGTH OF YOUR LINES!

CPU-design is completely off-topic in a programming newsgroup.
This is absolutely inexcusable.

Since you are retarded, completely ignorant, or both, I'll spell
it out for you.

This is a programming newsgroup.  It isn't a forum.  You must
make sure that the lines in your post are no more than 80-characters
long.

This is a programming newsgroup.  Don't make any posts about building
a birdhouse or designing a CPU or sweeping the floor or playing
tiddly-winks.

Understand?

You are even more disgusting and obnoxious than Gavino.  At least
he talks about programming, not about silicon.

Don't pollute this programming newsgroup with your arrogant
boasting about your vast expertise in designing hardware.

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

#21659

Fromrickman <gnuarm@gmail.com>
Date2013-04-14 09:44 -0400
Message-ID<kkebnn$ene$1@dont-email.me>
In reply to#21656
On 4/13/2013 8:19 PM, WJ wrote:
>
> You are even more disgusting and obnoxious than Gavino.  At least
> he talks about programming, not about silicon.
>
> Don't pollute this programming newsgroup with your arrogant
> boasting about your vast expertise in designing hardware.

Another country heard from!

-- 

Rick

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

#21667

FromBrad Eckert <hwfwguy@gmail.com>
Date2013-04-15 09:39 -0700
Message-ID<5411c319-6a00-44ee-8651-8d3be2120a96@googlegroups.com>
In reply to#21656
On Saturday, April 13, 2013 5:19:47 PM UTC-7, WJ wrote:
> CPU-design is completely off-topic in a programming newsgroup.
You know absolutely nothing about Forth.

Sorry, I fed a troll. http://digourideas.com/blog/dont-feed-the-trolls/

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

#21668

FromBernd Paysan <bernd.paysan@gmx.de>
Date2013-04-15 19:28 +0200
Message-ID<kkhdc8$qp9$1@online.de>
In reply to#21667
Brad Eckert wrote:

> On Saturday, April 13, 2013 5:19:47 PM UTC-7, WJ wrote:
>> CPU-design is completely off-topic in a programming newsgroup.
> You know absolutely nothing about Forth.
> 
> Sorry, I fed a troll. http://digourideas.com/blog/dont-feed-the-trolls/

The propper thing to feed trolls with are fishs:

<°)))))><

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [standalone]

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

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

csiph-web