Sujet : Re: Top 10 most common hard skills listed on resumes...
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 28. Aug 2024, 13:25:05
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <van4v1$3fgjj$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 28/08/2024 12:49, Michael S wrote:
On Wed, 28 Aug 2024 11:26:03 +0200
David Brown <david.brown@hesbynett.no> wrote:
>
(I am not even sure why you thought branch prediction was relevant
here.)
>
>
It is relevant.
Sophisticated branch prediction + BTBs + deep speculation working
together is a main reason for very good common-case performance of
virtual function calls on "big" CPUs.
Well, yes. But branch prediction on its own is not sufficient - it is not even the major part of the reason. Without speculative execution to at least some extent, a cpu is not going to be able to see into the virtual method table pointer, or the virtual method pointer itself, in order to pre-fetch the instructions of the virtual method. A non-virtual method is just a "call" instruction that relatively simple pre-fetching can handle.
It is speculative execution, along with register renaming (so that the register moves typically found around function calls are "executed" in zero clock cycles), that greatly speed up virtual method calls. Smarter instruction caches, and return stack caches are also more relevant than branch prediction here. (Branch prediction is of course useful for other things.)
And while microcontrollers sometimes have a limited form of branch prediction (such as prefetching the target from cache), the more numerous and smaller devices don't even have instruction caches. Certainly none of them have register renaming or speculative execution.
Modern x86 processors are highly tuned to give fast execution of inefficient code - which is great for code with lots of indirection such as from virtual methods, as well as older code and poorly optimised code. Microcontroller processors are a different world there. So writing code that is efficient on a small microcontroller is very different from writing code for big processors - even though C++ (as well as C) can be an appropriate choice of language in both cases.
(I know /you/ know all this, but Bonita is clearly clueless about it.)