Appel de fonction avec i + 1, ++ i différence d'implémentation?

Question

Juste un petit mot à propos de Java, et permettez-moi de le dire d'abord: je ne suis pas inquiet à cause de l'optimisation des performances, juste curieux de savoir sur les choses en coulisses en général. Depuis que je ne trouve rien à ce que je suppose qu'ils sont équivalents à tous égards, mais juste pour être sûr:

Dans une fonction récursive foo(int i), ou je suppose que dans generel dans un appel de fonction, est-il une différence entre foo(++i) et foo(i + 1)? Je sais que le résultat est le même, mais je pensais que celui avec ++i pourrait faire un extrawork en arrière-plan parce que c'est une tâche? Donc peut-être cela crée-t-il un (anonymous field) = i en arrière-plan qui est incrémenté puis référencé? Ou est-ce que le compilateur optimise simplement ++i à i + 1?

Ma compréhension est un peu floue comme vous le voyez, donc de l'aide serait appréciée.

EDIT pour clarifier:

Au début, cela était dû à une fonction récursive par exemple

public static int foo(int i) { 
     return (i >= 4) ? 0 
      : i + foo(++i); 
    } 

Les fonctions « en général » -part est venu en train d'écrire la question et, comme le remarque, rend cette ambiguïté, etc. Espérons que cela clarifie tout.

Answer 1

Si la réponse ne porte pas sur la sémantique mais sur les performances au niveau de la machine après que l'IR a été optimisé, traduit en instructions machine, je dirais, "non sauf si mesuré et prouvé autrement."

Il est très peu probable qu'il y aura une différence de performance après toutes les optimisations sont faites entre f(++i) et f(i+1), en supposant que votre code est telle que vous pouvez réellement considérer comme des solutions de rechange (en supposant l'état de i cesse de devenir pertinentes après la appel de fonction). C'est juste le matériel de base et la conception du compilateur, le coût des instructions pour la mémoire déjà stockées dans un registre, la simplicité d'optimiser ce code au même code machine même dans un compilateur semi-compétent (et je pense que Java JIT serait au moins cela). Il est très fondamental qu'un compilateur reconnaisse les effets secondaires inutiles et les élimine complètement (en fait, l'une des raisons pour lesquelles les tests de niveau micro peuvent être trompeurs, à moins qu'ils ne soient écrits très soigneusement de manière à empêcher l'optimiseur de sauter du code carrément). Parmi les effets secondaires les plus faciles à éliminer, il y a un cas comme celui-ci, où nous incrémentons une variable, i mais pas en fonction du changement d'état par la suite.

Il semble peu probable d'avoir un réel impact sur les performances. Bien sûr, l'ultime moyen est de regarder le code machine final résultant (pas le code IR du bytecode mais le code machine final réel) ou de le mesurer et de le profiler. Mais je serais assez choqué, pour dire le moins, si l'un est plus rapide que l'autre, et cela tendrait à me faire penser que le compilateur fait un mauvais travail dans la sélection d'instruction ou l'allocation de registre.

Cela dit, si l'on était en réalité (la chance à distance) plus vite que l'autre, je pense que vous l'avez en arrière. ++i nécessiterait probablement moins de travail car il peut simplement incrémenter une valeur dans un registre. ++i est une opération unaire sur un opérande, et cela fonctionne bien avec les registres qui sont mutables. i + 1 est une expression qui exige que i être traité comme immuable et demanderait un second registre (mais seulement dans une sorte vraiment horrible scénario du compilateur de jouets qui n'optimiser quoi que ce soit, bien que dans ce cas, nous compilez aussi cette expression dans le contexte d'un appel de fonction et doit considérer des choses comme des renversements de pile, ainsi même un compilateur de jouet pourrait les rendre quelque peu équivalents).

Answer 2

Si i est utilisé après foo(++i), la valeur aura été modifiée

Si vous traitez i après foo(i + 1), la valeur n'aura pas été modifiée

foo(int i) 
{ 
    //process stuff A 
    foo(i + 1); 
    //process stuff B 
} 

bar(int i) 
{ 
    //process stuff A 
    bar(i + 1); 
    //process stuff B 
} 

Selon ce qui est dans //process stuff B, vous peut soit vouloir utiliser i + 1 et avoir la valeur de i être le même, soit ++i et avoir i être incrémenté

Answer 3

Il n'y a pas de différence dans l'exécution de foo(++i) et foo(i + 1): la valeur du paramètre passée à foo est la même.

Cependant, dans le premier cas, la variable locale i est augmentée de un; dans ce dernier cas, il conserve sa valeur d'origine.

Donc, si vous faites la même méthode appel deux fois, il y a une différence:

foo(++i); 
foo(++i); // Invoke with i 1 greater than before. 

est différent de

foo(i + 1); 
foo(i + 1); // Invoke with the same argument 

En tant que tel, en général, le compilateur ne peut optimiser tout de suite, parce que ils ont une sémantique différente.

Answer 4

À côté des autres commentaires sur la valeur de i après avoir utilisé l'incrément de préfixe. Il y a une petite différence dans le bytecode généré. Voir ci-dessous les résultats simplifiés.

foo (++ i) compilé

iinc 
iload_1 
invokestatic 

foo (i + 1) Compilés à

iload_1            
iconst_1            
iadd             
invokestatic 

Answer 5

oui, ++ i se compose de deux opérations d'addition et assignment.Since, vous Je n'ai pas besoin de plus tard, i + 1 est préférable à utiliser plutôt que ++ i.