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

Groups > comp.lang.forth > #46362

Re: The problem with implementation defined behaviour.

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: The problem with implementation defined behaviour.
Date 2016-03-31 16:21 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2016Mar31.182116@mips.complang.tuwien.ac.at> (permalink)
References (4 earlier) <4b57b1ee-841e-4007-8812-0c0810620dec@googlegroups.com> <2016Mar30.095908@mips.complang.tuwien.ac.at> <5d973aa6-707b-4e4b-b510-2f62acf80c5d@googlegroups.com> <2016Mar31.125525@mips.complang.tuwien.ac.at> <ea6d7906-5957-4311-a265-02c3038153ce@googlegroups.com>

Show all headers | View raw

mhx@iae.nl writes:
>On Thursday, March 31, 2016 at 1:24:24 PM UTC+2, Anton Ertl wrote:
>> mhx@iae.nl writes:
>> >In answer of which I posted, at that time,
>> >
>> >FORTH> DIVTEST
>> >CELL-BITS = 64
>> >Divisions tested 10,000,000 times (#times).
>> >     /    : 0.033 seconds elapsed.
>> >[s]  /    : 0.110 seconds elapsed.
>> >[f]  /    : 0.155 seconds elapsed.
>> >      mod : 0.020 seconds elapsed.
>> >[s]   mod : 0.112 seconds elapsed.
>> >[f]   mod : 0.152 seconds elapsed.
>> >     /mod : 0.021 seconds elapsed.
>> >[s]  /mod : 0.110 seconds elapsed.
>> >[f]  /mod : 0.150 seconds elapsed.
>> >    */mod : 0.115 seconds elapsed.
>> >[s] */mod : 0.111 seconds elapsed.
>> >[f] */mod : 0.171 seconds elapsed.
>> >    */    : 0.113 seconds elapsed.
>> >[s] */    : 0.113 seconds elapsed.
>> >[f] */    : 0.182 seconds elapsed.
>> >   um/mod : 0.099 seconds elapsed.
>> >   fm/mod : 0.133 seconds elapsed.
>> >   sm/rem : 0.110 seconds elapsed.
>> >   m*/    : 0.236 seconds elapsed. ok
>> >
>> >( nothing == default in iForth, [s] symmetrical, [f] == floored )
>> 
>> The difference between SM/REM and FM/MOD is not that big (actually
>> smaller than in the Gforth/Pentium 4 numbers I posted).  But these
>> data leave some questions open:
>> 
>> Why are the default / MOD and /MOD so much faster than the [S]
>> variants?  Did some optimization kick in that did not work for the [S]
>> variants?
>
>That is indeed because "/" is optimized in the metacompiler (by me),
>while iForth "itself" works on SM/REM and must break it down first.
>I didn't put much effort in optimizing SM/REM and FM/MOD.
>
> 
>> Why is the [F] variant of / MOD /MOD */MOD and */ slower than FM/MOD,
>> while the [S] variants have the same speed as SM/REM?  Did you perform
>> some inlining or other optimization for the [S] variants that you did
>> not do for the [F] variants?
>
>The answer is more or less the same as for the first question.
>It would cost me years to really optimize every case in iForth 
>(at least, in the way it is done now).

That's not necessary, but it means that the results of these
microbenchmarks may say more about your optimizations than about
floored vs. symmetric division on your hardware.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 14:39 +0000
  Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 16:20 +0000
    Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 09:16 -1000
      Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 00:06 +0000
        Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-29 22:09 -0700
          Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 21:37 -1000
          Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
            Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
          Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:59 +0000
            Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-30 10:16 -0700
              Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 23:43 +0000
                Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:01 -0700
                Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:36 +0000
                Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 14:57 -0700
                Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:59 +0000
                Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-02 00:51 -0700
                Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 08:25 +0000
                Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:32 +0000
                division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 11:12 +0000
                Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 20:45 +0000
                Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 10:03 +0000
                Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 22:53 +0000
                Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 10:14 +0000
                Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 13:43 +0000
              Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 10:55 +0000
                Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:38 -0700
                Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 16:21 +0000
                Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-31 11:49 -0700
                Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-31 10:11 -1000
                Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 03:53 -0700
                Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 11:44 +0000
                Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:53 +0000
                Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-02 11:46 -0500
                Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-02 21:43 +0000
                Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-03 03:17 -0500
                Re: The problem with implementation defined behaviour. hughaguilar96@gmail.com - 2016-04-01 23:54 -0700
          Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:58 +0000
          Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:22 +0000
        Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:55 +0000
      Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:44 +0000
        Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:08 +0000
          Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 13:43 +0000
        Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:06 +0000
      Re: The problem with implementation defined behaviour. trevor <tgritchie@blueyonder.co.uk> - 2016-03-30 13:13 +0100
        Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:56 +0000
      Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:49 +0000

csiph-web