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

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

FORTH Trouble--Please Show Me

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

Contents

  FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-17 16:56 -0500
    Re: FORTH Trouble--Please Show Me all2001@spambog.com (Wolfgang Allinger) - 2012-10-17 19:11 -0300
      Re: FORTH Trouble--Please Show Me Mark Wills <forthfreak@gmail.com> - 2012-10-18 01:15 -0700
        Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-18 05:25 -0500
    Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 00:14 +0200
      Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-17 18:45 -0400
        Re: FORTH Trouble--Please Show Me Anonymous <nobody@remailer.paranoici.org> - 2012-10-18 08:49 +0000
          Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-18 15:58 -0400
            Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-18 21:53 +0000
            Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:39 -0700
              Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-19 23:22 -0700
              Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-21 13:40 -0500
            Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-19 21:00 -1000
              Re: FORTH Trouble--Please Show Me "A. K." <akk@nospam.org> - 2012-10-20 09:18 +0200
                Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 08:40 -1000
            Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 12:22 +0200
              Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-21 08:46 -0400
        Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 21:08 +0200
          Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:29 -0700
    Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-17 20:24 -0700
      Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:46 -0400
        Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:46 -0700
          Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-20 21:03 -0400
            Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 15:40 -1000
            Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-20 18:52 -0700
              Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 16:27 -1000
            Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-20 20:56 -0700
              Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:40 -0400
                Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 12:51 -0700
                  Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 23:50 +0200
                    Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 17:11 -0700
                      Re: FORTH Trouble--Please Show Me mhx@iae.nl - 2012-10-22 00:19 -0700
                        Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 00:41 -0700
                          Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 09:31 -0500
                            Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 08:13 -0700
                          Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 21:40 +0200
                            Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 13:14 -0700
                              Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 10:41 -1000
                                Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 23:21 +0200
                                Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 14:27 -0700
                                  Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 14:16 -1000
                                    Re: FORTH Trouble--Please Show Me Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-23 21:42 +0100
                  Re: FORTH Trouble--Please Show Me vandys@vsta.org - 2012-10-22 00:24 +0000
                  Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:12 -0400
                    Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 01:40 -0700
                      Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:39 -0700
                    Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:30 -0700
                      Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 22:27 -0400
                    Re: FORTH Trouble--Please Show Me David Thompson <dave.thompson2@verizon.net> - 2012-11-04 22:18 -0500
                      Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:35 +0100
                  Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 12:22 -0700
                    Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 12:51 -0700
                      Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 23:40 -0700
                        Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:50 +0000
                          Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-24 09:13 -0700
                            Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 12:31 +0000
                              Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-26 09:58 -0700
                Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-21 16:24 -0700
                  Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 02:51 +0200
                    Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 19:55 -0500
                      Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 03:02 +0200
                    Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:50 -0400
                    Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 01:03 -0700
                      Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:12 +0000
                    Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:08 +0000
                      Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 18:06 +0200
                        Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 22:14 +0200
                          Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-23 00:50 +0000
                          Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-23 03:43 +0200
                            Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:14 -0500
                      Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 19:54 -0700
                        Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-22 22:59 -0700
                          Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 09:23 -0700
                        Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:33 +0000
                          Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:05 -0700
                            Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-24 14:56 -0400
                      Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 11:50 +0000
                        Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 14:39 +0000
                          Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 15:59 +0000
                            Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-24 14:33 +0000
                              Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 14:19 +0000
                  Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:56 -0400
                    Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-21 22:12 -1000
                    Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:51 -0700
            Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 05:29 -0500
              Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:35 -0400
              Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-21 15:44 +0200
                Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 18:43 -0500
                Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:20 -0400

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

#16553

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Hugh Aguilar wrote:
>>> Look at how horribly slow Gforth is. That is because it was written
>>> in C rather than assembly-language. Your C-based Forth will also be
>>> horribly slow for the same reason.
>> 
>> I don't know what you mean with "horribly slow".
> 
> Hold on!  I'm sure you just told me "Don't feed the trolls."

Ok, yes, I shouldn't feed Hugh either ;-).  But doing these benchmarks 
was fun, and from time to time I want to know how horribly slow Gforth 
really is.

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

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

#16560

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:4915176.bI2hdeRrkA@sunwukong.fritz.box...
> Hugh Aguilar wrote:
> > Look at how horribly slow Gforth is. That is because it was written in
> > C rather than assembly-language. Your C-based Forth will also be
> > horribly slow for the same reason.
>
> I don't know what you mean with "horribly slow".

My Forth is interpreted as in ITC.  So, yes, it'll be slow as compared to a
compiled Forth.  But, I think Hugh was referring to the usually switch()
based Forth in C, which aren't very fast either.  GForth moved "beyond" that
design years ago.

