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 1B42642933 for ; Wed, 6 Apr 2022 08:42:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 20E5668B247; Wed, 6 Apr 2022 11:42:09 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4E9DF68B0D3 for ; Wed, 6 Apr 2022 11:42:03 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id BFF04240179 for ; Wed, 6 Apr 2022 10:42:02 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7tvmzqckz3M6 for ; Wed, 6 Apr 2022 10:42:02 +0200 (CEST) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 119922400F5 for ; Wed, 6 Apr 2022 10:42:02 +0200 (CEST) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id C608F1601AD; Wed, 6 Apr 2022 10:41:53 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB036517C3185EE467B97EF6B6BAE49=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> =?utf-8?q?=3C?= =?utf-8?q?DM8P223MB036517C3185EE467B97EF6B6BAE49=40DM8P223MB0365=2ENAMP223?= =?utf-8?q?=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 06 Apr 2022 10:41:53 +0200 Message-ID: <164923451378.24258.12863595879743109558@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Soft Works (2022-04-05 23:05:57) > do I understand it right that there won't be a single-thread > operation mode that replicates/corresponds the current behavior? Correct, maintaining a single-threaded mode would require massive amounts of extra effort for questionable gain. > > Not that I wouldn't welcome the performance improvements, but one > concern I have is debugging filtergraph operations. This is already > a pretty tedious task in itself, because many relevant decisions > are made in sub-sub-sub-sub-sub-functions, spread over many places. > When adding an additional - not even deterministic - part to the > game, it won't make things easier. It could even create situations > where it could no longer be possible to replicate an error in a > debugger - in case the existence of a debugger would cause a variance > within the constraints of the non-determinism range. I don't think debugging filtegraph internals will get significantly harders, it might even become slightly easier because you will have a thread entirely dedicated to filtering, with nothing else going on in it. > > From another point of view, this is a change, so fundamental like > ffmpeg(.c) hasn't seen in a long time. > I would at least suppose that this could cause issues at many ends, > and from experience, there may be additional ends where it's rather > unexpected to have effects. > > In that context, I think that doing a change of such a wide scope > in an irreversible way like this, would impose quite a burden on > many other developers, because sooner or later, other developers > will run into situations where something is no longer working like > before and you'll regularly wonder whether this might be a consequence > of ffmpeg.c threading change or caused by other changes. > But then, you won't be able anymore to bisect on that suspicion, > because the threading change can't be reverted and (as long as it's > not shortly after the change) there might have been too many other > changes to easily port them back to a state before the threading > change. > > I wonder whether this couldn't be done in a way that the current > behavior can be preserved and activated by option? > > Wouldn't it be possible to follow an approach like this: > > - Assuming the code would be fine and it would mark the desired > end result > - Put it aside and start over from the current HEAD > - Iteratively morph the code current code in a (possibly) long > sequence of refactoring operations where every single one > (and hence in sum) are semantically neutral - until the code > is turned more and more into what has already been developed > - eventually, only few differences will be left, and these can > be made switchable by an option - as a result, both - old and > new operation modes would be available. If I understand correctly what you're suggesting then I don't believe this approach is feasible. The goal is not "add threading to improve performance", keeping everything else intact as much as possible. The goal is "improve architecture to make the code easier to understand/maintain/extend", threads are a means towards that goal. The fact that this should also improve throughput is more of a nice side effect than anything else. This patchset already changes behaviour in certain cases, making the output more predictable and consistent. Reordering it somehow to separate "semantically neutral" patches would require vast amounts of extra work. Note that progressing at all without obviously breaking anything is already quite hard --- I've been working on this since November and this is just the first step. I really do not want to make my work 10x harder for the vague benefit of maybe making some debugging slightly easier. -- Anton Khirnov _______________________________________________ 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".