1. Relevance. Is the topic of the paper relevant to and important to the DaMoN community?

Yes

2. Writing. Is the paper readable and well organized?

Definitely - very clear

3. Novelty. Does the paper contain new insights relevant to the community? This can be lessons learned from new directions but also from revisiting past assumptions.

Mostly - the contributions are above the bar

4. Correctness. Are the paper's methodology, assumptions, models, and arguments free of serious flaws?

Yes - to the best of my understanding

5. Overall Rating. Papers with Reject or Strong Reject ratings should have at least one negative score on Q1-Q4.

Accept

6. Justification. Could you discuss the reason for your overall rating? Mention Strong Points (S1, S2, ...) and Opportunities of Improvement (O1, O2, ...)

S1. Relevant topic for the community. Documenting such differences between the CPU vendors is useful.
S2. The technical depth is solid for a short paper.
S3. The paper is well written and easy to read.

O1. The usefulness of the presented insights remains unclear.
O2. Some novel features of the processors are not discussed.
O3. The case-study could offer more guidance if the finer-granular reporting (AMD) is more insightful than the more consolidated one (Intel). Guide what perf should support.

7. Detailed Commments. Add detailed points of your review that help authors to improve their paper.

The paper is a very interesting read for any database system practitioner. Indeed, the difference in sampling techniques for memory-accesses between the two major vendors is big and understanding them is critical for our community. The DaMoN workshop is the right place to discuss some of these findings and to perhaps guide a discussion on what interface/abstraction should the next generation perf tools support/provide.

There are certain points that could be improved. For example:

D1. I am still not sure I understand what the practical insights from the experiment in Section 3 are. We get a better breakdown, but what can we do with it? Is there anything that we can optimize better for now that we know that AMD spends more time on tag-to-completion-to-retirement? Can we determine which information is useful as opposed to good-to-know but nothing to act upon?

D2. Modern processors are more heavily based on the chiplet-based architecture, where the latencies/bandwidth also within a processor are more heterogeneous than even. Also, new processors can be equipped with HBM or even DSAs. When discussing about what profiling information is useful for us (reporting, sampling, etc.) maybe including some of these things in the analysis would be even more practically useful.

D3. The paper makes initially the observation that perf as a tool does not necessarily capture the granularity of reporting that one could get from AMD processors. But, it fails to make a "closure" and suggest what could be a suitable interface (at least from a practitioner's perspective). Perhaps this is linked to the insights from D1 and how to "generalize" them.

8. Accept as Short Paper? If this is a full paper and it is rejected, would you support its acceptance as a short (2 page) paper?

Yes

1. Relevance. Is the topic of the paper relevant to and important to the DaMoN community?

Yes

2. Writing. Is the paper readable and well organized?

Mostly - the presentation has minor issues, but is acceptable

3. Novelty. Does the paper contain new insights relevant to the community? This can be lessons learned from new directions but also from revisiting past assumptions.

No - the contributions in this version do not warrant acceptance

4. Correctness. Are the paper's methodology, assumptions, models, and arguments free of serious flaws?

Yes - to the best of my understanding

5. Overall Rating. Papers with Reject or Strong Reject ratings should have at least one negative score on Q1-Q4.

Reject

6. Justification. Could you discuss the reason for your overall rating? Mention Strong Points (S1, S2, ...) and Opportunities of Improvement (O1, O2, ...)

The paper concisely describes and compares memory access performance counters on Intel and AMD CPUs.
While the example of a memory request is a helpful example to illustrate the provided performance counters, the following B-tree use case only provides limited insights.
As the paper states in its conclusion paragraph, the paper seems to provide a solid foundation for more insightful work in future.

7. Detailed Commments. Add detailed points of your review that help authors to improve their paper.

- The B-Tree is a good use case to show the relevance and importance of understanding performance counters and profiling information.
- The paper describes the provided performance counters but does not discuss more practical engineering implications. For example, it would be interesting to show how the provided profiling information can enable engineers to provide performance bottlenecks or optimization potentials in data structures.
- For example, the authors could analyze one or two commonly used implementations and show how a structured and detailed performance profiling can uncover hidden performance optimizations.
- The discussion of the shortcomings of the perf subsystem is short and could be more thorough. For example, is extending the perf subsystem to be more extensible and provide more counters easy? Or is it required to develop a new tool to overcome the shortcomings? What insights (i.e., performance bottlenecks, optimization potentials) would engineers miss due to the shortcomings of the perf subsystem?

8. Accept as Short Paper? If this is a full paper and it is rejected, would you support its acceptance as a short (2 page) paper?

Not applicable, this is a short (2 page) paper

1. Relevance. Is the topic of the paper relevant to and important to the DaMoN community?

Yes

2. Writing. Is the paper readable and well organized?

Mostly - the presentation has minor issues, but is acceptable

3. Novelty. Does the paper contain new insights relevant to the community? This can be lessons learned from new directions but also from revisiting past assumptions.

Mostly - the contributions are above the bar

4. Correctness. Are the paper's methodology, assumptions, models, and arguments free of serious flaws?

Mostly so - there are some minor issues, but none of them are fatal

5. Overall Rating. Papers with Reject or Strong Reject ratings should have at least one negative score on Q1-Q4.

Accept

6. Justification. Could you discuss the reason for your overall rating? Mention Strong Points (S1, S2, ...) and Opportunities of Improvement (O1, O2, ...)

S1. Timely topic - Performance Engineering becomes more important with the end of Moores low.
S2. Well-written and clearly presented.

O1. Lacks actionable insights.
O2. More details.

7. Detailed Commments. Add detailed points of your review that help authors to improve their paper.

O1. Lacks actionable insights.
I would like to see more directly actionable insights on how these insights help us.

O2. Provide more details, on methodology as well as provide the commands that are used to record the measurements.

8. Accept as Short Paper? If this is a full paper and it is rejected, would you support its acceptance as a short (2 page) paper?

Not applicable, this is a short (2 page) paper