> E.g. take a very
> classical Forth benchmark, the Byte sieve one.  On my machine, gforth-
> fast does this benchmark in 0.325s (1000 times primes, x64
> architecture).  VFXForth, which has a way more sophisticated compiler,
> does it in 0.215s.  bigForth, which is a less sophisticated native code
> compiler for x86, does it in 0.277s - both use the x86 architecture,
> i.e. the register starved 32 bit model.
>
> We did put quite some effort into Gforth to make it fast while still
> using the C compiler - the latter to make it easy enough to port.  The
> effort to write a compiler like the one in VFX is tremendous, and not
> worth to repeat for more than a very few popular platforms.  I.e. the
> result wouldn't be a very portable Forth.

Correction:
"... did put quite some effort into" _Gforth-fast_ "to make ..."

My ITC interpreter easily outperforms GForth ITC, except for loops - where
it is currently very, very slow.  The loop constructs are now coded in
Forth.  It does nothing special.  It's very simple.  It has almost no
optimizations.  In fact, I've been making it progessively  *slower*  in
order to eliminate C code.  It'll be reworked later, after the
transformation is complete.  The loop constructs might be converted to
low-level words or primitives at that time.


Rod Pemberton

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

#16562

On Oct 21, 5:51 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > Look at how horribly slow Gforth is. That is because it was written in
> > C rather than assembly-language. Your C-based Forth will also be
> > horribly slow for the same reason.
>
> I don't know what you mean with "horribly slow".

I didn't benchmark it, I just ran my own programs and timed them. A
lot of my programs do recursive-descent searches and they can take
several minutes to run. The slide-rule program doesn't search, but it
still takes several minutes to run, just because it is doing a lot.
Roughly speaking, I found SwiftForth to be 2 times faster than Gforth.
With some assembly-language help for SwiftForth (mostly in LIST.4TH
for programs like SLIDE-RULE.4TH that use lists a lot) it was 3 times
faster.

This was with SwiftForth 2.0, as I don't have 3.0 (and I'm not going
to spend another $300 to get it). SwiftForth does almost no
optimization at all. It will inline short machine-code functions to
save the CALL/RET, but it isn't really optimizing. It is just pasting
the code snippets together. It is still pushing values onto the stack
and immediately taking them off again. It is pretty lame.

I have always suspected that the reason why Gforth was written in C,
was to ensure that it wouldn't run faster than SwiftForth. I think
Elizabeth Rather insisted that Gforth be slower than SwiftForth in
exchange for allowing you guys to participate in creating ANS-Forth
and Forth-200x. That whole standards committee is a charade --- Forth
Inc. has veto power over everybody --- none of you guys can buck them.

> E.g. take a very
> classical Forth benchmark, the Byte sieve one.  On my machine, gforth-
> fast does this benchmark in 0.325s (1000 times primes, x64
> architecture).  VFXForth, which has a way more sophisticated compiler,
> does it in 0.215s.  bigForth, which is a less sophisticated native code
> compiler for x86, does it in 0.277s - both use the x86 architecture,
> i.e. the register starved 32 bit model.
>
> We did put quite some effort into Gforth to make it fast while still
> using the C compiler - the latter to make it easy enough to port.  The
> effort to write a compiler like the one in VFX is tremendous, and not
> worth to repeat for more than a very few popular platforms.  I.e. the
> result wouldn't be a very portable Forth.
>
> I'm not actually looking forward to your "straight Forth", because I
> don't think it ever will see light.  But if it does, I hope it is at
> least a factor 10 faster than Gforth, because "horribly slow" is usually
> something you can't only measure, but you can really perceive as big
> difference.  A factor 10 is perceivable.  If you achieve this, I will
> call you Superman.

Are you aware that Straight Forth is a cross-compiler for micro-
controllers? I will first be targeting the PIC24. From there maybe
onto the MSP430. Eventually some 32-bit targets such as the PIC32, the
ARM or the AVR32 (but not the x86). I'm mostly interested in 16-bit
micro-controllers though. Does Gforth even run on 16-bit micro-
controllers?

Straight Forth is actually two Forth systems. We have HostForth which
runs on the x86. The only program that will ever be written in
HostForth is TargForth, which is the cross-compiler. TargForth
generates the micro-controller program.

If HostForth is slow, the only effect will be that TargForth will
compile programs slowly. Even if HostForth is very slow however,
TargForth should still compile large programs in under a second. There
is no real point in my spending a lot of time on HostForth's speed ---
it can be a crude threaded system and still be plenty fast for what it
is being used for. HostForth will be written in assembly language (HLA
right now, although I may change later in order to get 64-bit x86),
and I expect it to be about 2 times faster than SwiftForth, but if it
isn't I won't care.

Also, btw, Straight Forth will not be ANS-Forth compliant. This makes
it difficult to compare speeds with Gforth. Its main feature will be
closures. People are going to use iterators a lot --- they aren't
going to manually write loops with BEGIN all that much. I won't
support DO loops at all. Lists will be used a lot. The programs will
look different --- there is a lot of influence from Scheme here.

