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

Groups > comp.lang.forth > #46397

Re: The problem with implementation defined behaviour.

From Bernd Paysan <bernd.paysan@gmx.de>
Newsgroups comp.lang.forth
Subject Re: The problem with implementation defined behaviour.
Date 2016-04-01 21:32 +0000
Organization A noiseless patient Spider
Message-ID <ndmpdi$ek8$1@dont-email.me> (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> <ndhob4$eer$3@dont-email.me> <2016Apr1.102503@mips.complang.tuwien.ac.at>

Show all headers | View raw

Am Fri, 01 Apr 2016 08:25:03 +0000 schrieb Anton Ertl:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>I've tested with the current git branchless variants of floored division
>>(which now bases on unsigned division):
>>
>>: utest $1234.5678.9abc.def0 $40000000 $300 DO
>>     2dup i um/mod 2drop  $12 +LOOP  2drop ;
>>: ftest $1234.5678.9abc.def0 $40000000 $300 DO
>>     2dup i fm/mod 2drop  $12 +LOOP  2drop ;
>>: stest $1234.5678.9abc.def0 $40000000 $300 DO
>>     2dup i sm/rem 2drop  $12 +LOOP  2drop ;
>>: mtest $1234.5678.9abc.def0 $40000000 $300 DO
>>     2dup i du/mod 2drop  $12 +LOOP  2drop ;
> 
> I wanted to compare with the old implementation (commit
> 58411a3ad8335ee6d7d5d54c40b520ba71f5f169), but the timing code is
> missing,

Oh, timing is easy, just !time <word> .time

> so I used contrib/divspeed.fs (100M iterations); timings from a
> 4GHz Core i7-6700K:
> 
> implementation    old         old        new
>        default symmetric   floored     floored
>         /        832 ms     820 ms      784 ms mod      776 ms     864
>         ms      868 ms /mod     780 ms     816 ms      936 ms */      
>         792 ms     836 ms      852 ms */mod    828 ms     844 ms     
>         896 ms fm/mod   856 ms     876 ms     2448 ms sm/rem   844 ms   
>          860 ms      812 ms um/mod   820 ms     820 ms      756 ms m*/  
>           3304 ms    3344 ms     3280 ms
> 
> I find the results puzzling: The new / is faster (even than the
> symmetric variant),

Yes, that's expected.

> but /MOD */ and */MOD is slower than the old variant
> (divspeed.fs makes the branches easy to predict, so the new variant
> might have advantages on other code).

Funny, because I haven't changed anything on */ and */MOD yet ;-).

Using cputime as divspeed.fs does is not very accurate.

The Core i7 idiv and div take a shortcut when the input is actually 64 
bit and not 128 bit, so using idiv is faster for small negative numbers 
(which is what divtest.fs does).

That's divtest.fs on my 3.4GHz non-mobile Core i7, with fm/mod for 
negative double numbers first, and positive second:

/       1068 ms  2712 ms
mod      980 ms  2588 ms
/mod     988 ms  2604 ms
*/      1080 ms
*/mod   1164 ms
fm/mod  2712 ms  1028 ms
sm/rem  1132 ms  1144 ms
um/mod   940 ms
m*/     3832 ms

Second column is "negated input"

That is an awful lot worse, just because it's now a "big" number and not 
a small number.

Old method:

/       1212 ms
mod     1168 ms
/mod    1144 ms
*/      1108 ms
*/mod   1100 ms
fm/mod  1144 ms
sm/rem  1128 ms
um/mod   940 ms
m*/     3524 ms

Testing the new code with negative numbers shows that the slowdown is 
quite big:  So the new code is good for the common case (all numbers are 
positive), but bad for the uncommon case.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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