From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jon@ffconsultancy.com>
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 15F43BC57
	for <caml-list@yquem.inria.fr>; Sun, 12 Dec 2010 19:01:26 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AADOcBE3UnwdkkGdsb2JhbACDXJMyjQEVAQEBAQkJDAcRBCWvKY9MgSGDNXQEjg0
X-IronPort-AV: E=Sophos;i="4.59,333,1288566000"; 
   d="scan'208";a="70355420"
Received: from relay.pcl-ipout02.plus.net ([212.159.7.100])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Dec 2010 19:01:25 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EACSdBE3Unw4U/2dsb2JhbACDXJMyjQF4ry2PTIEhgzV0BI4N
Received: from outmx08.plus.net ([212.159.14.20])
  by relay.pcl-ipout02.plus.net with ESMTP; 12 Dec 2010 18:01:24 +0000
Received: from [84.93.149.66] (helo=WinEight)
	 by outmx08.plus.net with esmtp (Exim) id 1PRqEe-0000vW-0u; Sun, 12 Dec 2010 18:01:24 +0000
From: "Jon Harrop" <jon@ffconsultancy.com>
To: =?utf-8?Q?'T=C3=B6r=C3=B6k_Edwin'?= <edwintorok@gmail.com>
Cc: <caml-list@inria.fr>
References: <036001cb9a0c$725acef0$57106cd0$@com>	<20101212175524.73a8e285@deb0>	<038301cb9a20$13af7d10$3b0e7730$@com> <20101212192632.6536a647@deb0>
In-Reply-To: <20101212192632.6536a647@deb0>
Subject: RE: Value types (Was: [Caml-list] ocamlopt LLVM support)
Date: Sun, 12 Dec 2010 18:01:13 -0000
Message-ID: <039301cb9a26$9214c2e0$b63e48a0$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuaIbt4UJa5VEU/TZGa2qO5tb8TswAAjiXw
Content-Language: en-gb
X-Spam: no; 0.00; ocamlopt:01 ocamlopt:01 fwiw:01 cheers:01 edwin:98 $1,:98 $1,:98 $2,:98 1090:98 wrote:01 caml-list:01 int:01 int:01 caml:02 caml:02 

T=C3=B6r=C3=B6k 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=C3=97
> > 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.