I heard jmp and jr knocks down CPU conveyor

Good do one jr or jmp.
Bad method do more then one jmp\jnz\jz\jae\jbe

That all depends on CPU brand/generation that you work with. When you write something that is going to work on a wide range of hardware, my usual suggestion is to optimize primarily for size and simplicity.

Study the BTB (Branch Target/Tag Buffer) it's how the processor predicts where to go next. Multiple Jcc close together can be a performance problem - as far as I can remember JMP has no penalty 100% predicted obviously.

Forget about trying to predict what the BTB predictor will do. Really! It's a fools game to go down that path. It might give you a vague idea about things, but not much more. With over 100 instructions in flight at any one time inside the CPU there is just too much happening to predict any of this statically by simply looking at the code by eye and counting clock cycles or something. Hehe, well unless you are still using an old P3 system, then maybe you can get away with it there.

Test your code to see what happens when it runs for real. No need to guess, when you can know for sure by running it and seeing what happens.

It was more about branch locality than trying to predict the processor. There are a limited number of bits to indicate where the Jcc instruction is. If there are too many branches in a small region of memory this can artificially slow things down.

All this is very academic at the extreme edge of optimization.

As a concrete example, assume we want to execute some function, but only if a file/folder exists: ...this is a rather common pattern in Windows.

I read https://www.agner.org/optimize/instruction_tables.pdf
Call far take 16-22 CPU cycles (for modern CPU its about 16 nanoseconds)
JMP far take 16-20 CPU cycles

Jcc take 1-2 CPU cycles

Question in Fasm 64 bit invoke do far Call ?

64-bit x86 code doesn't support far calls. The segment registers are not used.

Actually aren't far calls used to switch between 32-bit and 64-bit code?

so does far jmps.