Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: WCET analysis (was: Privilege Levels Below User)
Date: Tue, 11 Jun 2024 17:14:15 -0400
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <jwvsexjfasn.fsf-monnier+comp.arch@gnu.org>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com>
	<h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com>
	<2024Jun9.185245@mips.complang.tuwien.ac.at>
	<38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com>
	<2024Jun10.091648@mips.complang.tuwien.ac.at>
	<o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com>
	<lcq749F7sotU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 11 Jun 2024 23:14:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="adecb8f45b089a8dec176645b14c32be";
	logging-data="1314219"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/3WXWajRfSE9O6PgyN8mWoKgJWAM4Wi5k="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:EPSp+rQeSCekrsIoUfeKFYdONZ0=
	sha1:vQMEaXdqPXDuIFAHEZaOUXbN9n0=
Bytes: 2122

> Not always. If the mistakenly speculated cache-fetch /evicted/ some other
> data from the (finite-sized) cache, and the evicted data are needed later on
> the /true/ execution path, the mistakenly speculated fetch has a /negative/
> effect on performance. (This kind of "timing anomaly" is very bothersome in
> static WCET analysis.)

BTW, I heard that nowadays "static WCET analysis" is typically based on
statistical models of the performance of various parts of the code.
So they don't give an ironclad worst case any more (contrary to what
you'd get back in the day where you could count cycles and there were no
caches), but rather one that is "very unlikely" to be wrong.

I remember papers doing "real WCET" by analyzing the code to detect
those memory accesses which were guaranteed to be cache hits.  Do you
know if this is still done nowadays?


        Stefan