What kind of benchmarks are used to test micro-controller systems?
Most micro-controller programs spend somewhere around 1/2 of their
time in ISRs (Straight Forth will support ISRs but will take away some
features such as floating-point). What kind of benchmark would be
meaningful in the context of micro-controllers? Straight Forth is
intended to be used for hobbyist robotics. Maybe we should just build
robots and have them fight! :-)

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

#16572

On Mon, 22 Oct 2012 01:03:43 -0700 (PDT), Hugh Aguilar
<hughaguilar96@yahoo.com> wrote:

>That whole standards committee is a charade --- Forth
>Inc. has veto power over everybody --- none of you guys can buck them.

Total rubbish. Both MPE and Forth Inc have been outvoted in the past.

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]

#16571

On Mon, 22 Oct 2012 02:51:02 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>I don't know what you mean with "horribly slow".  E.g. take a very 
>classical Forth benchmark, the Byte sieve one.  On my machine, gforth-
>fast does this benchmark in 0.325s (1000 times primes, x64 
>architecture).  VFXForth, which has a way more sophisticated compiler, 
>does it in 0.215s.  bigForth, which is a less sophisticated native code 
>compiler for x86, does it in 0.277s - both use the x86 architecture, 
>i.e. the register starved 32 bit model.

As you yourself have commented several times, be careful with
benchmarks. Over the application benchmarks on the MPE website,
the gforth-fast time is 3.90 times the VFX time on an i7.

>We did put quite some effort into Gforth to make it fast while still 
>using the C compiler - the latter to make it easy enough to port.  The 
>effort to write a compiler like the one in VFX is tremendous, and not 
>worth to repeat for more than a very few popular platforms.

x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430

The effort put in to designing and implementing the first two VFX
compilers was huge. Implementing a code generator for a new CPU is
a matter of a few weeks, including writing the assembler and
disassembler. However, I will concede that, over the years, we
have put more effort into the x86 code generator than we should
have done. After initially writing a reasonable quality code 
generator, further improvements are usually a matter of incremental
development.

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]

#16580

Stephen Pelc wrote:
> As you yourself have commented several times, be careful with
> benchmarks. Over the application benchmarks on the MPE website,
> the gforth-fast time is 3.90 times the VFX time on an i7.

Everybody uses the benchmarks where their compiler shines most.  The 
sieve you use takes 458ms here on Gforth, ours takes 321ms.  It's doing 
the same thing, we just use +LOOP for the inner loop, and not this 
horribly bad coding style from the Byte article.  Maybe this gives an 
advantage for Gforth and a disadvantage for VFX?  It's not deliberately.  
Using +LOOP instead of the WHILE loop is a code cleanup for style 
purposes that already had been done in VolksForth, from which I 
inherited that benchmark.

However, as several benchmarks are almost identical (you also do fib):  
Why on earth is your Core i7 only marginally faster than my netbook AMD 
E-350, at less than half the frequency and a much smaller die?  I would 
expect a Core i7 at 3.4GHz to run the current Gforth sieve benchmark in 
~100ms.

There's something fishy going on.  I don't know, maybe the Windows 
version of Gforth 0.7.0 still suffers from GCC problems or whatever.

Another fishy thing (which don't go into the factor 3.9, but where 
Gforth on your machine is really horribly slow): You test 40k times 
KEY?, and Gforth comes out at 765ms on a really fancy Core i7 at 3.4GHz.  
On my machine (Linux, E-350, 1.6GHz), this takes 48ms.  Cygwin problem?  
Maybe.  Some simple innocent and fast code on Linux might turn out as 
nightmarish slow on Cygwin.

>>We did put quite some effort into Gforth to make it fast while still
>>using the C compiler - the latter to make it easy enough to port.  The
>>effort to write a compiler like the one in VFX is tremendous, and not
>>worth to repeat for more than a very few popular platforms.
> 
> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
> 
> The effort put in to designing and implementing the first two VFX
> compilers was huge. Implementing a code generator for a new CPU is
> a matter of a few weeks, including writing the assembler and
> disassembler. However, I will concede that, over the years, we
> have put more effort into the x86 code generator than we should
> have done. After initially writing a reasonable quality code
> generator, further improvements are usually a matter of incremental
> development.

There's another reason for not using the C compiler: You don't have to 
work around the bugs each new version brings you.

And yes: Be careful with benchmarks.  Different people will get 
different results.  All of them are invalid, because only liars do 
benchmarks.

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

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

#16592

Bernd Paysan <bernd.paysan@gmx.de> writes Re: FORTH Trouble--Please Show Me

> Stephen Pelc wrote:
>> As you yourself have commented several times, be careful with
>> benchmarks. Over the application benchmarks on the MPE website,
>> the gforth-fast time is 3.90 times the VFX time on an i7.

> Everybody uses the benchmarks where their compiler shines most.  The 
> sieve you use takes 458ms here on Gforth, ours takes 321ms.  It's doing 
> the same thing, we just use +LOOP for the inner loop, and not this 
> horribly bad coding style from the Byte article.  Maybe this gives an 
> advantage for Gforth and a disadvantage for VFX?  It's not deliberately.  
> Using +LOOP instead of the WHILE loop is a code cleanup for style 
> purposes that already had been done in VolksForth, from which I 
> inherited that benchmark.

What hardware are you using? A steam-powered CPU?

> However, as several benchmarks are almost identical (you also do fib):  
> Why on earth is your Core i7 only marginally faster than my netbook AMD 
> E-350, at less than half the frequency and a much smaller die?  I would 
> expect a Core i7 at 3.4GHz to run the current Gforth sieve benchmark in 
> ~100ms.

On my hardware ( i7 2.66 GHz ) gForth 0.7 runs it in 171 ms, while 
iForth64 takes 79 ms and VFX 32bit 93 ms.

> There's something fishy going on.  I don't know, maybe the Windows 
> version of Gforth 0.7.0 still suffers from GCC problems or whatever.
[..]

Then fix it :-)

-marcel

-- ---------------------------------------------------------------------

\ i7 system, 2.66 GHz, Windows 7. 

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
include siev.fs  ok

main main main
171000 us elapsed
172000 us elapsed
171000 us elapsed ok


-- ----------------------------
marker -sieve

CREATE FLAGS 8190 ALLOT
variable eflag

: PRIMES  ( -- n )  
  FLAGS 8190 1 FILL  
  0 3  EFLAG @ FLAGS
    DO 
       I C@
         IF  DUP I + DUP EFLAG @ <
                IF  EFLAG @ SWAP
                    DO  0 I C! DUP  +LOOP
              ELSE  DROP  
	      THEN  
	     SWAP 1+ SWAP
       THEN  2+
  LOOP DROP ;

: BENCHMARK  0 1000 0 DO  PRIMES NIP  LOOP ;

: main 
  TIMER-RESET
	flags 8190 + eflag !
	benchmark ( . ) drop
  CR .ELAPSED ;

-- -------------------------

\ i7 system, 2.66 GHz, Windows 7, iForth 64bit. 

FORTH> main main main
0.087 seconds elapsed.
0.081 seconds elapsed.
0.079 seconds elapsed. ok

-- --------------------------------------------

VFX Forth for Windows IA32
 © MicroProcessor Engineering Ltd, 1998-2012 

 Version: 4.50 [build 3327]
 Build date: 17 April 2012

 Free dictionary = 7561806 bytes [7384kb]


( exact same code source as for iForth )

\ i7 system, 2.66 GHz, Windows 7

main 
93 ms elapsed ok
main 
94 ms elapsed ok
main 
94 ms elapsed ok

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

#16603

In article <19891313938435@frunobulax.edu>, Marcel Hendrix <mhx@iae.nl> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> writes Re: FORTH Trouble--Please Show Me
>
>-- ----------------------------
>marker -sieve
>
>CREATE FLAGS 8190 ALLOT
>variable eflag
>
>: PRIMES  ( -- n )
>  FLAGS 8190 1 FILL
>  0 3  EFLAG @ FLAGS
>    DO
>       I C@
>         IF  DUP I + DUP EFLAG @ <
>                IF  EFLAG @ SWAP
>                    DO  0 I C! DUP  +LOOP
>              ELSE  DROP
>             THEN
>            SWAP 1+ SWAP
>       THEN  2+
>  LOOP DROP ;
>

That benchmark is severely rigged compared to the honest Byte benchmark:
lina 1.430 mS versus .861 mS

Groetjes Albert

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

#16604

Marcel Hendrix wrote:
> What hardware are you using? A steam-powered CPU?

An AMD E-350 Netbook CPU, as I told below.  Running at 1.6GHz, it 
doesn't seem to be much less efficient than the Core i7, which would run 
that in 284ms instead of 321ms at the same frequency.  Given that Core 
i7 usually runs circles around anything AMD makes today, this isn't 
really that much faster.

> On my hardware ( i7 2.66 GHz ) gForth 0.7 runs it in 171 ms, while
> iForth64 takes 79 ms and VFX 32bit 93 ms.

Sounds reasonable, roughly factor 2 vs. VFX.

>> There's something fishy going on.  I don't know, maybe the Windows
>> version of Gforth 0.7.0 still suffers from GCC problems or whatever.
> [..]
> 
> Then fix it :-)

GCC?  Nope.  It's unmaintainable ;-).

If you think about fixing the distribution:  I did create a setup.exe 
from the CVS head a few weeks ago, as a user discovered other problems, 
and had a few wishes for the installation script (like adding the Gforth 
location to PATH): it's on

http://bernd-paysan.de/gforth-0.7.9-20121007.exe

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

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

#16613

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Marcel Hendrix wrote:
> 
>>> There's something fishy going on.  I don't know, maybe the Windows
>>> version of Gforth 0.7.0 still suffers from GCC problems or whatever.
>> [..]
>> 
>> Then fix it :-)
> 
> GCC?  Nope.  It's unmaintainable ;-).

:-P

Andrew.

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

#16609

On Oct 22, 3:10 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Mon, 22 Oct 2012 02:51:02 +0200, Bernd Paysan <bernd.pay...@gmx.de>
> wrote:
>
> >We did put quite some effort into Gforth to make it fast while still
> >using the C compiler - the latter to make it easy enough to port.  The
> >effort to write a compiler like the one in VFX is tremendous, and not
> >worth to repeat for more than a very few popular platforms.
>
> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430

Do you simulate the target processor at compile-time even for the
MSP430???

I can see your technique of simulating the target processor at compile-
time in your "cross-compiler" in regard to the big 32-bit processors
such as everything else in your list above, but it seems like a very
bad idea with a little 16-bit processor.

All in all, simulating the target processor at compile-time is a very
bad idea in any case --- it blows me away that you do that.

> The effort put in to designing and implementing the first two VFX
> compilers was huge. Implementing a code generator for a new CPU is
> a matter of a few weeks, including writing the assembler and
> disassembler. However, I will concede that, over the years, we
> have put more effort into the x86 code generator than we should
> have done. After initially writing a reasonable quality code
> generator, further improvements are usually a matter of incremental
> development.

Is your x86 system 32-bit or 64-bit?

I'm somewhat interested in buying VFX. Do you allow programs written
in VFX to contain the dictionary and to provide the user with a
command-line so that Forth can be used as an embedded scripting
language by the user? I'm interested in writing a CAM program to
generate gcode for CNC machines. Right now I'm learning Gambit Scheme
primarily so that it could be used for this. Lua is another
possibility. I'd rather use Forth, but I'm not aware of any Forth
system that is capable of this --- at least, not without me writing my
own mini-Forth on top of the underlying Forth system to be the
embedded scripting language.

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

#16611

On Oct 23, 3:54 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> On Oct 22, 3:10 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
>
> > On Mon, 22 Oct 2012 02:51:02 +0200, Bernd Paysan <bernd.pay...@gmx.de>
> > wrote:
>
> > >We did put quite some effort into Gforth to make it fast while still
> > >using the C compiler - the latter to make it easy enough to port.  The
> > >effort to write a compiler like the one in VFX is tremendous, and not
> > >worth to repeat for more than a very few popular platforms.
>
> > x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
> Do you simulate the target processor at compile-time even for the
> MSP430???
>
> I can see your technique of simulating the target processor at compile-
> time in your "cross-compiler" in regard to the big 32-bit processors
> such as everything else in your list above, but it seems like a very
> bad idea with a little 16-bit processor.
>
> All in all, simulating the target processor at compile-time is a very
> bad idea in any case --- it blows me away that you do that.
>
> > The effort put in to designing and implementing the first two VFX
> > compilers was huge. Implementing a code generator for a new CPU is
> > a matter of a few weeks, including writing the assembler and
> > disassembler. However, I will concede that, over the years, we
> > have put more effort into the x86 code generator than we should
> > have done. After initially writing a reasonable quality code
> > generator, further improvements are usually a matter of incremental
> > development.
>
> Is your x86 system 32-bit or 64-bit?
>
> I'm somewhat interested in buying VFX. Do you allow programs written
> in VFX to contain the dictionary and to provide the user with a
> command-line so that Forth can be used as an embedded scripting
> language by the user? I'm interested in writing a CAM program to
> generate gcode for CNC machines. Right now I'm learning Gambit Scheme
> primarily so that it could be used for this. Lua is another
> possibility. I'd rather use Forth, but I'm not aware of any Forth
> system that is capable of this --- at least, not without me writing my
> own mini-Forth on top of the underlying Forth system to be the
> embedded scripting language.

I'd be very surprised if VFX could not do that :-) Even my little 16-
bit hobby system can do that. In my case, a simple call to INTERPRET
gives you a command line and you just have at it and go write Forth.

VFX will have EVALUATE and possibly even more sophisticated words.

The thing about VFX that is very attractive (to me) is it's GUI
library which uses GTK+ for true cross-platform GUI functionality. You
can write a GUI that will work on Winblows, Linux, and Mac with *no
code changes whatsoever*. That's a really nice feature.

