Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Stefan Monnier 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: References: <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at> 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