Link to results drive folder

[Jennifer Hellar]

Hi all,

 

Here is the link to the Drive folder with my results so far and some other documentation/figures/etc. (see the README).

 

https://drive.proton.me/urls/503GADCXJM#OtYw1dINdlpP

 

I will take a look at the other OpenHW core with bitmanip support next week, hopefully.

 

Best,

 

Jennifer

 

 

Cirrus Logic | Jennife...@cirrus.com | +1 512.851.4095

[Jennifer Hellar]

Hi all,

 

You may have already seen the new files, but I did upload results for the OpenHW core with bitmanip support.  Note that it doesn’t have floating-point, so I’m still unable to generate data for F or D with bitmanip.  Currently, I have the following architectures:

 

• RV32I
• RV32IM
• RV32IMC
• RV32IMFC
• RV32IMC_Zba_Zbb_Zbc

 

Is this sufficient @David Patterson?  If not, does anyone know of a platform we could run bitmanip with F and/or D extensions?

 

Best,

Jennifer

 

From: 'Jennifer Hellar' via Embench <emb...@lists.librecores.org>
Date: Friday, October 20, 2023 at 9:27 AM
To: emb...@lists.librecores.org <emb...@lists.librecores.org>
Cc: David Patterson <davidpa...@google.com>, jeremy....@embecosm.com <jeremy....@embecosm.com>, paolo....@embecosm.com <paolo....@embecosm.com>
Subject: [embench] Link to results drive folder

Hi all, Here is the link to the Drive folder with my results so far and some other documentation/figures/etc. (see the README). https: //drive. proton. me/urls/503GADCXJM#OtYw1dINdlpP I will take a look at the other OpenHW core with bitmanip support

ZjQcmQRYFpfptBannerStart

This Message is from an Untrusted Sender You have not previously corresponded with this sender.     Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

--
You received this message because you are subscribed to the Google Groups "Embench" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embench+u...@lists.librecores.org.
To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/BN6PR19MB0098E256B73431FF2B581C5A9EDBA%40BN6PR19MB0098.namprd19.prod.outlook.com.

[David Harris]

Jennifer,

Here were some results we got on CORE-V Wally a few months ago including Zb*, F, and D.  I can dust this off and work with you if it’s helpful.

David

march	rv32i_zicsr	rv32im_zicsr	rv32imc_zicsr	rv32imc_zba_zbb_zbc_zbs _zicsr	rv32gc or imafdc_zba_zbb_zbc_zbs_zicsr
aha-mont64	1.53	1.37	0.95	0.95	0.95
crc32	1.23	1.15	0.75	0.74	0.74
cubic	2.54	2.54	1.46	1.46	1.31
edn	1.71	1.45	1.05	1.03	1.03
huffbench	2.02	2.02	1.37	1.34	1.34
matmult-int	1.25	1.13	0.85	0.85	0.85
md5sum
minver	1.36	1.34	0.89	0.87	0.75
nbody	1.38	1.38	0.86	0.85	0.56
nettle-aes	1.64	1.63	1.25	1.21	1.21
nettle-sha256	1.93	1.93	1.63	1.16	1.16
nsichneu	1.60	1.60	1.35	1.35	1.35
picojpeg	1.54	1.47	1.15	1.12	1.12
primecount
qrduino	1.41	1.33	1.02	1.01	1.01
sglib-combined	1.51	1.48	1.01	1.00	1.00
slre	1.47	1.47	1.08	1.07	1.07
st	1.41	1.38	0.84	0.82	0.60
statemate	0.95	0.95	0.82	0.82	0.82
tarfind
ud	1.52	1.36	0.97	0.94	0.91
wikisort	1.43	1.41	0.95	0.94	0.93
Geometric mean	1.52	1.46	1.04	1.01	0.93

 

Table 21.5 Speed (speedopt_speed with -O2)

march	rv32i_zicsr	rv32im_zicsr	rv32imc_zicsr	rv32imc_zba_zbb_zbc_zbs _zicsr	rv32gc
aha-mont64	0.37	0.87	0.85	0.85	0.85
crc32	0.68	1.00	0.96	1.05	1.10
cubic	0.13	0.44	0.45	0.44	0.55
edn	0.05	1.06	1.03	1.04	1.06
huffbench	1.57	1.57	1.54	1.63	1.69
matmult-int	0.12	1.10	1.09	1.09	1.10
md5sum
minver	0.29	0.74	0.73	0.74	7.04
nbody	0.19	0.81	0.80	0.80	1615.65
nettle-aes	0.84	0.90	0.87	1.08	1.08
nettle-sha256	0.96	0.96	0.94	1.31	1.30
nsichneu	0.64	0.64	0.81	0.81	0.81
picojpeg	0.84	0.96	0.94	0.99	1.00
primecount
qrduino	0.81	1.39	1.35	1.42	1.40
sglib-combined	1.27	1.34	1.30	1.36	1.36
slre	1.46	1.46	1.42	1.42	1.40
st	0.23	0.95	0.96	0.96	34.51
statemate	2.19	2.19	2.12	2.12	2.15
tarfind
ud	0.60	1.11	1.05	1.05	1.68
wikisort	0.81	1.94	1.96	1.96	4.23
Geometric mean	0.51	1.05	1.05	1.10	2.41

 

Jennifer

 

 

<image001.png>

-- 
You received this message because you are subscribed to the Google Groups "Embench" group.
To unsubscribe from this group and stop receiving emails from it, send an email toembench+u...@lists.librecores.org.
To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/BN6PR19MB0098E256B73431FF2B581C5A9EDBA%40BN6PR19MB0098.namprd19.prod.outlook.com.

-- 
You received this message because you are subscribed to the Google Groups "Embench" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embench+u...@lists.librecores.org.

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/BN6PR19MB00981C550F2F7941A705B2059EAAA%40BN6PR19MB0098.namprd19.prod.outlook.com.

[Ray Simar]

Thanks Jennifer for the latest update!  And many thanks to David (the Harris one, not the Patterson one) for contributing.  Your help David is always very welcome.

I’ve been recovering from a bout of Covid so have been slow on the response time.  That said, I’m looking forward to digging into the numbers!

All the best,

Ray

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/8E92C317-3F6D-4802-BD4B-56B3F3838E00%40g.hmc.edu.

[Jennifer Hellar]

Hi David (Harris),

 

Thanks for the tip!  I had looked at Wally a while ago, but wasn’t sure if we wanted to collect data for the paper on a core that big (5-stage application-class).  The Arm comparisons are done vs the M4 which wouldn’t really be comparable to Wally.  But thinking about it more, maybe it doesn’t matter for this set of experiments (showing trade-offs of the different RISC-V extensions) since we’re only comparing RISC-V to RISC-V.  Thoughts,  @David Patterson?  Are you fine with having these experiments on a different size core?

 

Get well soon, @Ray Simar!

 

Jennifer

 

From: Ray Simar <ray....@rice.edu>
Date: Wednesday, November 8, 2023 at 9:47 AM
To: David Harris <har...@g.hmc.edu>, Jennifer Hellar <Jennife...@cirrus.com>
Cc: emb...@lists.librecores.org <emb...@lists.librecores.org>, David Patterson <davidpa...@google.com>, jeremy....@embecosm.com <jeremy....@embecosm.com>, paolo....@embecosm.com <paolo....@embecosm.com>
Subject: Re: [embench] Link to results drive folder

Thanks Jennifer for the latest update! And many thanks to David (the Harris one, not the Patterson one) for contributing. Your help David is always very welcome. I’ve been recovering from a bout of Covid so have been slow on the response time. 

ZjQcmQRYFpfptBannerStart

This Message is from an External Sender     Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

[Ray Simar]

Hi Jennifer,

These are some great thoughts on the topic and I think you are on to something…

If we can run these with essentially a flat memory (removing cache effects) then the results should be quite comparable.  I recall David H’s early work on this and don’t recall any obstacles to this approach.  How about we give this a try and see what pops out?

If we use the results we can, of course, point out what platforms we used in David P’s paper.  This has the side benefit of highlighting the growth of the RISC-V community with David H’s team work on Wally.

Any thoughts David P?

All the best,

Ray

PS: On my current status - on steroids now, voice (which I have lost) is beginning to come back.  We’ll get there!

Ray

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/8E92C317-3F6D-4802-BD4B-56B3F3838E00%40g.hmc.edu.

[David Harris]

Wally can be configured with tightly integrated instruction and data memories instead of a cache.  That won’t matter much because the benchmarks are small enough to fit in the caches. It has a gshare branch predictor, that probably should be kept on. The privileged portion doesn’t matter for Embench tests; it could be turned off, but won’t affect benchmark scores.  

If there’s interest, I’ll repeat the experiments without caches, but I don’t expect much change.

The big effects are that nbody, minver, and st see enormous speedups from floating-point, and some of the other benchmarks see modest speedup.  See the table below.

David

[Ray Simar]

Hi David,

Thanks for the information!  If no one sees an issue, how about we have David H repeat the experiments without caches?

Like him, I don’t expect much change.  But that’s why we do the experiment. :)

All the best,

Ray

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/B51F8296-CE3B-4D0E-B242-F58E54E2804F%40g.hmc.edu.

[Roger Shepherd]

David,

For me, Ray has this on the nose (does make sense to Americans?), this is scientific method - observe the data, build a hypothesis, maker a prediction, TEST IT. Please do this.

Roger

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/B68C94DD-C9F8-4C12-B7DC-23A55F912CE3%40rice.edu.

Roger Shepherd

roger.s...@chipless.eu

[Roger Shepherd]

Jennifer,

Speaking as someone who has spent decades developing computer architectures I really welcome these experiments. In my experience, the lack of hard (defined, documented, reproducible) data about performance has been a huge problem in understanding the engineering of computer systems. And the problems in obtaining such data are wide - technical and commercial. I think that for a group trying to provide benchmarks the type of raw data you are producing is very valuable. Now, it may or may not be useful for David P’s paper (I can’t speak to that) but I think for the group it is very useful. My question would be how to make use of the data.

Roger

Ray

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/8E92C317-3F6D-4802-BD4B-56B3F3838E00%40g.hmc.edu.

 

-- 
You received this message because you are subscribed to the Google Groups "Embench" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embench+u...@lists.librecores.org.

To view this discussion on the web visit https://groups.google.com/a/lists.librecores.org/d/msgid/embench/BN6PR19MB0098FE75B7ACB7A265B3B77F9EAFA%40BN6PR19MB0098.namprd19.prod.outlook.com.

Roger Shepherd

roger.s...@chipless.eu