There's a page that goes into some detail here:

http://www.mpeforth.com/vfxwin.htm#guigen

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

#16653

On Oct 22, 10:59 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Oct 23, 3:54 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> > I'm somewhat interested in buying VFX. Do you allow programs written
> > in VFX to contain the dictionary and to provide the user with a
> > command-line so that Forth can be used as an embedded scripting
> > language by the user? I'm interested in writing a CAM program to
> > generate gcode for CNC machines. Right now I'm learning Gambit Scheme
> > primarily so that it could be used for this. Lua is another
> > possibility. I'd rather use Forth, but I'm not aware of any Forth
> > system that is capable of this --- at least, not without me writing my
> > own mini-Forth on top of the underlying Forth system to be the
> > embedded scripting language.
>
> I'd be very surprised if VFX could not do that :-) Even my little 16-
> bit hobby system can do that. In my case, a simple call to INTERPRET
> gives you a command line and you just have at it and go write Forth.
>
> VFX will have EVALUATE and possibly even more sophisticated words.

It is not a matter of a Forth not being able to do it in the technical
sense. The problem is that most Forth systems' license requires that
any software the customer (that would be me) releases can not include
the dictionary or the ability to compile Forth words. Most Forth
systems purposely destroy this part of the system when you create a
"turnkey" executable for distribution. They do this so the customer
doesn't just resell their Forth compiler as his own, with a few added
libraries that he wrote. SwiftForth is crippled like this, for
example.

I remember when I was 18 I wrote a program in SuperForth for the
Commodore-64. This was turtle graphics in 4 dimensions (W, X, Y and
Z). It displayed the 3D aspect of the 4D object, with the lines
receding to a vanishing point. The perspective could be rotated around
any of the 4 axis. Pretty cool! I've never seen anything like that
from anybody else. I couldn't sell it though, because it provided the
Forth command-line to the user similar to Logo so the user could write
functions. I wrote hypercube and some others myself as examples, but
the users were expected to write these kind of functions themselves.
It is no good without a command-line.

Now I'm learning Gambit Scheme. I'm rewriting that old turtle-graphics
program in Scheme as a learning exercise (I'm taking the advice that I
give to Gavino for myself, which is to write a program to learn, even
if the program is just a toy). This time I will be able to release the
program to the public because Gambit's license allows the REPL (that
is Scheme's term for the command-line) to be exposed to the users. I
won't be able to sell it though --- the days of selling software for
money are long past --- I missed my opportunity in the 1980s and early
1990s when people still bought shrink-wrapped software packages.

> The thing about VFX that is very attractive (to me) is it's GUI
> library which uses GTK+ for true cross-platform GUI functionality. You
> can write a GUI that will work on Winblows, Linux, and Mac with *no
> code changes whatsoever*. That's a really nice feature.

Considering that I know how to program in ANS-Forth, it would be
really great if I had an ANS-Forth system that was actually capable of
producing programs. I paid almost $500 for SwiftForth in the late
1990s, shortly after leaving Testra. That was a huge disappointment.
You really can't produce programs that have a GUI, and everybody in
the world demands GUI. It is really depressing. I've had situations
where people have wanted to hire me to write a program, but all of my
Forth experience is good for nothing as I can't write a Forth program
with a GUI, so I had to offer to use some other language that I'm not
very knowledgeable in and/or don't particularly like. It is
ridiculous! What is the point of being a Forth programmer if you can't
write Forth programs? The money I spent on SwiftForth was a huge
waste. Not only is there the GUI issue, but SwiftForth also just has
bugs. For example, any use of (LOCAL) will crash the system (although
LOCALS| does work). SwiftForth is also horribly slow compared to C/C++
and pretty much anything.

My experience with SwiftForth was so bad that I just gave up on Forth
for over a decade. My work experience with Testra wasn't helping me
get any jobs (there aren't any jobs for Forth), and Forth Inc. was a
dead-end because their SwiftForth was worthless, so I saw Forth itself
as being a dead-end. Recently (2009) I started visiting
comp.lang.forth, but I found the majority of comp.lang.forth members
to be a bunch of losers who just attack anybody who writes software
and who never write any software themselves. I tried Win32Forth, which
was supposed to provide GUI, but it was a bug-ridden mess. Their GUI-
generating stuff didn't work at all and would just crash. It was
worthless. Also, Alex McDonald, who is the representative of
Win32Forth, is a jerk --- so I dumped Win32Forth too.

I'm really close to just abandoning Forth altogether. That is just
depressing, considering that Forth programming is the only thing that
I ever became really skilled at (I know C and a variety of assembly
languages, but I'm no better than average, and maybe not even average
as I don't practice much). This is why I'm learning Scheme now. My
experience so far with Scheme is that the people involved are
intelligent and know a lot about computer science, they write software
that works, and they don't attack other people's software. There is no
Scheme equivalent of Elizabeth Rather who claims to be the greatest
expert in the world, who never writes any software, who doesn't know
what closures are or any other basic programming concepts, and who
works as a salesperson selling overpriced garbage. And no flaming
faggots either. The Scheme crowd has way more class than the Forth
crowd.

I may give VFX a shot though. It is the only Forth system that I
haven't tried yet.

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

#16615

On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
<hughaguilar96@yahoo.com> wrote:

>> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
>Do you simulate the target processor at compile-time even for the
>MSP430???

Yes, but not in the sense of simulating the CPU. We just provide 
Forth words, e.g. @ and CMOVE that operate on the target memory
space. We're simulating the target Forth, not the CPU.

>All in all, simulating the target processor at compile-time is a very
>bad idea in any case --- it blows me away that you do that.

We like to surprise people.

>Is your x86 system 32-bit or 64-bit?

32 bit.

>I'm somewhat interested in buying VFX. Do you allow programs written
>in VFX to contain the dictionary and to provide the user with a
>command-line so that Forth can be used as an embedded scripting
>language by the user?

Yes. Download the *free beer* eval system and read the licence.

Basically you can do what you want with a bit of protection of
our copyright. Since Forth is an interactive language it would
be foolish to remove that facility at run time.

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]

#16656

On Oct 23, 3:35 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
>
> <hughaguila...@yahoo.com> wrote:
> >> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
> >Do you simulate the target processor at compile-time even for the
> >MSP430???
>
> Yes, but not in the sense of simulating the CPU. We just provide
> Forth words, e.g. @ and CMOVE that operate on the target memory
> space. We're simulating the target Forth, not the CPU.

Well, that makes a lot more sense! That is how my MFX worked. I had
TARG words and HOST words, and the HOST words ran on the host computer
but accessed the target memory image (there was @ and CMOVE etc.).

This is not what you said previously in this thread though:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3

You said this:
On Dec 8 2009, 3:18 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> There are three types of compilation involved
> 1) Host compilation
> 2) Clone compilation (target CPU same as host and memory matches)
> 3) Cross compilation (target CPU is not host CPU)
>
> In the third case you have to simulate *everything* when dealing
> with both the definition and execution of defining words. It's not
> easy. You also have to extend the normal Forth compiler by at least
> two time frames. Forth cross compilers are much more complicated
> and much more subtle than they appear to be.

You said that in 2009, and I haven't taken you seriously since that
time --- because I saw you as yet another self-proclaimed cross-
compiler "expert" who doesn't know anything about cross-compiling ---
it is not all that complicated and subtle (I figured it out, so how
hard could it be?).

It is possible that I misunderestimated you though.

> >I'm somewhat interested in buying VFX. Do you allow programs written
> >in VFX to contain the dictionary and to provide the user with a
> >command-line so that Forth can be used as an embedded scripting
> >language by the user?
>
> Yes. Download the *free beer* eval system and read the licence.
>
> Basically you can do what you want with a bit of protection of
> our copyright. Since Forth is an interactive language it would
> be foolish to remove that facility at run time.

I think that it is foolish too. Chuck Moore, who should know, has said
that Forth's primary purposes is to be a domain-specific-language. I
have *never* seen a commercial Forth system that allowed this though.
SwiftForth doesn't.

This makes me a *lot* more interested in VFX --- this would be a
*huge* benefit --- I never even considered this as a possibility
before.

I've worked as a CNC programmer and machinist, and I've written
software (in Forth) to generate gcode for CNC machines. I want to
write a CAM program to do this. The user has to be able to write
programs within the system though. CAM software that depends upon the
user clicking menu options is pretty much worthless. The user has to
be able to write programs of his own to generate the gcode
representing the part that he is fabricating. If VFX allows this, and
VFX is reasonably fast (CAM programs usually involve a *lot* of
floating-point arithmetic), then VFX might be a good choice. Most
machinists aren't programmers --- they need a pretty simple language
to work with --- Forth is pretty simple though, as it has no syntax
rules at all, and it manages this without all the parenthesis of
Scheme. :-)

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

#16662

On 10/24/12 1:05 PM, Hugh Aguilar wrote:
> On Oct 23, 3:35 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
>> On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
>>
>> <hughaguila...@yahoo.com> wrote:
>>>> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>>
>>> Do you simulate the target processor at compile-time even for the
>>> MSP430???


