From: Sundeep KOKKONDA <Sundeep.Kokkonda@windriver.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org, randy.macleod@windriver.com
Subject: Re: [OE-core] [PATCH] rust: Enable parallel-frontend-threads
Date: Thu, 12 Mar 2026 18:41:12 +0530 [thread overview]
Message-ID: <8a0c93d3-d8ce-4ee0-bb08-fbda7e5f1883@windriver.com> (raw)
In-Reply-To: <CANNYZj_D=9z-ZjjP2D+RqVUAF2Kq0a8cd62dqE5doHzSYdPQnA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
On 12-Mar-26 14:32, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Thu, 12 Mar 2026 at 05:07, Sundeep KOKKONDA via
> lists.openembedded.org
> <sundeep.kokkonda=windriver.com@lists.openembedded.org> wrote:
>> Test Results:
>> A few tests ran by, with and without enabling this option.
>> - Avg. default build time (w/o this option) - 56m 50.104s
>> - Avg. build time with this option - 49m 17.224s
>> - Performance Difference - 7m 32.880s faster builds (≈ 13.3%)
>>
>> Tests were performed by setting thread count as 8 & 16 but no much difference is seen.
>> So, the parallel-frontend-threads = 8 is set.
> It would really help to provide specifics. What tests did you run, and
> how were the numbers obtained? How can these tests be reproduced? What
> CPU was used and how many cores it had?
I tested the rust build time with `time bitbake rust` (I wonder how I
missed this to put is commit msg)
Machine Info: Intel(R) Xeon(R) CPU E5-4669 v3 @ 2.10GHz with 144 CPUs.
>
>> + config.set("rust", "parallel-frontend-threads", "8")
> I'd suggest we don't hardcode a number, but rather set to oe.utils.cpu_count()
> (grep oe-core for examples).
I choose 8 here as there is no noticeable difference between 8/16. Also, the rust blog says (https://blog.rust-lang.org/2023/11/09/parallel-rustc/) -
/We recommend eight threads because this is the configuration we have
tested the most and it is known to give good results. Values lower than
eight will see smaller benefits, but are appropriate if your hardware
has fewer than eight cores. Values greater than eight will give
diminishing returns and may even give worse performance. /
Thanks,
Sundeep K
>
> Alex
[-- Attachment #2: Type: text/html, Size: 3179 bytes --]
next prev parent reply other threads:[~2026-03-12 13:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 4:07 [PATCH] rust: Enable parallel-frontend-threads sundeep.kokkonda
2026-03-12 9:02 ` [OE-core] " Alexander Kanavin
2026-03-12 12:13 ` Richard Purdie
2026-03-12 13:11 ` Sundeep KOKKONDA [this message]
2026-03-12 13:21 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a0c93d3-d8ce-4ee0-bb08-fbda7e5f1883@windriver.com \
--to=sundeep.kokkonda@windriver.com \
--cc=alex.kanavin@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=randy.macleod@windriver.com \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox