Endrekursion müsste auch gut funktionieren. Aber dafür könnte man gleich eine reguläre Schleife nehmen.
Kommt halt darauf an, was der Compiler an optimiertem Code ausspuckt.
http://wiki.c2.com/?GotoConsideredHarmful hat auch eine kurze Zusammenfassung:
>Here's a good rule of thumb: don't use backward GoTo statements. Notice that continue, break, and mid-function return statements are all forward gotos (and switch is a computed forward goto). EwDijkstra's argument does not apply to them. I have noticed subjectively that they aren't confusing, unless you jump into something else (like the middle of a loop - see DuffsDevice). I don't think there's anything wrong with using goto to do, for example, a double break. Forward gotos are also useful for jumping to cleanup code after an error - they're often much more readable than doing your real work inside an if statement, and they're always more readable than doing your real work in a terraced landscape of nested if statements. (SyntaxMatters)
>Backward gotos could be ok when it makes sense that your error case would repeat the last iteration. I like to call it rare looping. A good example exists in beej's networking guide. http://beej.us/guide/bgnet/ See section 8. Why does select() keep falling out on a signal?
>>5423>https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables
Nett.
>I did some simple benchmarking with random opcodes and the goto version is 25% faster than the switch version. This, naturally, depends on the data and so the results can differ for real-world programs.
>Comments inside the CPython implementation note that using computed goto made the Python VM 15-20% faster, which is also consistent with other numbers I've seen mentioned online.
Wie praktisch.
>Think about it this way: for each jump, the branch predictor keeps a prediction of where it will jump next. If there's a jump per opcode, this is equivalent to predicting the second opcode in an opcode pair, which actually has some chance of success from time to time. On the other hand, if there's just a single jump, the prediction is shared between all opcodes and they keep stepping on each other's toes with each iteration.
Den Teil hab ich noch nicht ganz verstanden. (Dass es mit mehr als einem JMP besser zurechtkommt, schon.)
Muss ich noch ein wenig durchdenken:
https://danluu.com/branch-prediction/
https://developer.amd.com/resources/developer-guides-manuals/
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
https://www.agner.org/optimize/microarchitecture.pdf
>>5420Die implizite Betonung wäre auf SELBER schlecht in C nachbauen.
>>5423>Loop unrolling bzw. Duff's device
Im Prinzip ja. Hot loops und Really hot loops sind halt eine Klasse für sich.
Für optimale Leistung dann halt noch cache line alignment zurecht pfriemeln, wobei Compiler/Inline-Assembler teilweise sicher etwas an Unterstützung bieten.
Microsoft hatte oder hat glaub ich sogar ein Tool, welches die Executables nach Übersetzung & Linken optimiert, so dass wichtiger Code innerhalb einer 4K-Speicherseite liegt.