From: "Jon Harrop" <jon@ffconsultancy.com>
To: "'Török Edwin'" <edwintorok@gmail.com>
Cc: <caml-list@inria.fr>
Subject: RE: Value types (Was: [Caml-list] ocamlopt LLVM support)
Date: Sun, 12 Dec 2010 18:01:13 -0000 [thread overview]
Message-ID: <039301cb9a26$9214c2e0$b63e48a0$@com> (raw)
In-Reply-To: <20101212192632.6536a647@deb0>
Török Edwin wrote:
> Do you really need to use Int64 for that though? Won't the 63-bit
> version do?
I'm running 32-bit.
> > I am unable to reproduce your results. Here, the time falls from 24s
> > to 19.5s (using ocamlopt 3.12.0 on Intel x86) which is still 26×
> > slower than HLVM.
Sorry, I'm actually using an Opteron x86 (logged in from an Intel x86!).
> Do you still have 'idiv' in the compiled code? See my attached
> assembly, and compare it with yours please.
> I was doing the test on 64-bit, with ocamlopt 3.11.2 and 3.12.0.
I get what appear to be calls to C code:
camlCollatz__collatzLen_1030:
subl $8, %esp
.L103:
movl %eax, 4(%esp)
movl %ebx, 0(%esp)
pushl $camlCollatz__10
pushl %ebx
movl $caml_equal, %eax
call caml_c_call
.L104:
addl $8, %esp
cmpl $1, %eax
je .L102
movl 4(%esp), %eax
addl $8, %esp
ret
.align 16
.L102:
pushl $camlCollatz__8
movl 4(%esp), %eax
pushl %eax
movl $caml_int64_and, %eax
call caml_c_call
.L105:
addl $8, %esp
pushl $camlCollatz__9
pushl %eax
movl $caml_equal, %eax
call caml_c_call
.L106:
addl $8, %esp
cmpl $1, %eax
je .L101
pushl $3
movl 4(%esp), %eax
pushl %eax
movl $caml_int64_shift_right, %eax
call caml_c_call
.L107:
addl $8, %esp
movl %eax, %ebx
jmp .L100
.align 16
.L101:
movl 0(%esp), %eax
pushl %eax
pushl $camlCollatz__6
movl $caml_int64_mul, %eax
call caml_c_call
.L108:
addl $8, %esp
pushl $camlCollatz__7
pushl %eax
movl $caml_int64_add, %eax
call caml_c_call
.L109:
addl $8, %esp
movl %eax, %ebx
.L100:
movl 4(%esp), %eax
addl $2, %eax
jmp .L103
> FWIW the original code took 2.8 seconds here, so only 4x slower (this
> is an AMD Phenom II x6 1090T CPU). It probably depends how fast/slow
> the 'idiv' is on your CPU.
The performance of idiv is irrelevant here. The bottleneck may be those C calls but I don't understand why they are being generated.
Cheers,
Jon.
next prev parent reply other threads:[~2010-12-12 18:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-12 14:54 Jon Harrop
2010-12-12 15:55 ` Török Edwin
2010-12-12 17:14 ` Jon Harrop
2010-12-12 17:26 ` Török Edwin
2010-12-12 18:01 ` Jon Harrop [this message]
2010-12-12 18:22 ` Török Edwin
2010-12-12 19:09 ` Benedikt Meurer
2010-12-12 19:20 ` John Carr
2010-12-14 9:43 ` Value types Goswin von Brederlow
2010-12-12 19:55 ` Value types (Was: [Caml-list] ocamlopt LLVM support) Török Edwin
2010-12-12 22:05 ` Jon Harrop
2010-12-12 22:27 ` Török Edwin
2010-12-12 23:41 ` Jon Harrop
2010-12-13 2:13 ` Eray Ozkural
2010-12-12 21:50 ` Jon Harrop
2010-12-13 8:43 ` Alain Frisch
2010-12-15 10:29 ` Benedikt Meurer
2010-12-15 13:15 ` Jon Harrop
2010-12-14 9:54 ` Value types Goswin von Brederlow
2010-12-12 19:53 ` Value types (Was: [Caml-list] ocamlopt LLVM support) Brian Hurt
2010-12-12 20:39 ` Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='039301cb9a26$9214c2e0$b63e48a0$@com' \
--to=jon@ffconsultancy.com \
--cc=caml-list@inria.fr \
--cc=edwintorok@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox