From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ygrekheretix@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 38B837EE51
	for <caml-list@sympa.inria.fr>; Fri, 26 Apr 2013 05:31:42 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  ygrekheretix@gmail.com) identity=pra;
  client-ip=209.85.192.182;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="ygrekheretix@gmail.com";
  x-sender="ygrekheretix@gmail.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  ygrekheretix@gmail.com designates 209.85.192.182 as permitted
  sender) identity=mailfrom; client-ip=209.85.192.182;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="ygrekheretix@gmail.com";
  x-sender="ygrekheretix@gmail.com";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-pd0-f182.google.com) identity=helo;
  client-ip=209.85.192.182;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="ygrekheretix@gmail.com";
  x-sender="postmaster@mail-pd0-f182.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisCAGP0eVHRVcC2m2dsb2JhbABRgz2CcLtBgQcWDgEBAQEBBgsUFCiCHwEBBAE6BgEbHgMMBgULKRIjEQEFARwZiAEBAwkFAaF1jDGCfYQ5ChknDVmHbgEFDI1ygT4WgzgDiQ+FYogqAYEljhg/hEGBXg
X-IPAS-Result: AisCAGP0eVHRVcC2m2dsb2JhbABRgz2CcLtBgQcWDgEBAQEBBgsUFCiCHwEBBAE6BgEbHgMMBgULKRIjEQEFARwZiAEBAwkFAaF1jDGCfYQ5ChknDVmHbgEFDI1ygT4WgzgDiQ+FYogqAYEljhg/hEGBXg
X-IronPort-AV: E=Sophos;i="4.87,554,1363129200"; 
   d="scan'208";a="14927261"
Received: from mail-pd0-f182.google.com ([209.85.192.182])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Apr 2013 05:31:41 +0200
Received: by mail-pd0-f182.google.com with SMTP id 14so631765pdj.13
        for <caml-list@inria.fr>; Thu, 25 Apr 2013 20:31:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:date:from:to:subject:message-id:in-reply-to:references
         :x-mailer:mime-version:content-type:content-transfer-encoding;
        bh=itVvGcuT8vveFdyyoNxeMhoeQhvKGGFbKxXZDaKgIPM=;
        b=iSf7iFldNWc4oSagslrfWFHJ9N8YlYqh20936TqEZwqVsF0rGGFOttGz3d3pBlvNBF
         1Lyl2wmIF9o+o1JIvUjhkjS24bcbK9lfZkOQPpgIlqojIARnREVcBOCz453w5DlQtNYv
         kgk9+HfoeIm6FibG6VZO//1azSjpIz8NzhKhGpD3GaHqVp4dcysQePGumhrf78jUBnTW
         mF0ofmxK35lX2djeBZE7Zt8ftNMob2Ox5fYAInCv7WB4JmLHW5NDoVnSkOyRQjSxSK5U
         EHyDKvFGmP1RbCEdLha7GtPS6fz/EODQiUliD++e9GzJvWgTKUtuZoqDdgLzHUrrPgQZ
         ejHQ==
X-Received: by 10.68.216.70 with SMTP id oo6mr55833759pbc.160.1366947099821;
        Thu, 25 Apr 2013 20:31:39 -0700 (PDT)
Received: from kiwi.local.tld ([182.55.247.28])
        by mx.google.com with ESMTPSA id ts3sm9771358pbc.12.2013.04.25.20.31.37
        for <caml-list@inria.fr>
        (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Thu, 25 Apr 2013 20:31:38 -0700 (PDT)
Date: Fri, 26 Apr 2013 11:31:36 +0800
From: ygrek <ygrekheretix@gmail.com>
To: caml-list@inria.fr
Message-Id: <20130426113136.ecf0fdfe1c038b5be9e1e287@gmail.com>
In-Reply-To: <201304241557.r3OFvT9a012995@outgoing.mit.edu>
References: <20130424183543.e3a4290382f7f9ce7b522a57@gmail.com>
	<201304241557.r3OFvT9a012995@outgoing.mit.edu>
X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] ackermann microbenchmark strange results

On Wed, 24 Apr 2013 11:57:29 -0400
John Carr <jfc@MIT.EDU> 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.

I was aware of the data alignment influences, but didn't think of
code alignment playing such a role. Got some interesting links to read :)
Thanks you!

-- 
 ygrek
 http://ygrek.org.ua