From owner-freebsd-current@freebsd.org Mon Oct 23 21:19:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 942DEE554D9 for ; Mon, 23 Oct 2017 21:19:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A8D712A for ; Mon, 23 Oct 2017 21:19:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x234.google.com with SMTP id 189so21663139iow.10 for ; Mon, 23 Oct 2017 14:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DzUYSjZiwvSDIeGW1Yg4zYhebi0rTiuxE9+mbcUYrbY=; b=e433GNML5cMGBS4S4kxkCYO3e4ir4mrZrL/pyVCLDBNYNgFLkWWEgxO3/S5tYdfU0u 24YgmwRqU2hDMwjKweVhaxaanRbnna2+LsWSybFzeSTgDhUPViCO7NlVmWwa+8c2IHsJ NqLBmDkx/nhCDpflYNeGD/waUlUpp5GTr2jeG464B7Z+mWZJ6Auwe+WmEYqkTZM09PDv KKeeh3Wqsv0rY+Ijdnb1PkNns4uDj7A7YIDsLZvjVlO/CSxFcOSQqNfqzRxhHi8LVmIj e7UAF5IHGU+s6awvtfGr9kfE2QeRw3lsoV/0RcbMtl8WuizZ+eHl9e8k7OTfdIsfFDfc SOEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DzUYSjZiwvSDIeGW1Yg4zYhebi0rTiuxE9+mbcUYrbY=; b=Mx2Ao1fjPdoZGa8OtKM05NRzjb439ktyvHlQarUqoKBYg5PiKZHWE6VPLubKGRUd8a 5TjkT0QYZ0TjoZDCF8nxDpRmAB9fA4pSEGqlae1LM77Y7HNXleeV/JORMm4MUXpM+JZL 2QEEviK436uFyjzr0aOtnAqSRnLD4r3iX0Gq3hz+XUsDjm1v4yNe8kfbl11KKl2Dpwex koDtAVA//MFSXsjeDMXxSQMreug83zhzaFaiqUC+/xnlModzYy455PIpKYjFCGL6zZ/N ylu1yPMc1esubvKffrQhB9IuNwxysHT8/S0YGMVY5jeShBlYRY9/6+xYoPYQevJviESY aSnQ== X-Gm-Message-State: AMCzsaVcgspDb8maGkIBzloaijpJHxup9uhQMFcsrclL0WgHdVohjb4E uWptmvepI5X5o2+gTPiffvkYo8K5aUL4Rr+eBuw= X-Google-Smtp-Source: ABhQp+RdcHXnLSAofNi2OR19IFx54/JcTVP0tvyneY+6Lczi74eUkQ10eH4NcS8FBaZ0oFHCgPllDOwt6f0HzTXGy4E= X-Received: by 10.107.114.5 with SMTP id n5mr11093612ioc.291.1508793564479; Mon, 23 Oct 2017 14:19:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.66 with HTTP; Mon, 23 Oct 2017 14:19:24 -0700 (PDT) In-Reply-To: References: From: blubee blubeeme Date: Tue, 24 Oct 2017 05:19:24 +0800 Message-ID: Subject: Re: There is *NO* abi stability in -head To: Mateusz Guzik Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 21:19:25 -0000 Thanks for these, I came across them when writing some game engine code a few years back. I really enjoy this stuff because I find it down right obnoxious that code gets slower as CPU power increases! On Tue, Oct 24, 2017 at 4:35 AM, Mateusz Guzik wrote: > This is your friendly reminder that in head struct layouts can change > and each update requires you to rebuild *all* modules (including ones > which come from ports). In practice you can get away without it most of > the time, but if in doubt or seeing funny crashes - *recompile* and test > with that. > > I'm sending this because in upcomming weeks struct thread (and probably > more) will start getting fields moved around to improve cache-locality > and reduce memory waste > > Both problems types are well known and rather widespread in big > real-world c codebases. > > 1. memory waste > Consider a 64-bit platform with 32-bit ints and 64-bit pointers > (coincidently that's e.g. amd64 on *BSD, Linux, Illumos and others): > > struct crap { > int i1; > void *p1; > int i2; > void *p2; > }; > > Normallly fields are aligned to their size. So in particular p1 will be > aligned to *8* bytes. But since sizeof i1 is only 4 bytes, there are > another 4 bytes straight up wasted. The total sizeo of the obj is 32 > bytes. > > That is, if an object of type struct crap is at address 0x1000, fields > will be: > > 0x1000 i1 > 0x1008 p1 > 0x1010 i2 > 0x1018 p2 > > Instead, the same can be reshuffled: > struct crap2 { > int i1; > int i2; > void *p1; > void *p2; > }; > > With offsets: > > 0x1000 i1 > 0x1004 i2 > 0x1008 p1 > 0x1010 p2 > > This is only 24 bytes. 2 ints can be placed together and since they add > up to 8 the p1 pointer gets the right alignment without extra padding. > > struct thread accumulated some of this and can just shrink without > removing anything. > > Interested parties can read http://www.catb.org/esr/structure-packing/ > > 2. cacheline bouncing (profesionnal term: cacheline ping pong) > > cpus store main memory content in local caches. the smallest unit it > reads is 64 bytes (aligned to 64, i.e. reading of 0x1010 will fetch > 0x1000). > > There are fields which are accessed only by the thread owning the > struct. If they happen to share the line with something modified by > other threads we lose on performance as now the cpu has to talk to > some other cpu which has the line modified. This is increasingly painful > on numa systems, where response times are longer. > > Furthermore, if fields frequently read/modified together are very far > apart, chances are they require avoidable memory fetches - instead of > taking just one line, they may take several. As cache size is finite, > this may mean something else useful has to be evicted. > > For interested parties I can't recommend enough: > https://www.kernel.org/pub/linux/kernel/people/paulmck/ > perfbook/perfbook.html > > -- > Mateusz Guzik > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >