darchr / gem5-20-paper Goto Github PK

The following is a comprehensive list:

https://www.arm.com/company/policies/trademarks/arm-trademark-list

As far as I can see from a first look we should be adding trademark symbols for the first occurrence of

• Arm
• TrustZone

As far as I can tell, the only explanation of the spectrum of gem5's uses, is this phrase in section 1.3: "Currently, the most common use case for gem5 is in computer architecture research." In my view this is too narrow (if this is the only place where we talk about uses). My own use of gem5 is, as a virtual platform for JIT compiler research. (Because with a JIT compiler we are dealing with self-modifying code, traditional debuggers can't cope with JIT scenarios and JIT development is severely impeded by debugging technology; this is where gem5 fits ideally. I wrote an ACM SIGPLAN paper about this (Shingarov, "Live Introspection of Target-Agnostic JIT in Simulation") and talked about it at the ARM Summit in 2017). The thing is, while I don't have hard data, I would guess I am far from being the only one who uses gem5 for things other than traditional architecture research. But how do we know? Shall we poll? Shall we have a section "Uses" in the paper dedicated to the growth of diversity of usage? This "2020" paper seems to be about growth and when talking about inventions a most interesting indicator is, use for things the inventor did not think of.

To me the paper ends somewhat abruptly. It might be the lack of a conclusions section, but I also wonder whether it would be better to talk about the future of gem5 at the end, after describing all the current features of the tool. That way I feel there will be more of a narrative - you've told me about all the great things to do with gem5 now, what's happening next?

Arm and ARM are used inconsistently throughout the document. We should unify this and prefer the use of "Arm"

There are several parts where ARM could be easily changed to Arm, but in some scenarios it might be confusing since the gem5-ISA is still using the old capitalized name.

A solution could be to use:

• Arm -> when mentioning the company or the Arch extensions (Armv8.x)
• ARM -> when mentioning the gem5 implementation of the architecture

Any feedback is welcomed (feel free to post it on the issue)

The description about the new 3-level ruby protocol seems vague to me. Is this the MESI_THREE_LEVEL protocol?

At level 0, the protocol has separate caches for instruction and data.

Shouldn't it be instructions instead? The singular is OK when using the expression instruction cache, but in this case the plural is probably more correct.

The first and the second levels do not distinguish between instruction and data.

Same as before.

Levels 0 and 1 are private to the CPU core, which the second level is shared across (possibly a subset) cores

Was the word which mistakenly used instead of while?

By the way, to make it easier to read I would maybe merge the second sentence with the first one. I would also move the expression possibly a subset at the end of the third sentence, like:

Levels 0 and 1 are private to each CPU core while the second level is shared across cores, all of them or possibly a subset.

"with a goal to provide a tool to further the state of the art in computer architecture. �The goal of gem5 is to provide a tool to further the state of the art in computer architecture"

Delete the second sentence?

Push the second paragraph to the end of section 2.11.
Gather the first and third paragraphs since they are related to replacement policies. The second one is related to compression mechanisms.

This may be minor thing, but by default x86 does not enable MinorCPU, but the user can modify the building script to enable that, but last time I tried this there are still some problems of branch prediction in MinorCPU when using x86. But overall I feel it is reasonable to say any ISA can be used with any CPUs.

"read and wrote memory atomically" -> "read and write memory atomically"

I feel this section is a little abstract and not that closely related to gem5. It would be great if it can cover more about the implementation in gem5 and what new research questions it empowers gem5 to explore?

Page 3 - Line 21: "we are excited to to" -> "we are excited to"
Page 4 - Line 16: "execution or memory" -> "execution or memory requests"
Page 4 - Line 26: Mention simple network?
Page 5 - Line 2: Reference for fake graphics GPU

Formatting issues in the Bibliography (some issues appear only in the arXiv version of the paper, i.e. the ones that have to do with special characters):

• - Some references use abbreviated author names (e.g. "[46] S. Li, Z. Yang, ...") and other use long names (e.g. "[45] Sheng Li, Jung Ho Ahn, Richard D. Strong, ..."). We should be consistent (and always use long names).
• - Some references incorporate a link to the DOI and some others don't.
• - Conference names sometimes are abbreviated, sometimes show long name, and sometimes show long name together with the acronym.
• - Conference location sometimes is mentioned and sometimes it isn't.
• - Attention in [13]: "ArmÂő Architecture" (check pdf in arXiv)
• - In [18], only "Parallel" uses a capital P (should be "International Conference on Parallel Architectures and Compilation Techniques")
• - In [28], "International Conference on" should go before the conference name.
• - In [29], attention with weird characters: "(ISCA âĂŹ19)" and "169âĂŞ182" (check pdf in arXiv)
• - In [39], attention with weird characters: "(ISCA âĂŹ10)" and "60âĂŞ71" (check pdf in arXiv)
• - In [41], attention with "191âĂŞ201" (check pdf in arXiv)
• - IEEE Comput. Archit. Lett. (in [42, 59]) VS IEEE Computer Architure Letters (in [9, 46, 62)
• - In [49], attention "ISCAâĂŹ03" and "182âĂŞ193" (check pdf in arXiv)
• - In [72], "International Symposium on" should go before the conference name.
• - In [73], attention with "100âĂŞ107" (check pdf in arXiv)
• - In [74], attention with "Krste AsanoviÄĞ" (check pdf in arXiv)

In Fig1 a and b, we see the drop in 16-17 before the new efforts are made, and how the situation significantly improved after that. Do we want to emphasize on that, and how important it is to maintain the same approach?

I think it would be better to avoid the word "fake" when describing a functional/behavioral model.

My suggestion is to replace "a fake graphics GPU" with "a functional graphics-only GPU model".

1. Can we show the citation distribution of gem5 paper over time in Figure 1? I am wondering the trend. Showing this may be helpful to stress the acceleration described in the section.

2. Page 3 - Line 5.
   I think the flow from the first paragraph to the second paragraph is not that smooth. I am not sure what "these problems" mean.

3. Page 2 - Line 16
   Gem5 -> The Gem5 community?

"the architecture of the built on a core" -> "the architecture was built on a core"

Hi Jason,

Just noticed that this commit (7e4f832#diff-41cd4cabd0f3cb6d6f90a3fdd6ba55f1) around "Update order, etc. Remove empty sections" in "changes/predictor-improvements.tex" has erroneously removed the branch predictor section from the final draft. Looks like you might have erroneously commented out the inclusion of \input{changes/predictor-improvements}.

Please take a look into that. Thanks.

page 1, line 29.

There is no caption for figure 3.

Just so we can keep track of this.

Most section titles use capital letters in the first letter of all nouns (2.4 "Arm Improvements" or 2.6 "Branch Predictor Improvements"), but some others don't (1.1 "The past, present, and future of gem5" until Section 2.2). We should have a consistent format for section titles.

Figures formatting

• Increase a bit font size in Figure 1 (especially "through May")
• Figure 2 should be placed in the previous page (page 4).
• Increase a bit font size in Figure 5

Others minor issues:

• Attention: In Section 2, you mention "There were 7015 commits", but earlier in the paper you mention multiple times "over 7500 commits".
• "VExpress_GEM5_Base" goes over the column limit.
• ARM should be replaced with Arm in multiple places in the text (most of the times we already use Arm).
• QEMU VS qemu -> use alwasy QEMU
• When describing new features in Section 2, we normally use past tense, but there are some sections that use present tense ().
• - "Today, Ruby shares the same replacement protocols (Section 2.11), the same port system to send requests into and out of the cache system, and the same flexible DRAM controller models (Section 2.9)." --> I believe we should say "Today, Ruby shares with classic cache models..."
• - "MESI_Three_Level" goes over the column limit.
• - "MOESI_CMP_directory" goes over the column limit.
• - In Section 2.12.2: load-locked/store-conditional (LL/SC) -> load-linked/store-conditional (LL/SC) according to Arm's terminology.
• - In 2.19: "S- mode" -> "SE-mode"
• - In 2.19: there are two lists of items that use "(1)", "(2)" and "(3)". Before you were using latin numbers for these lists.
• - hw model -> hardware model
• - we've -> we have
• - In the ACKs, Chris AJ appears twice ("Chris Adeniyi-Jones, Chris Adeniyi-Jones")

Currently, the paper lists major improvements of gem5 in Section 2.
I like recently added Figure 2, which describes the overview of gem5.
Could we provide a similar one for Section 2?
Why don't we start the section with a table or some paragraphs that summarize the major improvements? That would be helpful for readers to get what advances in gem5 are in a glance.

The section looks good to me. I have a few minor comments below.

Page 4 - line 22
“Figure 2 The gem5 project also contains tes….”

A dot is required to finish the sentence after "Figure 2."

Page 4 - line 30
“... simulator contains “simple” CPU models which are single-cycle models that can be used for memory system studies or ...“

What do you think about “functional CPU models which do not model pipeline stages” or “single-stage pipeline models”?

Page 4 - line 35
“... Although the KVM CPU model can execute at native speed, it does not model the timing of execution or memory requests. ...”

Adding example use cases of KVM would be helpful. For example, creating a checkpoint by passing unimportant execution points?

"The IEEE standard SystemC API has also been integrated with gem5 to enable users with SystemC models to use them as gem5 components."

This description seems more like "SystemC within gem5" rather than "gem5 within SystemC" to me. However, I have heard that the SystemC implementation in gem5 is not designed to be completely compatible with the standard SystemC implementation, which means that one cannot run prebuilt SystemC modules as gem5 components directly.

Just wondering, who is looking into section 2.9 predictor improvements portion? Is branch predictor improvements going to be a part of it? I got request for including my MICRO2014 branch predictor code into gem5 several times. Portion of this code already exists online as part of championship branch predictor (isca 2014) contest. Who is working on populating section 2.9?

This subsection seems to describe the general definition of QoS and does not deal with what gem5 provides on QoS extensions.
I think this section needs to explain what and how gem5 provides QoS extensions.

Section 2 has a lot of material, which is great.

However, to get a quick grasp of all the new features/improvements it might be worth considering adding a table at the beginning of section 2 with the list of subsections. If the table is split in 2 columns it would take about 10 lines.

The table can serve multiple purposes.

• Could be used to introduce the section with a bit more context
• Can help the reader navigate the paper
• Could be used to include additional content that refers to each subsection

Just a suggestion.

"Learning gem5" is set in italics in some cases. To make it clear that "Learning gem5" is a single object, why don't we italicize all of them?

The gem5 simulator has been wildly successful since its initial release nine years ago.

The list of contributors for the SVE improvement is (in alphabetical order)

Gabor Dozsa
Giacomo Gabrielli
Rekai Gonzalez-Alberquilla
Nathanael Premillieu
Javier Setoain

I have been included in the author list for SVE (together with Giacomo Gabrielli and Javier Setoain) though I haven't really contributed a lot to that specific feature. I think I should be excluded from that paragraph and the people mentioned above should be added instead

when gem5 is the first word of a sentence, it is still not capitalized.

maybe replace with 'The gem5 simulator' ?

or maybe I am too pedantic.

Back when I submitted patches to integrate RISC-V test suite into gem5, it only supported syscall emulation. Not sure if that has changed since then, but as far as I know FS for RISC-V is not yet supported? If that's correct, I would like the sentence about RISC-V test suite to be moved into section 2.8.1 (general RISC-V ISA implementation).

Section 1.2 explains the integration of gem5 with the System Simulation Toolkit (SST).
Does it mean this simulation framework (http://sst-simulator.org/)?
In that case, SST means Structural Simulation Toolkit.
As I am not an expert on SST, I might be wrong.

Thanks