linux-openrisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: el 01 <quantumleo78@gmail.com>
Cc: Idzwan Nizam <idzwan.nizam@yahoo.com>, linux-openrisc@vger.kernel.org
Subject: Re: Performance improvements of Marocchino implementation
Date: Tue, 11 Mar 2025 22:17:09 +0000	[thread overview]
Message-ID: <Z9C2ZSpretIpZ2DL@antec> (raw)
In-Reply-To: <7084228c-23a1-45f9-bb58-8c85c1ae13f0@gmail.com>

Hi Idzwan,

I noticed you reached out on IRC, if you want to join OTFC/#openrisc
we could chat there too.  I am not around much there as it has been really quiet
recently but its also available.

On Tue, Mar 11, 2025 at 04:00:23PM -0400, el 01 wrote:
> I defer to Stafford's judgement, but please don't feel an obligation to
> continue exactly where I left off. If you want to work with FuseSoC only,
> that should be fine.

I thimk using fusesoc is a good option.  But ideally both fusesoc and litex
would both work.  I think whatever you are more familiar with is best.

-Stafford

> A bit of advice in advance -- I didn't write a script to batch run tests on
> FuseSoC. I instead ran each of the binaries individually by invoking
> ``fusesoc run``.
> 
> On 10/03/2025 06:09, Idzwan Nizam wrote:
> > Would it be OK and consider a progress if only FuseSoC were used?
> > 
> > On 10/3/2025 1:02 am, el 01 wrote:
> > > Hello,
> > > 
> > > Hopefully this makes its way onto the mailing list, my previous
> > > email didn't.
> > > 
> > > Stafford's previous email basically covered what I did last summer.
> > > I've been dealing with some health issues and haven't been able to
> > > consistently document my progress; really sorry about the lack of
> > > documentation.
> > > 
> > > I left off at trying to figure out some (perhaps superficial)
> > > differences between measured cycle counts when running a benchmark
> > > on LiteX and FuseSoC, two different 'build systems' for the HDL
> > > design. This doesn't directly address the discrepancy between
> > > marocchino and mor1kx, but was a step along the way.
> > > 
> > > The build systems bundle the OpenRISC core with some other necessary
> > > hardware (e.g. simulated memory, peripherals, etc.) and build either
> > > a binary for simulation on your computer, or something which can be
> > > put on an FPGA.
> > > 
> > > When running binaries from the Embench benchmarking suite on the
> > > same processor core / simulation engine (and only changing the build
> > > system), there are some tests which have substantially different
> > > cycle counts.
> > > 
> > > Some initial data I gathered will be attached, it seems like there
> > > are some substantial differences in the cycles required to execute
> > > some instructions on LiteX.
> > > 
> > > I'm also not 100% on whether the measured cycle counts are
> > > completely accurate, as the debug / trace parts of the LiteX and
> > > FuseSoC are somewhat different.
> > > 
> > > Another minor thing that I wanted to address was some inefficiency
> > > in running LiteX simulations. Because of the way that the Embench
> > > testing script for LiteX works (see
> > > https://github.com/hhe07/litex-esp/blob/ main/sim.py -- from what I
> > > remember this is stuff that you can copy into your Embench install
> > > folder to enable compatibility), I think the CPU and some of the
> > > supporting software is rebuilt every time a different benchmark is
> > > run, which wastes a lot of time.
> > > 
> > > As for where this fits into the larger issue of the performance
> > > discrepancy between mor1kx and marocchino, (in my opinion /
> > > experience) I spent a lot of time trying to figure out the tools and
> > > determining if what I wanted to do was a feature of a tool or
> > > something I needed to figure out. So, I'd recommend trying to
> > > understand the tooling and perhaps doing some practice tasks around
> > > it. YMMV, though.
> > > 
> > > I know I haven't really made this problem better due to poor
> > > documentation on my part, so please email if you're unsure about
> > > something that I did. I'll try to reply ASAP.
> > > 
> > > As for the attached files:
> > > - profile.ods includes analysis on cycle counts per instruction for
> > > one test, I think nettle_sha256. This is for the mor1kx CPU.
> > > - results.ods includes cycle counts for all Embench tests run on
> > > both FuseSoC and LiteX, and calculated percent differences between
> > > the two.
> > > - nettle-mor1kx-{fusesoc, litex}-trace-prof include the outputs of
> > > cycle counts from the analysis scripts I wrote (basically same as
> > > profile.ods), as well as some additional information on the PCs of
> > > the start/end of critical sections in the code, and how many cycles
> > > they took to execute.
> > > 
> > > 
> > > ~ Leo
> > > 
> > > On 02/03/2025 21:11, Idzwan Nizam Jamal Abdul Nasir wrote:
> > > > Hi,
> > > > 
> > > > I am interested in OpenRISC Benchmarking and Performance
> > > > improvements task listed as one of the project ideas in Google
> > > > Summer of Code. I am unable to participate in GSOC but I would
> > > > like to contribute to the task gradually as I acquire skills in
> > > > digital logic and computer architecture.
> > > > 
> > > > Is the task still open? I would be glad if you could point me to
> > > > the right direction such as documentation I should read or tools
> > > > I have to be familiar with. Any guidance is welcome and greatly
> > > > appreciated. Thank you.
> > > > 
> > 
> 
> 

      reply	other threads:[~2025-03-11 22:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <810295975.3514440.1740967866807.ref@mail.yahoo.com>
2025-03-03  2:11 ` Performance improvements of Marocchino implementation Idzwan Nizam Jamal Abdul Nasir
2025-03-06 15:38   ` Stafford Horne
     [not found]     ` <16047285.689010.1741349294786@mail.yahoo.com>
2025-03-07 16:07       ` Stafford Horne
2025-03-09 17:02   ` el 01
2025-03-10 10:09     ` Idzwan Nizam
2025-03-11 20:00       ` el 01
2025-03-11 22:17         ` Stafford Horne [this message]

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=Z9C2ZSpretIpZ2DL@antec \
    --to=shorne@gmail.com \
    --cc=idzwan.nizam@yahoo.com \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=quantumleo78@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).