Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Performance monitoring
Date: Tue, 1 Oct 2024 18:50:51 +0000
Organization: Rocksolid Light
Message-ID: <1d6677bed47863fb37485efdf6425e43@www.novabbs.org>
References: <2024Mar25.193535@mips.complang.tuwien.ac.at> <memo.20240325202221.1408H@jgd.cix.co.uk> <PolMN.100748$_a1e.89032@fx16.iad> <2024Mar26.102754@mips.complang.tuwien.ac.at> <hMAMN.122731$SyNd.31862@fx33.iad> <2024Mar26.174702@mips.complang.tuwien.ac.at> <0d50af01e9217c15ecb945e0b643b597@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="140012"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$psGBXP0xUrbqt50/NnnXYuSEDN/3hyQwc3m2pddOaETZ0xzKV4rPK
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3080
Lines: 46

On Tue, 26 Mar 2024 18:47:38 +0000, MitchAlsup1 wrote:

> Anton Ertl wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>The biggest demand is from the OS vendors.    Hardware folks have
>>>>>simulation and emulators.
>>>>
>>>>You don't want to use a full-blown microarchitectural emulator for a
>>>>long-running program.
>>>
>>>Generally hardware folks don't run 'long-running programs' when
>>>analyzing performance, they use the emulator for determining latencies,
>>>bandwidths and efficiacy of cache coherency algorithms and
>>>cache prefetchers.
>>>
>>>Their target is not application analysis.
>
>> This sounds like hardware folks that are only concerned with
>> memory-bound programs.
>
>> I OTOH expect that designers of out-of-order (and in-order) cores
>> analyse the performance of various programs to find out where the
>> bottlenecks of their microarchitectures are in benchmarks and
>> applications that people look at to determine which CPU to buy.

That is the job of the architects, the designers are more concerned
with their (myriad of) sequencers and how they interact with each other.

>                                                                 And
>> that's why we not only just have PMCs for memory accesses, but also
>> for branch prediction accuracy, functional unit utilization, scheduler
>> utilization, etc.
>
> Quit being so CPU-centric.
>
> You also need measurement on how many of which transactions few across
> the bus, DRAM use analysis, and PCIe usage to fully tune the system.

Every block big enough to have a unique name (i.e., dram CONTROLLER)
should have its own set pf PMCs. In general, sequencers are too small
for their own PMCs. {{the PMCs would be larger than the sequencers
they measure.}}
>
>> - anton