From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id 12A4C7EE51
	for <caml-list@sympa.inria.fr>; Wed, 24 Apr 2013 18:07:57 +0200 (CEST)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=pra; client-ip=193.252.23.211;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.211;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@msa.smtpout.orange.fr) identity=helo;
  client-ip=193.252.23.211;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr";
  x-sender="postmaster@msa.smtpout.orange.fr";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtUBAHsCeFHB/BfTlGdsb2JhbABQDoMvu3aCZIEWDgEBAQEHDQkJFAMlgh8BAQU4QAEQCw4KCRYPCQMCAQIBRQYBDAEHAQGIFL4djW0MgTcHg0sDlxyGDo1hQYFp
X-IPAS-Result: AtUBAHsCeFHB/BfTlGdsb2JhbABQDoMvu3aCZIEWDgEBAQEHDQkJFAMlgh8BAQU4QAEQCw4KCRYPCQMCAQIBRQYBDAEHAQGIFL4djW0MgTcHg0sDlxyGDo1hQYFp
X-IronPort-AV: E=Sophos;i="4.87,542,1363129200"; 
   d="scan'208";a="12087259"
Received: from msa02.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.211])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Apr 2013 18:07:56 +0200
Received: from [192.168.1.106] ([86.195.23.217])
	by mwinf5d51 with ME
	id Ts7s1l00U4h25tS03s7sz2; Wed, 24 Apr 2013 18:07:56 +0200
Message-ID: <51780360.3020607@frisch.fr>
Date: Wed, 24 Apr 2013 18:08:00 +0200
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0
MIME-Version: 1.0
To: John Carr <jfc@MIT.EDU>, ygrek <ygrekheretix@gmail.com>
CC: caml-list@inria.fr
References: <20130424183543.e3a4290382f7f9ce7b522a57@gmail.com> <201304241557.r3OFvT9a012995@outgoing.mit.edu>
In-Reply-To: <201304241557.r3OFvT9a012995@outgoing.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] ackermann microbenchmark strange results

+1

I've already seen 20% speedup obtained by adding some dead code (in an 
OCaml program, but this is irrelevant).

-- Alain

On 04/24/2013 05:57 PM, John Carr wrote:
> Try changing loop alignment by editing assembly code.  The address of
> ack is different in the different versions.  Modern Intel processors are
> sensitive to code alignment.  There is a limit on the number of branch
> prediction table entries per cache line.  An instruction that crosses a
> cache line boundary may be slower than an instruction within a cache
> line.  I am not surprised to see a 20% difference caused by an apparently
> irrelevant code change.
>
>> Moreover, the generated assembly code for the main loop is the same, afaics. The only
>> difference is the initialization of structure fields and the initial call to ack. Please can anybody
>> explain the performance difference? I understand that microbenchmarks are no way the basis to draw
>> performance conclusions upon, but I cannot explain these results to myself in any meaninful way.
>> Please help! :)
>