Come gestire molti piccoli processi di lavoro

1

Quindi ho questa idea con cui sto giocando per rendere il mio esperimento di reti neurali da zero come un divertente esercizio per hobby, quindi ho qualcosa da imparare e da approfondire nel fare ricerche per ciò che voglio codificare . Sono assolutamente consapevole che sto reinventando la ruota. Ma lo sto facendo per scopi di apprendimento / divertimento / hobby.

Il mio approccio non sarà uno con il tradizionale calcolo del caso e lo stato di aggiornamento nella prossima generazione in cui migliorerà su se stesso, sto provando qualcos'altro, che consentirà alla mia rete di adattarsi a situazioni mutevoli, solo per vedere cosa accadrà quando spengo le luci .

Quale sarebbe un buon modo per gestire la moltitudine di processi di lavoro con cui la mia app finirà?

  1. Devo iterarli su ogni "tick" e aggiornare il loro stato?
  2. Devo inserirli in thread in modo che chiamino tutte le funzioni contemporaneamente (o quanto sia importante che lo scheduler di thread li trovi)?
  3. Dovrei raggrupparli in gruppi e inserire i gruppi in thread che li iterano in modo indipendente.
  4. Altro ...

Il mio problema con lo scenario 1 è : che se ci sono molti neuroni potrebbe essere necessario un po 'di tempo per aggiornarli tutti, rendendo più lento il progresso generale. Le cose che ti vengono in mente sono l'aggiunta di flag di aggiornamento a loro e solo per iterare quelli per l'aggiornamento. Potrei anche usare i flussi java in modo che java possa fare la magia sotto il cofano rendendo l'iterazione parallela quando possibile.

Il mio problema con lo scenario 2 è : ci sono solo tanti thread. Su normali thread della cpu da 1 a 8 di solito sono in esecuzione e deve anche ospitare un SO. Quindi non c'è molta flessibilità. Potrei espandere l'utilizzo dei nuclei GPU, ma c'è anche una quantità variabile lì, e sono solo per istruzioni specializzate. Anche lo stesso problema del problema del traffico nello scenario 3, ma su scale più piccole, e voglio evitare di cestinare lo scheduler dei thread

Il mio problema con lo scenario 3 è : causa un "accumulo / ingorgo" di segnali che devono essere elaborati che attraversano dal cluster A al cluster B se il cluster B non ottiene come molto tempo dallo scheduler dei thread come cluster A.

Il mio problema con lo scenario 4 è : non l'ho ancora inventato.

La mia lingua di destinazione sarà Java. Sono sicuro che ci sono soluzioni per questo e problemi simili, dove molti piccoli processi devono fare una cosa per completare una cosa grande (ciò che viene in mente è il rendering del gioco in 3D, da qui il mio scenario 1).

Sono propenso allo scenario 1, ma quali sono le cose che dovrei considerare con tutti questi piccoli lavoratori e quale sarebbe l'approccio più consigliabile.

    
posta Tschallacka 23.03.2018 - 18:17
fonte

1 risposta

2

Devi assolutamente evitare di creare un thread per worker. Avere molti thread creerà un sacco di overhead e trascinerà il tuo rendimento. Se vuoi avere molti lavoratori, la tua applicazione si fermerà quasi completamente.

Il numero ottimale di thread per la tua applicazione è qualcosa che dovrai sperimentare, ma in genere sarà approssimativamente il numero di CPU sul tuo sistema. Quindi se hai 4 core di hyperthread, potrebbe essere 7 thread.

Per gestirlo in Java puoi utilizzare Executor framework o utilizzare la più recente API di streaming . Utilizzando qualcosa come un servizio di esecuzione di un pool di thread fisso ti darà un sacco di controllo su questo e usando le API di streaming sarà più automatico. Io tendo verso gli Executor poiché ho già investito il tempo per comprenderli, ma se vuoi ottenere qualcosa andando molto velocemente, potresti voler seguire i flussi.

    
risposta data 23.03.2018 - 19:26
fonte

Leggi altre domande sui tag