From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 23B5623C4ED for ; Mon, 15 Sep 2025 16:03:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757952191; cv=none; b=hCu3sAdPKz0HEwtRHV9BX6BHJUECpWdscwNWRiA4o7BwhEd1YiGOxbUOfLD9aCfvNwVa8TcTsV3ZQ6aTXqWl03EXbzH0Tse8uinBNZmzGccdfdMVOf+BHEVMNlrGuM76PIfyZs+OCxARaT2x0Fiz8/xgUQj7g+v70BX/JA3nU44= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757952191; c=relaxed/simple; bh=QPRoP7epFosLbDiuuWmpyPHmr63+JaY09H8/EVERbKk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FwZAkIRbL2rIj6ETLNEZGk2cgqcC6KsgLrCqIRiy4Ub8DY7gLCrJq7s5MBCXGu4u5X2niRnZ4RhTVQrVJfbYo9BBUY0ZrI3AdvKmM0B7F46ZwEcVRvhe2jfr+LKdhsbHiSk4Js14efXQZ3oPCqlKXkY3drmLgngZ17B56qE+hHA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 70A6B59686; Mon, 15 Sep 2025 16:03:01 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf17.hostedemail.com (Postfix) with ESMTPA id 595DD1C; Mon, 15 Sep 2025 16:02:59 +0000 (UTC) Date: Mon, 15 Sep 2025 12:04:00 -0400 From: Steven Rostedt To: Indu Bhagat Cc: Jens Remus , Sterling Augustine , Pavel Labath , Andrii Nakryiko , Josh Poimboeuf , Serhei Makarov , Binutils , "linux-toolchains@vger.kernel.org" Subject: Re: Unaligned access trade-offs for SFrame FRE layout Message-ID: <20250915120400.09588912@gandalf.local.home> In-Reply-To: <0c524c2c-cbfa-4058-b360-b97cd361a190@oracle.com> References: <20250912151855.3af8c2ab@gandalf.local.home> <0c524c2c-cbfa-4058-b360-b97cd361a190@oracle.com> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/nCuDG3b9/5l+2m6T_A46rXT" X-Stat-Signature: zw1h1b6cmqb34fy6fugdoq96nd4h5o6o X-Rspamd-Server: rspamout01 X-Rspamd-Queue-Id: 595DD1C X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX18Qg42O7kwg53Cd+uaGA5aocg27vObrNPE= X-HE-Tag: 1757952179-80871 X-HE-Meta: U2FsdGVkX199vWMT6GnK8mDKyQj/vNrGJr3xXRKMhpic72twwpDwJHHuEA1ZQx42M3bjnXbb+fum7+mK+98ynoqpjOxWyzvlj24Iihi5IFUezSTcsIIyx/yxrZyQKW80qV6zdTqvfAzAH5oUfxMXlrAuSn3oDaSzxrgaqOBwvKZe2GEuO56JoKvYJKIiVhJQjcV/Go0y9V6OePTP0LpGIo56irWQu3O6vhhivGKYXour2/uLmdz9m6CeoXpmEXxMQM9cgLGjCanxZZNSnVgw77raHBQ2xji26hQGKDAsiWME30f3rJmlJF6qmEZmEQqIDy7w7yhSUSRyQOsPLdsb+uzj9bVJ3HxDn5nkzgXC9j47bUA46R6J8P/PXM4WZeakIOTr+y/8cCeWHVDyqaYOmmLtjp7sbyx4bxE/pLeCqYleoMrJFoXqfg== --MP_/nCuDG3b9/5l+2m6T_A46rXT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 13 Sep 2025 00:56:34 -0700 Indu Bhagat wrote: > I think quantifying the performance impact of unaligned accesses for > stack tracing using SFrame sections will be larger experiment which will > be hardware dependent.. > > https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/ I'm not so sure his example is good enough to show the overhead. So I wrote a much simpler test. I create an array of 1,000,004 unsigned longs and fill it with a simple increment. I then loop over the array and reading at every 5618 increments and modulus it to 1,000,000. I use 5816 because it is a factor of 1,000,004. By incrementing it by this number and modulus it with 1,000,000, then the wrap will go to 1,000,000 + 4. meaning by looping a 1,000,000 times on a 1,000,000 words should hit all of them if they are 4 byte long words or half of them if they are 8 byte words. I time a loop of going over all 1,000,000 numbers and simply adding them. I then report the total time. The test takes an offset to add before reading. Here's my results on two machines: On my workstation: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz $ ./aligned-access 0 val = 2296870857426500744 time = 6822 us $ ./aligned-access 1 val = -2296870857426996608 time = 7319 us $ ./aligned-access 2 val = 2296870857426500744 time = 7432 us $ ./aligned-access 3 val = -2296870857426996608 time = 7522 us $ ./aligned-access 4 val = 2296870857426500744 time = 6841 us On my server: Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz $ ./aligned-access 0 val = 2296870857426500744 time = 7093 us $ ./aligned-access 1 val = -2296870857426996608 time = 6948 us $ ./aligned-access 2 val = 2296870857426500744 time = 6761 us $ ./aligned-access 3 val = -2296870857426996608 time = 7111 us $ ./aligned-access 4 val = 2296870857426500744 time = 6940 us $ ./aligned-access 5 val = -2296870857426996608 time = 6939 us $ ./aligned-access 6 val = 2296870857426500744 time = 6937 us $ ./aligned-access 7 val = -2296870857426996608 time = 7254 us $ ./aligned-access 8 val = 2296870857426500744 time = 6939 us My workstation is a bit older than my server, and it looks like alignment does make a difference. For my server, it didn't show any difference. Thus, it looks like it's only a problem for older machines (on x86). Would be good to see how the performance of this is on arm64 machines. But feel free to try it out yourself. -- Steve --MP_/nCuDG3b9/5l+2m6T_A46rXT Content-Type: text/x-c++src Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=aligned-access.c #include #include #include #include #include #include static char *argv0; static char *get_this_name(void) { static char *this_name; char *arg; char *p; if (this_name) return this_name; arg = argv0; p = arg+strlen(arg); while (p >= arg && *p != '/') p--; p++; this_name = p; return p; } static void usage(void) { char *p = get_this_name(); printf("usage: %s [alignement]\n" " alignment is a number offset\n" "\n",p); exit(-1); } static void __vdie(const char *fmt, va_list ap, int err) { int ret = errno; char *p = get_this_name(); if (err && errno) perror(p); else ret = -1; fprintf(stderr, " "); vfprintf(stderr, fmt, ap); fprintf(stderr, "\n"); exit(ret); } void die(const char *fmt, ...) { va_list ap; va_start(ap, fmt); __vdie(fmt, ap, 0); va_end(ap); } void pdie(const char *fmt, ...) { va_list ap; va_start(ap, fmt); __vdie(fmt, ap, 1); va_end(ap); } static unsigned long long get_time(void) { unsigned long long time; struct timespec ts; clock_gettime(CLOCK_MONOTONIC_RAW, &ts); time = ts.tv_sec * 1000000; time += ts.tv_nsec / 1000; return time; } #define ARRAY_SIZE 1000000 static void fill_array(void *array) { for (int i = 0; i < ARRAY_SIZE; i++) { *(long *)(array + sizeof(long) * i) = i; } } int main (int argc, char **argv) { unsigned long long start, end; unsigned long long val = 0; unsigned long long idx, i; void *array; int offset; argv0 = argv[0]; if (argc < 2) usage(); array = malloc((ARRAY_SIZE + 1) * sizeof(long)); if (!array) pdie("Allocating array"); fill_array(array); offset = atoi(argv[1]); start = get_time(); for (i = 0; i < ARRAY_SIZE; i++) { idx = (i * 5618) + offset; idx %= 1000000; val += *(unsigned long *)(array + idx); } end = get_time(); printf("val = %lld\n", val); printf("time = %lld us\n", end - start); return 0; } --MP_/nCuDG3b9/5l+2m6T_A46rXT--