> but they make up a fairly small fraction of the total instructions in a typical

but if their cost increases by a large factor... besides, in any large compiled program, the core would certainly be based around some kind of programmable pipeline, and these would generally be implemented like this unless they wrote their own JIT compiler.

Yes - but for their cost to increase by such a large factor, the only obvious thing I can think of is that their prediction is disabled.

I didn't follow your comment about a "programmable pipeline". I don't think many or any of the Phoronix benchmarks are based on a pipeline with indirect branches at their core.

> I don't think many or any of the Phoronix benchmarks are based on a pipeline with indirect branches at their core.

I think a bunch are. e.g. for instance FFMPEG / libavfilter which is basically a node graph set up at runtime. Don't know for cinebench since it's closed source, but Blender present in the benchmarks is also based around a nodal rendering architecture. Stuff like PHP / CGI also heavily depend on function pointers for their behaviours - PHP with its plugin architecture, and CGI where all web requests go through FPs : https://github.com/php/php-src/blob/master/main/fastcgi.c#L8....

Right, I think I understand what you are saying about "pipelined" implementations. Sure, I can believe that at a high level there are some indirect branches to implement some kind of processing pipeline: but you'd have thousands or millions of instructions doing the heavy lifting for each chunk of data that passes though the pipeline, for every branch that you need to take to get to the next stage.

So I still doubt that that indirect branches are "dense" in those benchmarks: it just doesn't make sense since the core work they are doing are highly tuned encode/decode/whatever kernels, even if there is a control layer over top of that using indirect branches.