Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46386
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: The problem with implementation defined behaviour. |
| Date | 2016-04-01 08:25 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2016Apr1.102503@mips.complang.tuwien.ac.at> (permalink) |
| References | (3 earlier) <ndf59p$kap$1@dont-email.me> <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> |
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, 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), 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).
FM/MOD is very slow in the new variant; it's code is longer, but not
that much longer (see below). Strange. SM/REM and UM/MOD are a bit
faster in the new implementation, although their source code did not
change, and the binary code for um/mod is the same.
I get similar timings on repeating these runs, so these are not
one-time flukes. Inserting code before the benchmarked code to vary
code alignment seems to cause differences by up to 60ms for this test,
so code alignment may be responsible for the smaller differences
(which means we need a better way to benchmark this stuff). The
big slowdown for FM/MOD remains unexplained.
Here are some code fragments:
/
old symmetric old floored new floored
mov 0x8(%r15),%rax mov 0x8(%r15),%rcx mov 0x8(%r15),%rcx
add $0x8,%rbx mov %r14,%rsi add $0x8,%r15
add $0x8,%r15 add $0x8,%r15 test %r14,%r14
cqto mov %rcx,%rax jns (to lea)
idiv %r14 cqto mov %r14,%rax
mov %rax,%r14 idiv %r14 test %rcx,%rcx
mov -0x8(%rbx),%rdx mov %rax,%rdi mov $0x0,%edx
mov %rdx,%rax mov %rax,%r14 not %rax
jmpq *%rax mov %rcx,%rax cmovns %rax,%rdx
xor %rsi,%rax mov %rcx,%rax
jns (after cmovne) neg %r14
mov %rcx,%rax neg %rax
sub $0x1,%rdi jmp (to div)
cqto lea -0x1(%r14),%rax
idiv %rsi test %rcx,%rcx
test %rdx,%rdx mov $0x0,%edx
cmovne %rdi,%r14 cmovs %rax,%rdx
add $0x8,%rbx mov %rcx,%rax
mov -0x8(%rbx),%rdx div %r14
mov %rdx,%rax add $0x8,%rbx
jmpq *%rax mov %rax,%r14
mov -0x8(%rbx),%rdx
mov %rdx,%rax
jmpq *%rax
fm/mod
old (both engines) new
mov 0x8(%r15),%r8 mov %r14,%rcx
mov %r14,%rsi mov %r15,%rsi
mov 0x10(%r15),%rax mov 0x10(%r15),%r10
mov %r15,%rcx shr $0x3f,%rcx
lea 0x8(%r15),%r15 mov 0x8(%r15),%r11
mov %r8,%rdx lea 0x8(%r15),%r15
idiv %r14 test %cl,%cl
xor %rsi,%r8 je (to next mov)
mov %rax,%r14 neg %r14
jns (to add) neg %r10
test %rdx,%rdx adc $0x0,%r11
je (to add) neg %r11
lea -0x1(%rax),%r14 mov %r11,%rdi
lea (%rdx,%rsi,1),%rdx movzbl %cl,%ecx
add $0x8,%rbx mov %r11,%rdx
mov %rdx,0x10(%rcx) sar $0x3f,%rdi
mov -0x8(%rbx),%rdx mov %r10,%rax
mov %rdx,%rax add $0x8,%rbx
jmpq *%rax and %r14,%rdi
add %rdi,%rdx
div %r14
mov %rax,%r14
mov %rcx,%rax
neg %rax
xor %rdx,%rax
add %rcx,%rax
mov %rax,0x10(%rsi)
mov -0x8(%rbx),%rdx
mov %rdx,%rax
jmpq *%rax
- 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
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