>>> I'm somewhat interested in buying VFX. Do you allow programs written
>>> in VFX to contain the dictionary and to provide the user with a
>>> command-line so that Forth can be used as an embedded scripting
>>> language by the user?
>>
>> Yes. Download the *free beer* eval system and read the licence.
>>
>> Basically you can do what you want with a bit of protection of
>> our copyright. Since Forth is an interactive language it would
>> be foolish to remove that facility at run time.
>
> I think that it is foolish too. Chuck Moore, who should know, has said
> that Forth's primary purposes is to be a domain-specific-language. I
> have *never* seen a commercial Forth system that allowed this though.


> This makes me a *lot* more interested in VFX --- this would be a
> *huge* benefit --- I never even considered this as a possibility
> before.

I have been using VFX recently since I switched to an Intel Macintosh. 
Also have been using VFX on a Windows machine.  I can tell you that it 
is an *excellent* Forth overall, perhaps one of the best.  No experience 
with cross compiling but if that capability is as high quality as the 
rest, no reason to think it isn't, then you won't be disappointed.  I 
recommend you try it.

-Doug

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

#16618

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>As you yourself have commented several times, be careful with
>benchmarks. Over the application benchmarks on the MPE website,
>the gforth-fast time is 3.90 times the VFX time on an i7.

Searching for "application benchmarks on the MPE website", I
eventually found <http://www.mpeforth.com/vfxwin.htm#bnchmrk>, and
while that says "A set of application benchmarks follow.", I don't see
any application benchmark there.  There are a bunch of
micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
also the random number benchmark).  Not a single application benchmark
there.

I put quite a bit of effort into collecting several applications by a
number of authors and realeasing them as a benchmark suite, with each
benchmark running on several Forth systems:
<http://www.complang.tuwien.ac.at/forth/appbench.zip>

- 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 2012: http://www.euroforth.org/ef12/

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

#16621

On Tue, 23 Oct 2012 11:50:37 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>There are a bunch of
>micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
>at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
>also the random number benchmark).  Not a single application benchmark
>there.

To quote from the file itself:
"These benchmarks have been collated from a variety of sources, and
were originally used to test MPE's VFX code generator and optimiser
for 32 bit Forth systems."

These tests had a specific rationale. I have no doubt that your
tests are good for their purpose, but that purpose is probably 
different.

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]

#16622 — Application Benchmarks (was: FORTH Trouble--Please Show Me)

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Tue, 23 Oct 2012 11:50:37 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>There are a bunch of
>>micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
>>at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
>>also the random number benchmark).  Not a single application benchmark
>>there.
>
>To quote from the file itself:
>"These benchmarks have been collated from a variety of sources, and
>were originally used to test MPE's VFX code generator and optimiser
>for 32 bit Forth systems."
>
>These tests had a specific rationale. I have no doubt that your
>tests are good for their purpose, but that purpose is probably 
>different.

Tests?  We have been talking about benchmarks, not tests.  In
particular, we have been talking about application benchmarks.  From
<http://en.wikipedia.org/wiki/Benchmark_(computing)>:

|Application benchmarks run real-world programs on the system.

That's what <http://www.complang.tuwien.ac.at/forth/appbench.zip>
does and your benchmark suite doesn't do.

Concerning the purpose: The main purpose of appbench is to raise the
bar in Forth benchmarking.  One problem we have had in Forth is that
serious performance problems, in particular I/D-Cache synchronization
issues were not noticed or ignored by Forth implementors because they
did not show up in the microbenchmarks that most Forth implementors
use.  So, when working on the performance of a Forth system, it's a
good idea to use real application benchmarks in addition to, e.g.,
microbenchmarks for particular features.

Another purpose of appbench is to compare the performance of various
Forth systems in a hopefully realistic setting.  The applications in
appbench are relatively large and certainly more realistic and
idiomatic than, e.g., the recursive Fibonacci benchmark, the Byte
Sieve, Wil Baden's LZ77 code (which is an unidiomatic translation of
non-Forth code), or Dhrystone (a synthetic benchmark originally
written in Ada, later translated to C, and apparently also to Forth).

- 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 2012: http://www.euroforth.org/ef12/

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

#16650 — Re: Application Benchmarks (was: FORTH Trouble--Please Show Me)

On Tue, 23 Oct 2012 15:59:31 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>|Application benchmarks run real-world programs on the system.
>
>That's what <http://www.complang.tuwien.ac.at/forth/appbench.zip>
>does and your benchmark suite doesn't do.

Thank you for the explanation.

>Concerning the purpose: The main purpose of appbench is to raise the
>bar in Forth benchmarking.  One problem we have had in Forth is that
>serious performance problems, in particular I/D-Cache synchronization
>issues were not noticed or ignored by Forth implementors because they
>did not show up in the microbenchmarks that most Forth implementors
>use.

Since 2006 the file benchmrk.fth has contained code to test the effect
of code and data separation. Small scale benchmarks like the random
number test are much easier to use when analysing the impact of
such details.

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]

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

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

csiph-web