From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id A142B44311 for ; Mon, 5 Sep 2022 19:58:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AC03368B889; Mon, 5 Sep 2022 22:58:38 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3827E68B1CE for ; Mon, 5 Sep 2022 22:58:32 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 285JwUAP032382-285JwUAQ032382 for ; Mon, 5 Sep 2022 22:58:30 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id D48DFA1467 for ; Mon, 5 Sep 2022 22:58:30 +0300 (EEST) Date: Mon, 5 Sep 2022 22:58:29 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: ffmpeg-devel@ffmpeg.org In-Reply-To: <20220905122020.4103129-1-martin@martin.st> Message-ID: <6bfb9a2c-6db5-a888-d13e-e6c5ef14c23a@martin.st> References: <20220905122020.4103129-1-martin@martin.st> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH] slicethread: Limit the automatic number of threads to 16 X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 5 Sep 2022, Martin Storsj=F6 wrote: > This matches a similar cap on the number of automatic threads > in libavcodec/pthread_slice.c. > > On systems with lots of cores, this does speed things up in > general (measurable on the level of the runtime of running > "make fate"), and fixes a couple fate failures in 32 bit mode on > such machines (where spawning a huge number of threads runs > out of address space). > --- On second thought - this observation that it speeds up "make -j$(nproc) = fate" isn't surprising at all; as long as there are jobs to saturate all = cores with the make level parallelism anyway, any threading within each = job just adds extra overhead, nothing more. // Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".