SpriteKit, mettre un processus sur un autre cœur ?

Question

Imaginez dans votre

 class NattyScene: SKScene {

vous avez peut-être un champ personnalisé pour les nœuds, ou quelque chose d'autre qui se produit à chaque image. Imaginez maintenant que vous ayez un calcul à faire, par exemple le centre de gravité...

var globalCOG: CGPoint
func updateCOG() {
   .. say, get all the .position of all Spaceship ..
   globalCOG = .. some point
}

Il serait tout à fait judicieux d'en parler dans un autre fil, en supposant que des questions comme celles qui suivent soient abordées.

• la lecture des .positions est rapide et sans risque pour les threads
• cet autre thread putatif sur un autre noyau, connaît les frames SpriteKit (de sorte que vous pouvez calculer jusqu'au temps d'abandon de la manière habituelle, etc, peut-être préférez-vous sauter une frame ou autre - la panoplie habituelle de la programmation de jeux threadés)
• vous pouvez écrire en threadsafe/blahblah le global COG vers le reste de SpriteKit

Qu'en est-il ?

• Quel est l'idiome moderne pour cela dans Swift4 / SpriteKit ?
• Comment l'obliger à passer à un autre noyau physique entier ?

Des idées ?

---

override func update(_ currentTime: TimeInterval) {

    let x = safely get info from a thread on another physical core on the device
    print("now that's cool")
}

sur l'autre noyau ...

 func loopy() {

    let x = safely look at info on NattyScene
    let globalCOG = calculation
}

---

Note : Le KOD a indiqué DispatchQueue Ce qui est très bien, mais y a-t-il un moyen de s'assurer qu'il s'agit bien d'un autre cœur ?

Answer 1

Bonne question, malheureusement je ne pense pas que cela soit possible pour 2 raisons principales.

Raison 1

Ce type d'accès de bas niveau n'existe pas dans iOS.

C'est le système d'exploitation qui décide quel thread s'exécute sur quel cœur. Il a également la capacité d'activer et de désactiver les cœurs en fonction de plusieurs conditions qui dépassent le cadre de votre application.

Par exemple, lorsque dans Grand Central Dispatch vous écrivez

DispatchQueue.global(qos: .background).async { }

Vous n'avez aucune garantie que la fermeture sera exécutée sur un autre noyau.

Raison 2

La boucle d'exécution de SpriteKit exécute un certain nombre de choses

1. Mise à jour de l'appel
2. évalue les actions
3. simule la physique
4. applique des contraintes

Votre idée implique l'exécution des étapes suivantes dans le cadre de la call update phase

1. passer à un fil de discussion "de fond".
2. effectuer des calculs lourds
3. ramener le résultat dans le fil d'exécution principal

Mais à ce stade, vous n'avez aucune garantie que la boucle d'exécution du jeu se trouve toujours dans le fichier call update phase. Il peut s'agir de la phase evaluates actions ou il pourrait même fonctionner au cadre suivant. D'autre part, vous n'avez pas plus de 16 millisecondes pour rendre chaque image.

Solution possible

Au lieu de cibler un autre cœur de processeur, vous pourriez tirer pleinement parti des 64 bits autorisés par le cœur actuel. Regardez cette question/réponse sur SceneKit où sont énumérés les avantages de SIMD.