Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <jwvfrnvp23p.fsf-monnier+comp.arch@gnu.org>
Deutsch   English   Français   Italiano  
<jwvfrnvp23p.fsf-monnier+comp.arch@gnu.org>

View for Bookmarking (what is this?)
Look up another Usenet article 
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: Reverse engineering of Intel branch predictors
Date: Wed, 13 Nov 2024 10:53:08 -0500
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <jwvfrnvp23p.fsf-monnier+comp.arch@gnu.org>
References: <vfbfn0$256vo$1@dont-email.me>
	<c517f562a19a0db2f3d945a1c56ee2e6@www.novabbs.org>
	<jwv1q002k2s.fsf-monnier+comp.arch@gnu.org>
	<a3d81b5c64ce058ad21f42a8081162cd@www.novabbs.org>
	<jwvcyj1sefl.fsf-monnier+comp.arch@gnu.org>
	<abef7481ff0dd5d832cef0b9d3ea087a@www.novabbs.org>
	<jwv1pzhsahr.fsf-monnier+comp.arch@gnu.org>
	<8928500a87002966d6282465c037003e@www.novabbs.org>
	<jwvpln0qpel.fsf-monnier+comp.arch@gnu.org>
	<18bfd4ce1048f68ad4d39d972c459e99@www.novabbs.org>
	<jwv7c98qell.fsf-monnier+comp.arch@gnu.org>
	<vh1i5u$235kt$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 13 Nov 2024 16:53:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="178f45f210aaccfbca18a8627294f3a4";
	logging-data="2391998"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Suegzz2HILpx32n7rRtB4nZREAhQUFoQ="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:vD0b440erzzYWu9/LsL3AKwVALs=
	sha1:DMKaEXDNpMW4H4Q36zaygavjboU=
Bytes: 2670

>>>> I guess for small jump table that would work well, indeed, but for
>>>> something like a bytecode interpreter, even if you can compact it to
>>>> have only 16bit per entry, that still spans 512B.  Is your IB large
>>>> enough for that?
>>> For something like a bytecode interpreter, the prediction accuracy
>>> of the jump predictor is going to be epically bad.
>> Current Intel processors do a surprisingly good job of it.
> I'm guessing this is the branch pattern recognizer at work, i.e some
> sequences of bytecode ops are much more common than a simple random walk
> through the opcodes, and those sequences make it possible to predict the
> next bytecode jump to be performed?

Yes.  If you consider the two levels of language at play (the CPU view
at the level of machine language and the interpreter's view of the
bytecode language), IIUC the branch history of the CPU view ends up
being a usable approximation of the bytecode-level instruction pointer,
so for those sections of your bytecode-level program which are sufficiently
repetitive, the prediction applied by the CPU can correctly predict the
next bytecode.


        Stefan