From owner-freebsd-current@FreeBSD.ORG Wed May 13 15:21:09 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 549804C3; Wed, 13 May 2015 15:21:09 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE181965; Wed, 13 May 2015 15:21:05 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id E88D21013A0; Wed, 13 May 2015 14:44:20 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org ([TEMPUNAVAIL]. [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Wed, 13 May 2015 14:44:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1431528261139:1580616211 X-MC-Ingress-Time: 1431528261139 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YsXtN-0001gY-QG; Wed, 13 May 2015 14:44:13 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4DEi93P003468; Wed, 13 May 2015 08:44:09 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18zqKsH2h7c9DvCens0acNn Message-ID: <1431528249.1221.15.camel@freebsd.org> Subject: Re: Increase BUFSIZ to 8192 From: Ian Lepore To: Hans Petter Selasky Cc: David Chisnall , John-Mark Gurney , Poul-Henning Kamp , Baptiste Daroussin , current@freebsd.org Date: Wed, 13 May 2015 08:44:09 -0600 In-Reply-To: <55530CC3.1090204@selasky.org> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 X-AuthUser: hippie Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 13 May 2015 15:21:09 -0000 On Wed, 2015-05-13 at 10:35 +0200, Hans Petter Selasky wrote: > On 05/13/15 10:27, David Chisnall wrote: > > On 13 May 2015, at 09:03, John-Mark Gurney wrote: > >> > >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 += 0000: > >>> -------- > >>> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney = writes: > >>> > >>>> Also, you'd probably see even better performance by increasing the > >>>> size to 64k, [...] > >>> > >>> easy: > >>> 8K on 32bit > >>> 64k on 64bit > >> > >> Sounds good to me... Just for people who care... I did a quick set = of > >> benchmarks on sha256.. This is using my preliminary patch to use sse= 4 > >> optimized sha256... But this should be the same for others... > >> > >> The numbers in ministat output are the time in seconds it takes my > >> 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so low= er > >> numbers are better.. I've processed them into easier to read format= : > >> BUFSIZ: 145MB/sec > >> 8k: 193MB/sec > >> 16k: 198MB/sec > >> 64k: 202MB/sec > >> 128k: 202MB/sec > >> -t: 211MB/sec > > > > It looks like most of the benefit is gained at 16KB. Did you try run= ning the benchmark with something else running at the same time to see if= there is any advantage in trashing the caches a bit less (simple case, w= hat happens if you run two instances of the same benchmark at once)? > > > > I suspect that you=A2re about right anyway - I recently did some test= s while playing with JavaScript FFI generation with a multithreaded proce= ss JavaScript environment calling out to OpenSSL to do SHA calculations a= nd having each of 8 threads reading in 128KB chunks gave the fastest perf= ormance (Core i7, 4 cores + hyperthreading), with only a negligible gain = over 64KB. In all cases, the JavaScript implementation was significantly= faster than the openssl tool, which used 8KB buffers. > > >=20 > Hi, >=20 > You should also try this using an USB disk. The performance numbers=20 > heavily depends on the hardware's interrupt moderation values. All this discussion should be happening in phabricator, not the email that announces the review on phab. But, since it's now happening here, I guess I'll transplant my comments from there to here... There are 2125 occurrances of BUFSIZ in the base code (probably 95% of them inappropriately used to size a local temp buffer or string). Do you really want to perturb that much working tested software because it makes md5 faster? How many of those occurrances are stack-allocated variables and is it wise to allocate 8k buffers on the stack for all of them? How about existing programs (not necessarily in base) that open many streams concurrently... what will be the impact of a sudden 8x increase in memory usage for them? It seems to me that if libmd needs bigger buffers to perform well, it should use setvbuf(). -- Ian